Jump to content

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

v1.0.43 released: Send keystrokes faster & more reliably


  • Please log in to reply
25 replies to this topic
Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
This release took longer than I'd announced earlier, so thanks for your patience.

NOTE: Although it has been extensively tested and is not expected to break any existing scripts, several changes were made to the sending of keystrokes and mouse clicks. If you have any mission-critical scripts that rely on such features, it is recommended that they be re-tested or that you wait two weeks for any bugs to get fixed.

Here are the changes for v1.0.43:

Fixed AltGr hotkeys that use Send, such as <^>!m::Send ^c. Also fixed AltGr remappings such as F1::RAlt [thanks foxer]

Fixed inability of VarSetCapacity to free the memory of a ByRef parameter. [thanks corrupt]

Fixed hotstring option b0 to show the ending character where you typed it rather than at the end of the replacement.

Improved the speed and reliability of auto-replace hotstrings by defaulting them to SendInput mode.

Improved the reliability of mouse clicks/drags in cases where the user is physically moving the mouse during the event.

Added command Click and Send {Click}, which are easier to use than MouseClick. They also compensate if the left/right mouse buttons have been swapped via the control panel.

Added command SendMode, which makes Send synonymous with SendInput or SendPlay rather than the default (SendEvent). It also makes Click and MouseMove/Click/Drag use the specified method.

Added two new methods for sending keystrokes and mouse clicks: SendInput and SendPlay. These are generally faster and more reliable. Also, SendPlay allows keystrokes and hotstrings to be accepted by a broader variety of games.


Remarks

If anyone has had trouble sending keystrokes and mouse clicks to particular games, I'd appreciate your feedback about whether SendPlay works for them (however, I'm pretty sure SendPlay won't work with all games, just more of them).

Also, if you discover that SendPlay works better with a key-delay higher than the default of "none", please let me know the details.

By the way, the name "SendPlay" is derived from the fact that this method uses the journal playback hook available in all operating systems. However, there are rumors that Windows Vista will have journal playback and record disabled by default (as a security precaution). It may require admin privileges to turn it back on, or worse.

Thanks.

Thalon
  • Members
  • 641 posts
  • Last active: Jan 02 2017 12:17 PM
  • Joined: 12 Jul 2005
Looks great! Posted Image

I think I'll test the new features soon!

Thalon

PhiLho
  • Moderators
  • 6850 posts
  • Last active: Jan 02 2012 10:09 PM
  • Joined: 27 Dec 2005
Hey, we didn't waited so long, and it has great improvements and features!
The new Click command will surely be popular and will reduce the amount of FAQ on how to do a continuous click.

Althought simple and perhaps in synch with similar commands, I am not a fan of the pure numeric options (X, Y, ClickCount). The current syntax may make them unambiguous, but it looks a bit corny as you use comma for them (in the examples) but not for the other options (comma is optional, I see).
Here, comma is used as option separator, in any order (except count), unlike most other commands where it is used as parameter separator in a more rigid order.

I would have prefered no use of comma at all, and prefixed values, à la Gui:
Click right x44 y55
Click ; Click at previously specified coordinates?
Loop 10
{
    x := 44 + A_Index * 10
    ; Clicks in a horizontal line
    Click right x%x%
}
Click c2 ; Double click on last coordinate
It allows to specify only one coordinate, to be consistent with the fact that no coordinates = previous coordinates.

It may be a bit late to change the syntax. Is it? There isn't so much scripts using the new command... Perhaps presenting the new command early and asking for ideas would have been fruitful (but may be confusing!). Anyway, I can live with the present syntax, I just wanted to submit some ideas.

Perhaps you should at least indicate that a click with coordinates updates the current position (is it so obvious?).

Using Click x y 0 to move the cursor without clicking sound a bit strange (click but no click...), but it is consistent, so it is OK for me. :-)
What does Click 0? (Nothing, I guess)

The examples at the start of the page are great to show the advantages of the new command, but then you should remove the redundancy with those at the end, perhaps providing alternate examples.
PS.: in the list of commands, I believe Click should be before ClipWait...
Posted Image vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

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

it looks a bit corny as you use comma for them (in the examples) but not for the other options (comma is optional, I see).

To me, coordinates look better with a comma: with only a space between them, they look almost like a single number.

I would have prefered no use of comma at all, and prefixed values, à la Gui:
Click right x44 y55

I considered using the prefixes but it didn't seem as friendly to me because it's more typing. Keeping in mind that 90% of all uses of Click are probably a simple "Click 100, 200". That's a lot of users who would have to type an X or Y prefix a lot of times. In addition, familiarity was a consideration, so it seemed best to make Click a lot like MouseClick (just more flexible and easier to type). Finally, using an X/Y prefix would have messed up the ability to directly copy & paste coordinates from Window Spy / Window Info.

; Clicks in a horizontal line
Click right x%x%

At various times in the past, I've considered supporting only a single coordinate. While tempting due to its coolness, when I considered how many people would actually use it, it seemed very low. In the end, the code and documentation complexity didn't seem worth the small benefit.

Click c2 ; Double click on last coordinate

One reason I opted against an option letter for the click-count is that it seemed harder to remember than knowing that the command is flexible enough to do what you want with the three numbers. I thought it would be easier to remember the ordering than a letter such as "C", but could be wrong.

Perhaps presenting the new command early and asking for ideas would have been fruitful (but may be confusing!).

That is something I've done in the past and intend to do again when I have doubt. In this case, the benefits seemed clearly in favor of the shortest possible syntax given how often clicking is needed in macros.

