Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

v1.0.42 released: Better context-sensitive hotkeys


  • Please log in to reply
27 replies to this topic
Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
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.

Demokos
  • Members
  • 105 posts
  • Last active: Jan 20 2011 06:28 PM
  • Joined: 28 Dec 2005
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

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004

#IfVar [Variable, value]

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.

Laszlo
  • Moderators
  • 4713 posts
  • Last active: Mar 31 2012 03:17 AM
  • Joined: 14 Feb 2005
The new freedom in the order of hotkey modifiers is a bit confusing.
Hotkey ^!x, msg



!^x::MsgBox Hotkey Label <%A_ThisHotKey%>



msg:

   MsgBox Hotkey Command <%A_ThisHotKey%>
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?

BoBo
  • Guests
  • Last active:
  • Joined: --
@ Chris
I've to give you a salute for the enhanced Control command set. A live saver :D
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 ! 8)

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
Thanks BoBo. I should have thanked Suny for suggesting it.

Could it be possible to have the modifiers in A_ThisHotKey (and its relatives) always in some canonical order?

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?

Laszlo
  • Moderators
  • 4713 posts
  • Last active: Mar 31 2012 03:17 AM
  • Joined: 14 Feb 2005
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):
SortWord(var)

{

   Loop Parse, var

      x = %x%%A_LoopField%`n

   Sort x

   StringReplace x, x, `n,,All

   Return x

}


Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
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.

toralf as guest
  • Guests
  • Last active:
  • Joined: --

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.

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

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004

...what you mean with "create a new variant" as opposed to "updating any existing hotkey of that name".

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:
Hotkey, #c, NewLabel
return  ; End of auto-exec section.

#c::MsgBox Win+C
#IfWinActive ahk_class Notepad
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.

tester8900
  • Members
  • 18 posts
  • Last active: Dec 07 2009 05:24 PM
  • Joined: 23 Jan 2006
#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

Laszlo
  • Moderators
  • 4713 posts
  • Last active: Mar 31 2012 03:17 AM
  • Joined: 14 Feb 2005
This is a really good application. It looks safer, though, to use ahk_class ConsoleWindowClass, because the window title is often different.
#IfWinActive ahk_class ConsoleWindowClass

^v::Send !{SPACE}ep     ; Ctrl-V to paste into console apps

^k::Send !{Space}ek     ; Ctrl-K to marK text, Enter copies

#IfWinActive


tester8900
  • Members
  • 18 posts
  • Last active: Dec 07 2009 05:24 PM
  • Joined: 23 Jan 2006
Thanks for the tip!

kapege.de
  • Members
  • 192 posts
  • Last active: Jan 16 2012 12:34 PM
  • Joined: 07 Feb 2005
... and for the poor with win98: Yes it works, but you need an additional line:
#IfWinExist, Notepad

^x::

    ; your sample code here

return

#IfWinExist

^x::send, {Ctrl Down}x

;----^^^^---- this one you'll need



; if you put a {CTRLUP} after the 'x' you have to release CTRL first and press it again afterwards for the next ctrl-command (e.g. ctrl-v).

Peter

Wisenheiming for beginners: KaPeGe (German only, sorry)

PhiLho
  • Moderators
  • 6850 posts
  • Last active: Jan 02 2012 10:09 PM
  • Joined: 27 Dec 2005

It looks safer, though, to use ahk_class ConsoleWindowClass, because the window title is often different.

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... :-)
Posted Image vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")