AutoHotkey Community

As many of you know, the Planned Features page has not been updated in years. To better represent the community’s interests I’ve browsed the 30 pages of this forum and compiled an updated list that I think better reflects what the community would like to see happen with AHK. The list is intended to be prioritized: I’ve tried to rank the items based mostly on how much they’ve been requested, but also on how much benefit they offer (which is a more subjective measurement). It seems like every time I look at the list I move items around though, especially in the middle; so input on the rankings is encouraged.

The items are NOT ranked in the order they should be added to the official release of AHK. For that type of ranking, I would have given much higher positions to the items that can be most easily completed. The best example of this is Unicode support: it is requested constantly and would benefit a great many users; but the time required to implement it means it will not happen soon, if ever. Multi-Threading falls into the same category, so I’ve added question marks to both. It can legitimately be argued that both of these are outside the scope of AHK. Nevertheless, they are oft requested features.

I am hoping for plenty of feedback on the new list. Specifically, I am interested in the following (in order).
● I removed many items from the old list that I deemed too low-priority to keep. At one time, nearly every suggestion on the forum was added to the list. Many of these have not been requested since. If you believe I removed an item that should remain, please explain why it is more important than other items.
● If you believe any items on the new list are too low-priority to keep, please explain why.
● I searched for workaround scripts for each item on the new list, but I’m sure I didn’t find them all. If better workarounds exist for any of the items, please point them out.
● If you believe the items should be rearranged, suggest new priorities and explain why.

Here is the brand-spanking new Requested Features Top 40.

@ jaco0646
Thx for your impressing support of the community! Thumbs up!!

I second BoBo's sentiment.

A few items (14, 29, 30) say "Scripted by Lexikos", and link to AutoHotkey_L. I think that's a bit inaccurate since AutoHotkey_L is a custom build of AutoHotkey, not a script. For 29 and 30, I scripted that functionality before adding it to AutoHotkey_L - Menu Icons (MI.ahk).
Also scripted by deguix, rodfell and nanasisan.
Could you clarify this one? As far as I can tell, Laszlo's and skrommel's scripts simply use ClipboardAll/Clipboard to save/restore all clipboard contents. If there's still something to add to AutoHotkey itself, what is it?