Perhaps you should at least indicate that a click with coordinates updates the current position (is it so obvious?).

It seems clear enough to me because it says "at the mouse cursor's current position". However, I'm not objective enough to see the weaknesses of the documentation the way a typical user would, so I'd welcome more discussion about this and other areas.

...remove the redundancy with those at the end, perhaps providing alternate examples.

It is my belief that many people skip reading the middle part of the page and go straight to the examples at the bottom. Assuming this is true, using the most common examples there (even though redundant) might be optimal.

I believe Click should be before ClipWait...

Thanks; I've fixed that.

I appreciate your quality feedback. Please send more whenever it occurs to you.

PhiLho
  • Moderators
  • 6850 posts
  • Last active: Jan 02 2012 10:09 PM
  • Joined: 27 Dec 2005
I agree with most of the reasons you gave. :-)
I trust you have more experience dealing with user tastes and preferences (at least at AutoHotkey level of use) than me, so that's OK.
Posted Image vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

Tekl
  • Members
  • 814 posts
  • Last active: May 03 2009 03:28 PM
  • Joined: 24 Sep 2004
Hi Chris,

what a great release.

Is there any disadvantage, when using SendMode, InputThenEvent?
Tekl

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
SendMode InputThenEvent may be preferred for scripts that were written prior to v1.0.43 and that want to use the SendInput mode in a more compatible way. This is because SendInput is very similar to SendEvent in terms of what is sent to the active window. However, since SendInput has no KeyDelay, applying it to an existing script may require re-testing.

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
Here are the changes for v1.0.43.01:

Fixed mouse clicking at unspecified coordinates in particular apps; e.g. Send {LButton} (broken by 1.0.43). [thanks incith]

Fixed tilde hotkeys so that if they remove a hook, their own key doesn't get stuck down (e.g. Mouse Gestures script and ~LCtrl::Hotkey, RButton, Off). [thanks Stefan Taubenberger]

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
Here are the changes for v1.0.43.02:

Fixed raw-mode hotstrings not to send the extra string {Raw} (broken by 1.0.43). [thanks stom2006]

Changed SendMode: 1) renamed InputThenEvent to Input; 2) added InputThenPlay, which is the same behavior as the former "Input". This was done because SendEvent is less likely to cause compatibility problems than SendPlay.

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
Here are the changes for v1.0.43.03:

Fixed distortion of 16x16 icons loaded via ahk2exe or Menu, Tray, Icon. [thanks Tekl]

Fixed the following to ignore #MaxMem as documented: VarSetCapacity(), FileRead, ClipboardAll, and ControlGet (ListView). [thanks Dippy46]

Changed the following to use locale case insensitivity vs. "A-Z only" insensitivity: Hotkey names, Hotstring abbreviations, Menu names, Input's MatchList, and Gui Tab.

Changed the expression equal operator (=) and the case-insensitive InStr() to use locale case insensitivity when StringCaseSense is Locale or On.

Improved StringCaseSense with a new option Locale that makes string comparisons case insensitive according to the rules of the current user's locale. For example, most English and Western European locales treat the letters A-Z and ANSI letters like Ä and Ü as identical to their lowercase counterparts. [thanks Boskoop & PhiLho]

Improved the Sort command and ListView sorting with a locale-case-insensitive option.

Improved mouse wheel hotkeys (WheelDown/Up) to report the number of wheel turns in A_EventInfo, which allows distinguishing between fast and slow wheel movement. [thanks evl]

Improved FileRead with an option to read only the leading part of a file. [thanks Dippy46]

polyethene
  • Members
  • 5519 posts
  • Last active: May 17 2015 06:39 AM
  • Joined: 26 Oct 2012

Improved FileRead with an option to read only the leading part of a file. [thanks Dippy46]

This has many useful purposes, thanks.

autohotkey.com/net Site Manager

 

Contact me by email (polyethene at autohotkey.net) or message tidbit


Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
In v1.0.43.04: Fixed crash of characters above Chr(127) in hotstring abbreviations and the locale-search-from-right mode of InStr() and StringGetPos (broken by 1.0.43.03). [thanks PhiLho & brotherS]

Serenity
  • Members
  • 1271 posts
  • Last active:
  • Joined: 07 Nov 2004

Fixed distortion of 16x16 icons loaded via ahk2exe or Menu, Tray, Icon. [thanks Tekl]


Thanks for fixing this.
"Anything worth doing is worth doing slowly." - Mae West
Posted Image

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
Here are the changes for v1.0.43.05:

Fixed and improved support for .ICL files (icon libraries), which was broken by 1.0.43.03. [thanks Tekl]

Changed case sensitivity in hotkey names back to pre-1.0.43.03 behavior: high ANSI letters like Ä and Ü are treated as different hotkeys than their lowercase counterparts. [thanks copa017]

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
Here are the changes for v1.0.43.06:

Changed ahk_id to operate directly on the specified HWND when it's a control (child). Previously, it operated upon the topmost sub-control if that control had any sub-controls.

Improved Post/SendMessage to fully support strings put into address variables by the receiver (e.g. PostMessage, Msg, &MyVar).

Improved support for control HWND as an alternative to control ClassNN: 1) Added a MouseGetPos option to retrieve control HWND; 2) Added "WinGet ControlListHwnd", which retrieves a list of control HWNDs; 3) Added "ControlGet Hwnd", which retrieves the HWND that corresponds to a control's ClassNN.

Added "GuiControlGet FocusV", which gets the focused control's variable name rather than its ClassNN.