parameter order
Posted: 02 Mar 2018, 09:24
- In the previous 'Parameter order' thread, inconsistencies in the ControlXXX functions parameter orders were discussed.
Parameter order - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 37&t=30439
- I noticed a similar inconsistency with the ProcessXXX functions: all of them have PID-or-Name as the first parameter except for ProcessSetPriority. This is unhelpful in terms of a mnemonic device, and arguably breaks the principle of least astonishment/surprise.
Process
https://lexikos.github.io/v2/docs/comma ... m#Priority
- This would also be inconsistent with a possible future ProcessGetPriority function, e.g.:
- Also, in my opinion, this important change needs more discussion:
InputBox parameter order - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 37&t=39809
- Also, there is a quote here re. OnMessage:
v2-thoughts
https://autohotkey.com/v2/v2-thoughts.htm
- Although I would welcome radical changes if beneficial, I believe that this change would cause a lot of bother to users for no clear gain. AFAICS it's simple enough to just include all 4 parameters when you define the callback function. Also, there are good examples at the documentation page that omit certain parameters, suggesting that the current set-up has some advantages.
MsgMonitor(wParam, lParam, uMsg, hWnd)
Parameter order - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 37&t=30439
- I noticed a similar inconsistency with the ProcessXXX functions: all of them have PID-or-Name as the first parameter except for ProcessSetPriority. This is unhelpful in terms of a mnemonic device, and arguably breaks the principle of least astonishment/surprise.
Process
https://lexikos.github.io/v2/docs/comma ... m#Priority
- This would also be inconsistent with a possible future ProcessGetPriority function, e.g.:
Code: Select all
JEE_ProcessGetPriority(vPIDOrName:="")
{
static oArray := {0x40:"Low", 0x4000:"BelowNormal", 0x20:"Normal", 0x8000:"AboveNormal", 0x80:"High", 0x100:"Realtime"}
;ABOVE_NORMAL_PRIORITY_CLASS := 0x8000 ;BELOW_NORMAL_PRIORITY_CLASS := 0x4000
;REALTIME_PRIORITY_CLASS := 0x100 ;HIGH_PRIORITY_CLASS := 0x80
;IDLE_PRIORITY_CLASS := 0x40 ;NORMAL_PRIORITY_CLASS := 0x20 ;(idle: low)
local vPriority
if !(vPID := ProcessExist(vPIDOrName))
return 0
;PROCESS_QUERY_INFORMATION := 0x400
hProc := DllCall("kernel32\OpenProcess", UInt,0x400, Int,0, UInt,vPID, Ptr)
vPriority := DllCall("kernel32\GetPriorityClass", Ptr,hProc, UInt)
DllCall("kernel32\CloseHandle", Ptr,hProc)
return oArray.HasKey(vPriority) ? oArray[vPriority] : vPriority
}
InputBox parameter order - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 37&t=39809
- Also, there is a quote here re. OnMessage:
v2-thoughts
https://autohotkey.com/v2/v2-thoughts.htm
- I rarely use OnMessage for the AHK Gui v1 commands, and have been happy with the current parameter order.OnMessage: Someone (I was unable to find the post) suggested the parameter order for the callback functions be changed, possibly because hwnd is needed more often due to the removal of A_Gui.
- Although I would welcome radical changes if beneficial, I believe that this change would cause a lot of bother to users for no clear gain. AFAICS it's simple enough to just include all 4 parameters when you define the callback function. Also, there are good examples at the documentation page that omit certain parameters, suggesting that the current set-up has some advantages.
MsgMonitor(wParam, lParam, uMsg, hWnd)