AutoHotkey Community

Well, they could be, but it is an enormous work (particularly most of AHKnow* suggestions...), in implementation and even more in researches (Chris doesn't know everything, like all of us).

Making a DLL need to know how to compile code, it is certainly not a small task.

Integrating other languages is extremely hard. Perhaps it is possible by making AHK a WSH language, but it also need lot of knowledge, including Com.

Laszlo's suggestion has been made numerous times, it is mostly putting AHK core functionalities in a DLL. It won't be done soon...

A plug-in system would be cool: add a DLL to AHK install dir, write in a script Require MyCoolPlugIn and just use the functions (or commands!) in the plug-in like they are full part of the language. Not to be there soon either... And probably need some kind of namespace to avoid conflicts (is GetFile a FTP command or a P2P one?).

SQLite support: already done with DllCalls.

An IDE: the idea is in the air, but need lot of work. I suggest Chris won't work on this (at least not alone), it should be started by somebody else and ideally be a community project.

Other encryptions? A better method? Do you know an example where the current encryption has been cracked?

_________________
vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

Thanks for all the comments. The thing about plug-ins (the kind that must be written in a programming language like C++) is that very few AutoHotkey users have the knowledge and interest to create one. In fact, there are so few that I suspect it would be at least several months before the first plug-in was written. Further evidence of this is that even though AutoHotkey has been around for over 3 years, it still has only one regular developer.

Two months ago, I asked for volunteers for this at AutoHotkey Needs You. Hopefully someone will come along someday.

Thanks.

Maybe, but a small amount of plugins could make a big difference ...

In the main AHK window, I find the menu to switch views impractical, and I never remember the corresponding shortcuts.
I would suggest either using tabs to switch views, or perhaps simpler, adding a simple toolbar with an icon per view.
Note: for some reason, if the script is displaying a message box, no keyboard shortcuts (^v, ^k, etc.) work in this window...

_________________
vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

I can see that it would be better, but at the current rate of progress, it will probably be a long time unless someone else does it.

It's a known limitation, but undocumented. Maybe there's an easy way to fix it, but I haven't found it yet.

I was thinking that maybe an alternate plug-in method could be come up with that does not require people to know C++. But whatever the alternate method is, it would need to be approved by Chris.



Idea 1:

Maybe what could be done is a special AutoHotkey program that uses the AHK2EXE and EXE2AHK compiler/decompilers on the fly.

Perhaps you could call this AHK_Plugin.exe

You would have 3 parts. User’s compiled script, AHK_Plugin.exe, and UDF/Plug-in folder with all the UDF’s/Plugins

The user’s compiled script would be written to call whatever functions that it wanted. If a function was not found in the user’s compiled script than it would call the AHK Plugin.exe .

The AHK Plugin.exe would have a list of functions available in the plug-in/UDF folder. I was thinking something DYNAMIC that constantly scanned the folder so that any new additions and functions would be updated in the AHK Plugin.exe list. The AHK Plugin.exe would then find the function.

Once a match was found it would decompile the user’s compiled script and add whatever functions were called. Then it would compile the script and proceed.

The biggest disadvantage would of course be speed.

The biggest advantage would be that it’s dynamic and allows the user to write his script to call specific function from many different UDFs/Plugin.

The next advantage would be size of AutoHotke.exe/AutoHotkeySC.bin could stay smaller and only the most essential thing would be added.


Idea 2:

The method used for the AutoHotkey dynamic execute script might help http://www.autohotkey.com/forum/topic3332.html

Perhaps it or the concept can be part of a new AHK plug-in architecture.

A script could be created to act as a special compiler/maker to create dynamic AHK executables. We could call this script an AHK Plug-in Compiler/Maker. Not a "true compiler", but something to convert regular scripts into dynamic AHK executables.

The trick here would be how the script would do it or any rules that are needed so that a script could easily be changed into a dynamic AHK executable. Another thing is that the AHK dynamic executables would have to have a way to make a list of its functions available.

The created dynamic AHK compiled scripts would act somewhat like AHK DLLs.

The advantage would be that users would simply drop these AHK dynamic executables into the same folder or specific folders and then execute whatever UDF’s they wanted. If the function was not in the script than it would search among the AHK dynamic executables (which would present a list) for it. Once found it would then execute it.

This method would be pretty fast, as there is no need to compile or decompile.

The user’s script and the AHK dynamic executables could be encrypted and have a greater amount of protection.

The disadvantage would be size, since the dynamic AHK compiled scripts would have the AutoHotke.exe/AutoHotkeySC.bin bound to them. But, we are not talking .NET big. Also at some point the official AutoHotkey compiler could be re-written to make DLLs. This would be an intermediate step that provided DLL/Plug-in like functionality in addition to DLLCall

Although they're a creative way to get plug-ins prior to support for "real" DLLs, I can't see myself working on it anytime soon due to other priorities.

But since the project is open-source, maybe another developer will take an interest in it. Thanks for the ideas.

Acutally I had a different idea in mind. Most people use AutoHotkey for automation, as a "short cut" language/"ease of use" scripting language, etc... For many people, AutoHotkey, is the primary language they are using. So they would use AutoHotkey unless a task required they need another language to get someting done.

That's why I keep pushing the "OtherScript" concept. You can use Fileappend or a variable with () in AutoHotkey to create temp files and then use the Run command to point at the scripting engine (like Cscript.exe). But doing it that way is a kind of odd work around.

Why not go the extra bit and create a new command that is specific for doing this (say OtherScript or whatever) and build in the CMDret function?

Now whenever you need something "extra" to perform a task, you can use Python, JScript, etc...

It seems to me that AutoHotkey should eventually go one way or the other. The "OtherScript command and built-in CMDret seems the easier path.

The other way would be to try to make AutoHotkey a Windows Scripting Host compliant language. This would also have the side benefit of allowing AutoHotkey to create and use COM objects. I'm no COM expert to be sure, but it appears very do-able. So anybody with more COM knowledge should feel free to jump in.

Examples of that direction-

Many other scripting languages like Python for example have done it. AutoHotkey, as a scripting language would not need to change, it would just follow the steps for compliance.

You can fill in the skeleton of an XML file, which would contain your scripting code, to allow it to run as a COM component. The WSH would call the correct script engine to perform a task.

By the way, Titan wrote kick-ass AHK based XML Reader and XML Writer, http://www.autohotkey.com/forum/topic12004.html (Reader) http://www.autohotkey.com/forum/topic9155.htm (Writer)

Here are some related articles that go over the steps:

http://www.microsoft.com/msj/0200/visua ... g0200.aspx (Using XML and The Windows Script Component Wizard )


http://www.pyzine.com/Issue007/Section_ ... onCOM.html (Python example. I thought the Python example was the most interesting, though I found the language syntax a bit annoying).

http://www.aspfree.com/c/a/Windows-Scri ... g-Host-56/ (Windows Scripting Host 5.6)

http://msdn2.microsoft.com/en-us/library/shzd7dy4.aspx (What is the Windows Scripting Host)

http://en.wikipedia.org/wiki/Component_Object_Model (Wiki on COM with examples in C++, links, etc...)

Microsoft is also committed to maintaining compatibility with WSH, even with its new PowerShell and .NET technologies. This would give AutoHotkey users another option to make use of com objects created in other programming and scripting languages.

You can never satisfy everybody. I have to write Python scripts to describe algorithms to my colleagues, I write MATLAB macros for numerical calculations, MAPLE functions for symbolic and arbitrary precision computation, C programs for benchmarking, VHDL for hardware description, etc. And I am not a programmer. Keeping all the different syntax rules, exceptions, command names etc. in mind is too much. I was excited about AHK, because it allows automating repeating tasks, creating keyboard shortcuts, GUIs, menus, etc. But it is different from all the others. I hoped it would develop to replace one of the other languages, so there will be no need to master yet another one. It will not happen. AHK's goal seems to remain to facilitate simple scripts for simple tasks.

Another hope was that AHK could be incorporated, say, in Python. The Python syntax, data structures etc. need not be replaced, so there will be no two languages to be remembered, just the new commands. It will not happen in the near future, either. I don't know, why many great AHK users stopped posting to the forum, but one of the reasons could be that AHK is and will be too different. It is very good for 20 line scripts interfacing to the Windows API, but not for professional applications, not for prototyping, not for large data sets, not for number crunching or scientific computations. If you only use one programming language, at home, AHK could be it.

Abosolutely true.

_________________

I guess you're right. Unfortunately it doesn't seem to be a challenge for some of those to expand the barriers of something which is/seems to be limited, while it's easier to play with something which seems to have unlimited potential. I guess without DllCall() + RegEx..() kinda features we would face even more people to fade away ...

I hope those will start to think about to play with AHK's source (C++) ? Well, a known standard of human beings - to go for the comfort zone. :wink:

That is not the solution as Chris has its vision how AHK should develop and as he is and will always be the main author, that will lead to code branches. Code branch will not have the same community as original AHK.

For instance, I think that support for multithreading (single ahk script host, instead 1 ahk instance = 1 ahk script) is numero uno missing thing in AHK and if I was among ahk developers I wouldn't be interested in anything else but that at first. Many ppl here think it is not important at all, including Chris and Philho....


Quite true. I have sevel 2000+ script projects so far that I abandoned or almost abandoned cuz of problems that was stressfull or impossible to solve in AHK. The ugly part is that AHK seems to be capable of all, and govern by that idea you may try to do complex scripts; after almost all things have been done you will generaly encounter very hard problems, that are either not solvable, either very hard to workaround at the very finish of your work (at least, it happend to me every time).

_________________

Sorry, for not stating clearly. I wouldn't be satisfied to see several different AHK's out there. I thought about to see AHK as a single project where willing devs are invited to contribute.
Unfortuantely it's quite difficult to get such a specific tribe of human beings (called 'developers'), together. One reason why AU3 and AHK went into different directions. Quite the same/common situation as with Linux (derivates), VNC, etc. ...

For paranoid/loyal users like myself, it's confusing to get quadzillions of apps/OS's which differs only regarding details.
It's like starving in front of a loaded buffet because you're not able to decide what to go for .
Well, I'm BoBo

I totaly agree. New ununited developers will lead to the same process that was going on between AU3 and AHK.

I am not BoBo but I also don't like code branches. There is abstract enough approach to anything....

_________________

Thanks for the ideas and feedback in the last 7 posts.