What problem is this solving?
This was brought up before I started developing v2:
MouseClick, WhichButton [, X, Y, ClickCount, Speed, D|U, R]
-> Superceded by "Click"? But if so the swapping control panel thing might be a minor issue, perhaps too rare for the translator utility to worry about.
Source: AutoHotkey v2
I had it on my list to review the Click and Mouse functions for years - possibly since the beginning. I reviewed them multiple times, and only ever really acknowledged two issues:
- MouseClick "Left" corresponding to the left physical button, instead of the left logical button. This never made sense to me, and any use case I could think of seemed very unlikely.
- Click requiring its "parameters" in one string. In v1, this means no expressions by default. I saw it as more of an issue when the Click command was compared to Click(), because the latter required both parentheses and quote marks. The simple answer was to simply allow the options to be split across multiple parameters, and that was implemented in 2014:
It just isn't documented. You can already do this:
Code: Select all
ClickRelative := Click.Bind("Relative")
ClickRelative(100, 0)
... but I don't see how this is better than
defining a function.
Code: Select all
ClickRelative(p*) => Click("Relative", p*)
; ClickRelative(p) => Click("Relative " p) ; Also works, but prevents the use of multiple parameters.
ClickRelative(100, 0)
Now,
ClickRelative is a constant, guaranteed to be initialized before the script executes, and can be more readily identified as a function. It also has a
.Name, unlike the bound function.
When I changed MouseClick (v2.0-a110), I decided that there weren't any actual
problems remaining that warranted further changes, or delaying v2.0, or even further thought, so I removed it from the list. For reference, this is what I had in
v2-thoughts:
MouseClick has been superseded by Click. Should MouseClick be removed? Should Click be renamed to MouseClick, for consistency with MouseMove?
- Click automatically compensates if the user has swapped the left and right mouse buttons via the system's control panel. For example, `Click R` performs a logical right-click, which typically produces a context menu even if the user has swapped the buttons. On rare occasions, this automatic compensation may be undesired--some way to bypass it should be added. I am open to more specific suggestions.
- Click doesn't support the *Speed* parameter. SetDefaultMouseSpeed must be used instead.
- Click doesn't support the `R` (relative coords) parameter, which could be ambiguous with "R" for "Right".
- If MouseClick is removed (or replaced with Click), should MouseClickDrag also be removed? At the very least, the default behaviour when buttons are swapped should be equivalent to Click.
- Maybe the other Mouse commands should be changed to support flexible parameter ordering similar to Click.
I'm not sure what I was thinking about the "R" parameter; I might have missed the fact that Click supports "Rel" and "Relative".
Also, the plan was to release beta 1 in June or July. That does not mean "there's still time for breaking changes" up until the end of July. It means beta 1 should be
ready for release in June or July. If changes are made at the last minute and then turn out to be detrimental, you may be stuck with them until v3.0.
The purpose of changing the label from "alpha" to "beta" is to give some assurance that future releases will be backward-compatible. Removing functions or changing the meaning of parameters is just about the most obvious violation. I do not intend to make any more changes of that nature without very compelling reasons prior to v2.0 or v3.0.
Prior to v2.0 proper, I may change program behaviour in more minor ways that generally won't break scripts, such as to improve the usability of warning dialogs.