Thank you both for your encouragement. There actually was quite a lot of "research" for such a short list: it took me most of two days. @Lexikos, I will update all the links in the morning (I'm too sleepy now) thank you for pointing them out. Concerning #33, that one came off the old list; I just added the links to popular virtual clipboard scripts. It might have been added prior to ClipboardAll in v1.0.29.

I don't remember ever using ClipboardAll myself. Is this a concern?Does that imply a limitation of the command or just a general error catchall?

If there are no longer any limitations, #33 should be removed from the list.

Seems important to me. I still get confused especially with plain text sometimes needing quotes, sometimes not and variables sometimes needing % and sometimes not. But I probably haven't studied the syntax properly.

Switch statement! Yes, please.

Hmm, neat concept, not sure of priority

Seems like a low priority. You can set a transparent gui window any size/place you want and alt-print screen it to the clipboard since it is transparent, you get the reqion under the window, if you screen shot of window, make it active and alt-print screen it.

How about width and height?
I wanted to show several lines of extra-wide text, with `t as a delimiter.
The tab works, and the message box can get pretty long, BUT...

...............There doesn't seem to be a clean way to change the width of the window.

I tried a variation of "Changing MsgBox's Button Names" (as listed in the FAQ) but I changed the width instead of button name.
It worked, but the background shading at the bottom of the box around button(s) doesn't 'stretch' when the window is resized.


Thanks for the link. I haven't got that far (stiill learning), but it would be nice.

Leef_me

It appears to be a "general error catchall".
If there are any specific limitations, fixing those could be put on the list. I think that #33 in its current form does not belong on the list.

See #10.
It can be done properly, without any sort of transparent window hack (see the "Scripted by" links). I don't understand why it was put on the "planned features" list to begin with:

• Decent script functions are available.
• It wouldn't offer anything new.
• It probably wouldn't be used very commonly.
• It isn't really central to the purpose of AutoHotkey. (It's just one very specific task which can be automated.)

MsgBox uses MessageBox to display a system-defined dialog box. The only way it can be done properly is with a custom GUI, which would look (and possibly behave) differently to the standard one, especially since the standard one is dependent on the version of Windows.

It probably can't be done any better with a built-in command than the current scripted methods.

Regarding



One of my open wishes is for URLDownload and a future URLDownloadToVar to work better with proxies.

Currently there's no way of entering the proxy user name / password other than storing it permanently in the Internet Explorer - something our work policies forbid.

On thing that I would like to see if a way to detect how many parameters were passed to a function (in the case of optional parameters). I worked with matlab, and it was a useful little variable.

For example, it would allow "overloading" functions more easily. Since you can only have one function with the same name, you could "overload" it via optional parameters. For example, say you have a function that takes 3 arguments up to 5. Depending on how many parameters were passed, you may want to take a different action, or the parameter order could be different.

Example:


I know, for example, AHK OOP could make use of this to provide better overloading of certain functions. Additionally, interfaces, can use this instead of the awful hack of a "reserved value". You can see my original post on this topic, A_ParamCount - to retrieve the numbef of PASSED parameters.

I'm not saying this is the most useful thing in the world (far from), but I'm giving my input.

_________________
As always, if you have any further questions, don't hesitate to ask.

Add OOP to your scripts via the Class Library. Check out my scripts.

I like both of these suggestions. UrlDownloadToVar and A_ParamCount would both be really useful to me. A_ParamCount would be more useful for me personally.

Another thing that would be handy, and I imagine simple to implement, is a better way of accessing the parameters passed to the script. Currently it confuses new ones because numbers are variables and frustrates more experienced ones because there is no way to pass the value of a script param in a function without first renaming the variables. ("Loop %0%" eeew..) But this may need to wait for v2 because it is a significant syntax change.

Maybe it has died down a bit, but I remember lots of requests for the making the mouse's position a hotkey context modifier. (like #IfWinActive) #IfMouseOver would be extremely handy for many people, and there is not currently a good way of achieving this in ahk code.

_________________
Scripts - License

Links have been updated for numbers 17, 29, and 30. Number 33 has been deemed obsolete and removed.

The priority of #11 (TrayTip gLabel) is high due to the benefit it would add, since I'm not aware of any effective workarounds. If anyone else feels its priority should be lowered or knows a good workaround script, let me know.

#23 (ScreenShot) is regularly requested on the Help forum. It would be commonly used by gamers, one of AHK's largest audiences. I agree that its priority could be lowered due to the excellent workaround scripts available. If anyone else feels it is not as important as other items, or that a ScreenShot command isn't necessary at all, let me know.

#37 (MsgBox coordinates) is obviously very low priority, but it made the list since workarounds require either a timer (clumsy) or a custom GUI (excessive). I'm a bit biased in favor of this one, since I often display MsgBoxes from another GUI and would like control over where the message is shown. Any other MsgBox enhancements seem to justify a custom GUI, as Lexikos noted. If anyone feels this item should be removed from the list, let me know.

@animeaime Your wish is #22.

YesYour wish is #26.

I've seen you guys refering to numbers left and right. Is there a place where we can see this numbered list, or does it exist in the minds of its creators??

_________________
As always, if you have any further questions, don't hesitate to ask.

Add OOP to your scripts via the Class Library. Check out my scripts.

The link is at the bottom of my original post.

AutoHotkey_L allows this via #If:
Not ideal, but at least it takes effect before the MsgBox appears:
AutoHotkey uses this message to force the MsgBox into the foreground. Since that is already in place, it probably wouldn't be difficult to add code for positioning. However, MsgBox's smart comma handling might make it difficult to add new parameters.

Hi Jaco,
Amazing effort with the list .

Here are some comments with shameless plugs for some of my own scripts...

Regarding:
2) Support multiple mice and keyboards.
I also had a sample script for multiple cursors
Other resources:
linux: http://wearables.unisa.edu.au/mpx/?q=screenshots
http://www.microsoft.com/downloads/deta ... laylang=en
http://code.google.com/p/pymultimouse/

3) Support true Arrays.
May as well do hashes at the same time, as that is bound to be the most requested feature as soon as arrays are implemented.
Something related that would be usefull is a find(item, sortedArray) function, that uses binary search. I am sorely lacking such a function working on ahkSearch.

Also, I would like persistent variables. Another example. But I would like a simpler implementation. A nice simple variable declaration such as Local, Static, Global, and suggested Persistent. This would have to be written to the A_ScriptDir (disk). Along the same lines, dumping and reloading the state of a currently running script...

7) Support scheduling by extending SetTimer
I would also like a parameter to SetTimer that lets the timer label know what function set it in the first place. Similar to how registercallback and lexikos' regex callout functions.

Add command URLDownloadToVar.
I may try to wrap edbrowse for this. It even has some javascript processing abilities builtin. discussion
Or, we can wrap wget.

13) Support function calls in addition to labels for most commands.
This is experimental in autohotkey.dll. Will try to turn it into a BIFs, with the help of Lexikos.

15) Support Multi-Threading?
There is a partial work around for this using multiply named copies of autohotkey.dll.

21) Support dynamic commands: Allow the contents of a variable to be run as though it were a section of the script, even if it contains multiple lines and perhaps even if it contains labels.
I will eventually add this feature in autohotkey.dll as a BIF.

26) Add directive to detect which part of a window (e.g. title bar or scroll bar) the mouse is hovering over
This is solved using Lexikos'#If directives... and they generalize to everything.

By the way, consider my added suggestions to be planned features in the testbed of AutoHotkey.dll with hopes of being merged into the mainline AutoHotkey.

I believe the plan is to support associative arrays - i.e. arrayvar[somekey]:=somevalue. Why would "hashes ... be the most requested feature as soon as arrays are implemented"?
There are many different ways to persist the state of variables, so I think it best be left up to scripts. (One example: AxM : Store and Retrieve AutoHotkey Global Variables.)
Exactly how is it similar? Neither RegisterCallback nor regex callouts will tell you which function set them. It would be much more generally useful for SetTimer to accept a function and parameter, perhaps even an expression to execute when the timer procs.
We already have UrlDownloadToVar. UrlDownloadToFile could easily serve as the basis for a built-in UrlDownloadToVar command.