AutoHotkey Community

I have, over the weekend, "ported" most of my menus and hotkeys etc. from PowerPro (PP) to AutoHotkey (AHK) (and I can tell you, my wife doesn't like AHK:-)). I think the syntax of the script language is in places rather funny, but this seems to be the same with all script languages.

I would say that, right out of the box, PP does more and does it more accessibly. Most things can be done with AHK as well (sometimes indeed better or more efficiently than in PP) but this invariably needs some extra work whereas in PowerPro the stuff (as far as it goes) simply works. Sooner or later you'll need the scripting language in PP as well, but many things have a rough but adequate user interface or a high-level command which hides most of the legwork.

Menus are a case in point: PP shields the user from the drudgery of actually handling the menu choice: you simply define the menu options and the actions linked with every option and that's it. But in the end that's not such a big deal, as most of the code needs only (re-)writing once. As I am not uncomfortable with script languages there's no problem. But the fact remains that PP is probably more newbie friendly than AHK. (By the way, all this is meant as constructive criticism, not as the starting point of a flame war about the best keyboard enhancement utility.)

And there is one feature in PP (filemenus) that I think would make for a great addition to AHK (see further down).

So, by and large, the process was relatively smooth. There are some small open points which probably need some more digging in the help file but in general almost all went fine. There is, so far, one glaring exception, a real show stopper, to do with windows losing focus (see the other thread).

Here are a few things in the would-be-nice-to-have category (if I am not making myself clear feel free to ask):

* PP has something called filemenus. A filemenu is a simple text file that can be displayed as a menu:-). The menu entries are connected with a string that is sent to the active window (see my problem above). The whole thing looks like this:
Mail&1=xyz.blabla@mail1.com
Mail&2=abc.blabla@mail2.com
Mail&3=nomail@mail3.com
&krt=Kind regards{enter 2}Thomas
&www=world.wide.web
&etc=et cetera...

So basically they are hotstrings without a hotkey, instead they are activated via a menu which in turn can be shown with a simple command upon pressing a hotkey. The beauty of it all is that you only need to define your menus in simple text files and off you go, no code to write, nothing. I am sure that one could write a script which does something very similar semi-automatically. But having such a feature out of the box is really nice (and would be nice for newbies as well).

* PP maintains a clipboard stack in which the last n texts seen by the clipboard are kept. I know there are utilities out there for this but they are much too bloated for what I need. Again one could probably write a script...

* PP can execute the contents of a variable as a script (which makes possible some amazing things). One could simulate that by writing stuff into a file and executing it but that's would not be too efficient, I imagine.

* A case statement would be nice. Okay, that's just syntactic sugar as a succession of if/elses can do the same but it makes for slightly more compact code.

* Mouse locations: not just x/y coordinates but also "logical" places like "in the left/right half of a window", "over the caption", "over the system menu", "over the minizime/maxizime button" etc.

* WinTitle parameters (for WinWaitActive etc.): more flexibility, ie. wildcards like "*Notepad" etc. Perhaps even regular expresssions?

* Regular expresssions would also be nice in the search routines. (One can always dream.)

* Commands which use WinTitle: another parameter which temporarily sets SetTitleMatchMode (having to set this script-wide is way to inflexible and bracketing stuff with SetTitleMatchMode commands gets cumbersome after a while)

* Sometimes (always?) path- or filenames need not be enclosed in "" even if they contain spaces. Okay. But what about filenames with a comma or a semicolon in them? Example:
#Include This filename contains a semicolon ;.txt ;try to load "This filename contains a semicolon ;.txt"
doesn't work. This example is contrived but I have lots of filenames (for instance, MP3 stuff) with commas and semicolons.

* Something esoteric: in PPro the command "Exec Explorer *" opens an Explorer window which shows the working directory of the currently active program. There is no obvious way how to get the working directory of a program in an AHK script so I don't see how that can be done in AHK.

What I miss most are the filemenus and the automatic clipboard handling. And there may be a few more things popping up, as I continue my explorations.

To sum up so far: I think that AHK is more stable, faster and better integrated into the OS than PP, for one thing. Also, compared to PP, the update cycle for AHK seem pretty short (does Chris ever sleep?). On the negative side is it's lack pre-packaged things (which may be a design feature. of course).

But once I can do (almost) everything I used to do with PP with AHK I will gladly rid myself of PP.

Any thoughts?

Regards Thomas

PS: Sorry for the long post.

I agree that any scripting app with a GUI macro designer is going to be more accessible to new users. AHK tries to make up for this a little with simplified syntax, such as hotkeys and hotstrings (which are designed to be accessible to even the most non-technical users). Even so, AHK has more of a learning curve.

Hopefully that's been fixed in v1.0.35.15, but if not I'd like to give it more attention.

