AutoHotkey Library / API

Why not have AHK's functionality exposed as a library so other programming languages can leverage the power of AHK?

A simple C DLL that exposes every command of AHK should be enough for everybody. All other programming languages can build their APIs as wrappers on top of that. E.g.: a JNI wrapper for Java, a Python C wrapper for Python, a C++/CLI wrapper for .NET, etc. It would be good if the library is released with a LGPL or similar license so developers can use it in commercial projects.

AutoIt v3 already has this: a C DLL and a COM interface. But I prefer AHK as its open source and the community is more vibrant.

It will also attract more developers to the project who are just looking
for a way to automate stuff in windows, using the programming languages they love and have mastered.

I've seen entries in the wish list asking for namespaces, static arrays and so forth. These are all features of most mainstream languages. IMHO the main goal of AHK is not to create another programming language, but to provide very powerful automation and scripting functionality to Windows.

You are not the first to make this wish...

Well, I agree with you, separating the functionnalities from the language itself would be nice, it would ease my vague project of implementing AHK stuff in Lua...
But I believe that's not a job for Chris, which has better things to do, like improving the program.

If somebody want this enough, he has to do the job. And hopefully, in a clean enough way that could be reused by AutoHotkey itself, so Chris would make evolutions to the language independent part (and the language part too, of course) instead that on the monolithic AHK.
Otherwise, one would have to track down every change to the sources and integrate them to the DLL project.

Note a licence issue: currently such library can be only GPL, thus any project using it must be GPL too. To do otherwise, one should also rewrite the small parts coming from AutoIt, so nothing remains from this project, that would allow to change for a licence of lighter burden. A derivative of BSD licence would be nice (new BSD, MIT, zlib/libpng, etc.).

I tend to agree with that. I'm not saying there will never be a more modular form of AutoHotkey such as a DLL; just that it doesn't seem nearly as high in priority as adding often-requested features to the main source.

Also, I see your point that it might attract more developers to the project. That is something that would definitely help, yet doesn't seem quite enough to take priority over features like version 2 and arrays.

Thanks.

I also agree 100% to the arguments Auto-Mate gave.
I work on an open source project that has some intersections in the features and goals as AutoHotkey. You can find out what I mean quickly, if you look at its home page: http://www.eventghost.org

Since I also needed keyboard emulation and hotkey events, I first looked at AutoHotkey with the wish to integrate it. But after days of studying the sources, it was clear to me, there is currently no way. So I had to implement it myself from the ground. The current implementation of the keypress emulation for example is far away from the quality AHK has, as I cannot spent all my time in figuring out all oddities the Windows system has. And if I look at all the exceptions you made in your code to circumvent all those special cases, I really could go green with envy. (BTW the sources with the massive comments teached me much.)

Since such an DLL wouldn't be possible in the near future, how about some limited COM/ActiveX interface for AHK? This would allow other scripting languages to kick in quickly. At least for some keyboard emulation (where the external application can give the window handle AHK should target) and event notification.

Thanks for your comments.

Since such an DLL wouldn't be possible in the near future, how about some limited COM/ActiveX interface for AHK?

I wouldn't know where to begin because I've no experience with COM/ActiveX.

Thanks for the link to www.EventGhost.org. Your project has many features that I'd like to see AutoHotkey have someday.

I just started to acquaint myself with the (in)famous C++ (downloaded Dev-C++), so for start I would be satisfied with just a library (or plugin, whatever it needs to work) that would enable GUI capabilities of AHK
Believe it or not, FYI, c++ is almost as primitive as assembler and it's incredible how serious programmers can make all those nice GUIs (see nero for example), and AHK has great GUI capabilities.
btw , I might add a suggestion that Autohotkey v2 would be even better, if it could compile dll-s (so then the whole world could discard M$ Visual C and embrace Autohotkey :twisted: )

omg.... :?

(downloaded Dev-C++)

You should try Code::Blocks, I find it more advanced and nicer than Dev-C++. Of course, it is matter of taste. You can have both to compare them, anyway.

I might add a suggestion that Autohotkey v2 would be even better, if it could compile dll-s (so then the whole world could discard M$ Visual C and embrace Autohotkey :twisted: )

:lol:

I wouldn't know where to begin because I've no experience with COM/ActiveX.

What a bummer!
I hated COM in the beginning but now I'm a fan of it. It allows you to write things, that can be used from any application and any language as if they would be a part of the language. So you would instantly get support for C, C++, Delphi, Python, Perl, VB, C#, Lua and so on. You can even use AHK from Excel and Word then. Writing COM-aware stuff from Python is very easy but I also have no experience how hard it is from C/C++. But as all MS stuff it was created on C/C++.

Its not the COM functionality that doesn't attract ppl, but the framework.
Programmers generaly don't like it, it appears that it is hard to create even simple things...

I didn't use COM much so I can't judge myself.
You must also account the fact that many of examples there use MFC and again, many programmers don't like MFC (personaly, I can't think about bigger horror)

Programmers generaly don't like it, it appears that it is hard to create even simple things...

As said before, I also had many reservations regarding COM. But at least from Python it is very easy. This is nearly all I had to write to get two functions exported:

import pythoncom
import eg

class EventGhostCom:
    _public_methods_ = ['TriggerEvent', 'BringToFront']
    _reg_progid_ = "EventGhost"
    _reg_clsid_ = "{7EB106DC-468D-4345-9CFE-B0021039114B}"
    _reg_clsctx_ = pythoncom.CLSCTX_LOCAL_SERVER

    def TriggerEvent(self, eventString, payload=None):
        eg.TriggerEvent(eventString, payload)

    def BringToFront(self):
        eg.mainFrame.BringToFront()

If you now want to trigger an event inside EG from an external application, you can write in Visual Basic for example:

Set EventGhost = CreateObject("EventGhost")
EventGhost.TriggerEvent("Hello from VB")

And that's really cool.

AutoHotkey and Eventghost should team up. I like the plug-in concept. I think AutoHotkey v.2 should make the attempt to compile its own DLLs. Maybe something "funky" could be done, where you could call functions from compiled AutoHotkey scripts. AutoHotkey would skyrocket in popularity and use after that.

Its not the COM functionality that doesn't attract ppl, but the framework.
Programmers generaly don't like it, it appears that it is hard to create even simple things...

I didn't use COM much so I can't judge myself.
You must also account the fact that many of examples there use MFC and again, many programmers don't like MFC (personaly, I can't think about bigger horror)

I think AutoHotkey should just make it easy and clear on how to use other scripting languages to do COM/ActiveX from within and AutoHotkey script.

I think AutoHotkey should just make it easy and clear on how to use other scripting languages to do COM/ActiveX from within and AutoHotkey script.

It's still on the to-do list among hundreds of other items, so I probably won't get to it before v2. If anyone would like to draft up something concise and useful for the documentation, I'll try find a place to put it (if nothing else, some index entries can guide people to it).