Review the Click-family of functions Topic is solved

[swagfag]

perhaps while theres still time for breaking changes before going into beta(unless breaking changes can be introduced during beta, too)

Click is a function that accepts one parameter, a string of all kinds of "parameter" combinations
Click [Options]

• arguably more "flexible" design(u can only include the parameters u intend to modify)
• parameter list mimics the format used by Send('{Click the_parameter_list}')
• unconventional calling interface(one argument space- and/or tab- and/or comma-separated string of parameter)
• makes it hard to compose into other functions(eg cant just use .Bind('Relative') to create a specialized, custom ClickRelative([Options]), instead have to write out a full function definition)

MouseClick [WhichButton, X, Y, ClickCount, Speed, DownOrUp, Relative]

• looks like a normal function(and behaves like one. u can use .Bind(), variadically expand an Array of arguments into it, etc)
• the parameter list somewhat resembles that of MouseClickDrag(also the names are similar)
• often times u wont have to specify all parameters, so ull have to write ugly and confusing MouseClick(, -5, -5, , , , 'R')

maybe some of these functions arent needed anymore or can be merged. in v1 one reason for using Click was

NOTE: The Click command is generally more flexible and easier to use.
The Click command is generally preferred over MouseClick because it automatically compensates if the user has swapped the left and right mouse buttons via the system's control panel.

but i see thats different in v2:

MouseClick and MouseClickDrag are no longer affected by the system setting for swapped mouse buttons; "Left" is the always the primary button and "Right" is the secondary.

[lexikos]

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:

1. 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.
2. 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:

v2.0-a048-573f142
Improved Click to support function syntax better - Click(x, y).
Source: AutoHotkey v2 alpha (UPDATES) - AutoHotkey Community

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.

[swagfag]

It just isn't documented. You can already do this:

Code: Select all

ClickRelative := Click.Bind("Relative")
ClickRelative(100, 0)

cool, i didnt know it could do that

What problem is this solving?

in light of the above, none. although one could argue against having 3 similarly named functions that almost kinda do the same thing

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.

ok. i brought it up, since i was writing a script for a guy and these things struck me as odd while i was writing it. i dont usually use Click() very often

I'm not sure what I was thinking about the "R" parameter; I might have missed the fact that Click supports "Rel" and "Relative".

perhaps:

• Click() recognizes "Rel" and "Relative", but not "R"
• MouseClick() recognizes "R", but not "Rel" and "Relative"

---

I don't see how this is better than defining a function.

sometimes a function simply isnt needed or wanted. writing out the full declaration requires that u name the parameters and also pass them in. .Bind() allows for pointfree style definitions. there isnt a definitive reason for universally preferring one over the other