There are some technical reasons why this feature is difficult to do. The primary one is that AutoHotkey is not a purely interpreted language. Instead, it semi-compiles the script upon startup, which enhances its runtime performance (especially loops).

I agree that this should get attention soon.

Wildcards are planned, but I'm not sure exactly how they will work or with which commands.

All of the RegEx libraries I've seen would increase the size of each compiled script by 20 to 50 KB. But hopefully someday a subset of the most commonly used RegEx features will be supported.

I think most scripts can use SetTitleMatchMode 2 and keep it for 95% of everything they need. That's the main reason it's a mode: Its net effect is to add convenience, even though it detracts a little in other ways.

Although commas don't need to be escaped if they're in the last parameter of any command, you can escape them (as well as semicolons) at other times: #include incl `; txt.ahk

I'll update the #Include documentation about this.

Getting this info via the OS's API does not seem straight-forward, but I'll look into it. Perhaps someone here knows how to program it.

Thanks for this detailed list of pros, cons, and suggestions. It's great to get the perspective of someone coming in from "outside the box".

I see the point. So what about the following command:
Execute %blabla%
The C++ code would take the contents of blabla, load and pre-compile them as if they came from an imaginary script file and then execute the code. Of course that would constitute a new execution environment but it would make some pretty useful things possible. And it would be much faster and simpler than writing the stuff into an actual temp file on the disk and having that executed.



I've seen on another thread that the size of the EXE is an important consideration. And I agree.

So why not having the main stuff of AHK in the EXE and supporting or esoteric things in a DLL (or set of DLLs) which is (are) only loaded if required? This would lose the beauty of having one EXE but one can't have everything.

I'll check the other things and will come back.

Thomas

RegEx is a lower priority than wildcards, and dynamic execution is not the highest priority because it has a high difficulty level but only benefits a small percentage of users.

But this topic's entire set of ideas is valuable and will help determine the shape of things to come. Please continue to post more as they occur to you.

The latter are easier to do, of course, but RegExes are much more powerful. MUCH MORE So my vote goes... okay, okay, I keep silent.


What about the idea of loading a sort of pseudo temp script?

Thomas

My rough estimate is that the difficulty would still be high because it would involve a redesign of several complex parts of the program. And the benefit doesn't seem too large, especially since jonny already wrote the following script to help dynamically execute commands: http://www.autohotkey.com/forum/viewtopic.php?t=3332

Quote from Chris: "I agree that any scripting app with a GUI macro designer is going to be more accessible to new users. AHK tries to make up for this a little with simplified syntax, such as hotkeys and hotstrings (which are designed to be accessible to even the most non-technical users). Even so, AHK has more of a learning curve. "


Hi... I think that AHK could take on some of the advantages of a GUI macro designer by adding additional features to an app like SmartGUI creator. Right now, SmartGUI just makes windows and controls. But AutoHotKey, is approaching the power of many programming languages. Just using a script editor will not do for small application development or RAD (rapid application development). When you start to get into complex code and logic combined with a GUI, there are better ways to develop small apps than what is being done now.

To blend AutoHotKey scripting power to the GUI windws that it can make, I strongly believe you need something approaching a real IDE, where you can assign action/events to controls. It does not have to be a super complex GUI IDE. It can just start by allowing you to right-click on control in SmartGUI and add commands for the action of the controls. Then it can start to grow from there and include more features.

Also, an extremely advanced version of this concept is Limnor (codeless programming system) http://www.limnor.com/ Obviously AHK is not Limnor, but moving a little in this direction will not hurt. Especially since Limnor may be moving in AHK's direction by adding a automation module/performer soon.

Just a thought...

These are some ambitious but cool suggestions. Limnor seems especially novel. Maybe it or something like it will be the "next big thing". Hasn't it been a while since we've had a "next big thing"? Maybe I haven't been paying enough attention

Thomasl, I was very impressed by PowerPro(PP) but about two years ago I dropped it because it offered TOO much -- too many goodies in the cookie jar for me to keep'em straight. Has Bruce Switzer made any major upgrades in the last year or so? Is there now any index to the documentation?

Yeah, Bruce keeps updating PP all the time (it is v 4.2 now, I think), though he sometimes seems more concerned to add new features than to get rid of old bugs. In fact that was one of the reasons why I looked for alternatives.

The documentation keeps also getting better. But I think will stick with AHK because it has a much smaller footprint. The main work (and worry) was getting my PP configuration up and running but it looks pretty good.

And AHK is open source which means if a bug or a misssing feature drives me up the wall I can always do something about it.

Perhaps this post could be moved from the Ask for Help to the Wish List section; would seem more appropriate, since it has good, thoughtfully considered suggestions.

_________________
1) The Open Source Definition http://www.opensource.org/docs/definition_plain.php

2) Intuitive. Logical. Versatile. Adaptable. <<AutoHotkey>>