AutoHotkey Community

Here are the changes for v1.0.42:

Fixed expressions such as "If not Installed" not to be misinterpreted as "If not in List". [thanks Toralf]

Fixed certain unusual situations where a hotkey would unnecessarily require the keyboard hook.

Fixed vkNNN hotkeys to be handled by the hook when that VK is also used as a prefix for other hotkeys.

Fixed #IfWin's automatic disabling of prefix keys work properly if Suspend is ON.

Fixed minor hotkey issues on Windows 95/98/Me: 1) The wildcard prefix (*) is ignored and such hotkeys are put into effect rather than being disabled; 2) Non-wildcard hotkeys that are a subset of a wildcard hotkey are put into effect rather than being disabled; 3) A left/right hotkey such as >#x is put into effect as Win-X rather than simply "X".

Changed the Hotkey command to create a new variant (when appropriate) rather than always updating any existing hotkey of that name. Please update your scripts accordingly.

Changed hotkeys to recognize ^!c as being the same as !^c (different symbol order). This also affects the Hotkey command.

Improved the Hotkey command to support UseErrorLevel and context-sensitive hotkeys (via "Hotkey IfWinActive/Exist").

Improved #IfWinActive/Exist to support Windows9x. In addition, the keyboard hook is now avoided whenever possible. Finally, #IfWin now sets the Last Found Window.

Improved the following commands to support TListBox/TComboBox and possibly others: Control (Add/Delete/Choose/ChooseString); and ControlGet (FindString/Choice/List).

Added support for hotkey and hotstring variants (duplicates). Such hotkeys perform a different action (or none at all) depending on the type of window that is active or exists.

A great great great release. Thanks a lot., Chris.
If you can do a #IfVar [Variable, value] on the model of #IfWinActive [, WinTitle, WinText] and others, where "Variable" is a variable name (or an expresson if possible) and "value" the expected value of the variable, it should be fabulous !!!

Thanks again for the good job

Although there would be some benefit, it seems reduced by the fact that you would normally have to use SetTimer to keep the variable updated. But maybe you had something else in mind.

There's still a plan to call a function of your choice upon typing selected hotkeys and hotstrings. If the function returns true, the hotkey would not fire (instead, it would pass through to the active window). Perhaps this would be suitable for what you envision.

The new freedom in the order of hotkey modifiers is a bit confusing.Ctrl-Alt-X now jumps to the label msg, but sees A_ThisHotKey as "!^x", from the hotkey label. If the second line were missing, the value of A_ThisHotKey would be "^!x". If a script checks the first character of A_ThisHotKey, the result is unpredictable. Could it be possible to have the modifiers in A_ThisHotKey (and its relatives) always in some canonical order?

@ Chris
I've to give you a salute for the enhanced Control command set. A live saver
To be able to identify a specific strings position at the index of a TComboBox, I was forced to do a sql query at the DB. That's now history.
Thank you Sir !

Thanks BoBo. I should have thanked Suny for suggesting it.

I see your point. However, there are at least two drawbacks that might outweigh the benefit of canonical ordering:

1) It would break existing scripts that rely on honoring the original/defined ordering of the symbols. For example, a script that does: If A_ThisHotkey = !^x

2) It seems counterintuitive because when someone defines !^x and then discovers ^!x inside A_ThisHotkey, they'd be puzzled until they looked up the note in the documentation about it. Also, they'd have to either memorize the canonical order or consult the documentation whenever they compare A_ThisHotkey to an exact value.

What do you think?

Existing scripts could break, anyway, with the unpredictable A_ThisHotKey. To fix others, which rely on comparing it to strings, we could use sort: If (A_ThisHotkey = SortWord(!^x)), with a function similar to this (assuming AHK sorts A_ThisHotKey and co. with the same algorithm):

It's true that existing scripts are broken by 1.0.42. The reason this was done is the number of scripts broken seems very small (fewer than 1 in 1000, I suspect), yet the benefit seemed large (catching unintended duplicates, not having to remember the order you defined the symbols when accessing a hotkey, being able to find out with certainty whether a combination of modifiers already exists as a hotkey, etc).

By contrast, the change you propose seems like it would break a higher number of scripts (perhaps 1 in 100), while providing a benefit only in cases where a hotkey was initially created as ^!x but then later accessed via the Hotkey command as !^x.

Doesn't it seem more intuitive to have the hotkey's true name be determined at the time it's created? That way, a user can refer to a hotkey in the way that is most comfortable for them rather than having to remember a sorting order.

Clearly there are cases where a user would prefer a strict/consistent ordering. So perhaps what is needed is a new directive to determine which style you prefer. However, if fewer than 1 in 1000 people would use it, it's hard to justify spending a lot of time and code size on it.

Until this is decided, I've updated the help file in two places to clarify the issue: When a hotkey is first created -- either by the Hotkey command or a double-colon label in the script -- its key name and the ordering of its modifier symbols becomes the permanent name of that hotkey as reflected by A_ThisHotkey. This name does not change even if the Hotkey command later accesses the hotkey with a different symbol ordering.

Sorry, but this isn't clear to me, could you please explain what has changed and why I need to adjust my scripts? Thank you
I guess I have problems to understand what you mean with "create a new variant" as opposed to "updating any existing hotkey of that name".

In which cases will this cause problems with old scripts.

toralf, feeling left alone in the forest

I believe this only impacts scripts that use v1.0.41 features and then upgrade to v1.0.42. Specifically, the Hotkey command in v1.0.41 would always update/modify a hotkey if it already existed as a hotkey. But in v1.0.42, the Hotkey command might create a new variant (sub-hotkey) even if the hotkey already exists. It will do this if is no existing variant for that hotkey that matches the current IfWin criteria.

For example:

In v1.0.42, the topmost line above creates a new variant for the #c hotkey that fires only when a Notepad window is active. By contrast, v1.0.41 would update the original hotkey to have the specified label (and it would not make it a Notepad-only hotkey).

I have clarified this in the changelog by adding, "this only affects scripts that use v1.0.41's #IfWin directive". Thanks.

#IfWinActive is a great new feature! Here's a combo to let Ctrl+V paste when a command prompt is open

#IfWinActive, C:\WINDOWS\system32\cmd.exe
^v::
Send !{SPACE}ep
return
#IfWinActive

This is a really good application. It looks safer, though, to use ahk_class ConsoleWindowClass, because the window title is often different.

Thanks for the tip!

... and for the poor with win98: Yes it works, but you need an additional line:

_________________
Peter

Wisenheiming for beginners: KaPeGe (German only, sorry)

Yes, I recently learnt the use of the title command...
It is really handy when you have several command windows opened.
Althought Microsoft could make one with tabs, like in Linux...

The tip is nice, but coming too late, I am becoming used to the QuickEdit mode...

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