just me wrote:I'd prefer the order:
command, command options, controlandorwindow criteria:
Code: Select all
ControlMove [, X, Y, Width, Height, Control, WinTitle, WinText, ExcludeTitle, ExcludeText]
ControlSend [, Keys, Control, WinTitle, WinText, ExcludeTitle, ExcludeText]
ControlSetText [, NewText, Control, WinTitle, WinText, ExcludeTitle, ExcludeText]
WinSetTitle, NewTitle [, WinTitle, WinText, ExcludeTitle, ExcludeText]
WinMove [, X, Y, Width, Height, WinTitle, WinText, ExcludeTitle, ExcludeText]
This goes accord what you intend to do and what the point of the command is. You want to move a control, you use the controlmove, otherwise, you do not use that command. You want to send something, its natural (to me i guess) to want to get to get to the send first, since thats the point of the command.
It comes down to either object, or functional, or a hybrid of the two (how it kind of already is). While a control is subset of a window, to me, these control commands are somewhat overloaded, they are very spaghettish, they want to act on controls of a given window, on controls only, or on a window only (ahk_parent), then if you want to use the control's hwnd, you need to work with the window parameter instead of the control parameter itself. But to not derail im not going to elaborate on this.
Controlsend, control, windowstuff,..., keys would emulate functional, controlsend(control, windowstuff,..., keys) or control(send, control, windowstuff,..., keys), since from a purely functional standpoint, there are no 'objects' and you would need to specify the object you want to act on everytime. With the drawback of omitable parameters meaning act on "this" i.e last/topmost object, so it just throws the entire purpose of the commad towards the end and dirties up the parameter list if you want to act on "this" by having a bunch of empty parameters. While this form may look like OO because you are always specifying an object to act on (trying to emulate OO), it's not, its just an emulation for appearance's sake, if it were, the controlsend command would have the reference to the object itself and thats not possible. So, the purely functional approach throws the whole point of the command towards the end of it, i.e, it gives the purpose, the least importance.
Just me's suggestion (the one i agree with), Controlsend, keys, control, window would be more OO when acting on "this", i.e ctrl.send(keys), we already know the control, its this, or the last, topmost, whatever, so, the control object is implied and thus, ignored as a parameter. If you need to diverge from "this" object in the command, in which case it would be the non-default usage, then you specify the object to act on after the main purpose of the command has been set. It gives the most importance to the wholesome purpose of the command. You want to send something to a control? k, use controlsend, keys. It's not this implied control? then state what you want to send (since thats the reason why you are even using me), then tell me where to send it. Therefore, purpose first, and the object to act on is all grouped together.
The current way, the hybrid way, where the object to act on may not be grouped together, so, if you try an odd situation with a functional approach, wintitle and windowstuff are on the other side of purpose of the command. If you try oo on "this", you have a dead parameter right before the purpose of the command. Which can be the cause of the confusion, because the command itself is not prioritizing its own purpose. I want to reiterate we are working with AHK's unique command way of doing things, so purely functional is confusing and wasteful (overloaded), purely object is impossible.
TLDR, my opinion is that just me's approach sounds best since it prioritizes the actual purpose of the command, which would be the main reason why you would even use it. And don't try to emulate OO using a functional approach, because it will just make it messier.
