bypassing A_ variables
Posted: 08 Oct 2018, 14:24
Following on from this post:
<> no longer acceptable as a comparison operator - Page 3 - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 02#p242602
- It can be advantageous to have functionality that is not dependent on A_ variables.
- Or you could have a changeable default setting, but you should be able to force a certain mode, bypassing the default.
- I'm not particularly opposed to any use of A_ variables. And don't feel particularly that AHK needs to be changed. Although I find the question a fair/interesting one.
- My one objection re. A_ variables is having to set A_StringCaseSense/A_DetectHiddenWindows/A_TitleMatchMode on and off, in scripts and functions. This can overcomplicate code, making it less readable/maintainable.
- However, the need to add case-sensitivity functionality to StrReplace, and something like ahk_dhw/ahk_mode, have already been established.
ALREADY IMPLEMENTED
- The GUIs in AHK v2 have moved away from using A_ variables.
- AHK v2 seems to be phasing out the use of ErrorLevel.
- There are 'Delay' variables but delays can be implemented via Sleep.
- A_FileEncoding can already be bypassed.
UNSURE
- AHK uses various A_ variables for hotkeys/hotstrings.
While I don't feel a change is needed. I'm not sure how this could be changed if desired.
OPERATORS
- CONTAINS and IN are based on A_StringCaseSense.
Solution: StrContains and StrIn(/StrExact) functions with a case-sensitivity parameter/setting.
- The following 5 operators: < <= > >= <> are based on A_StringCaseSense.
Solution: StrCmp with a case-sensitivity parameter.
LOOPS
- Loop File and Loop Reg use A_ variables.
Solution: custom enumerator classes, I've almost finished two such enumerator classes.
FUNCTIONS
- Case-sensitivity parameters should probably accept 'L' or 'Locale' for Locale. Not that I personally use Locale mode.
FUNCTIONS (EXTRA PARAMETERS)
- StrReplace would need a case-sensitivity parameter.
- I suppose the following would be necessary, if you wanted consistency:
- Reg functions would need a x64/x32 bitness parameter.
- InputBox would need a result parameter for OK/Cancel/Timeout if ErrorLevel was removed. (I would make this an A_ variable for convenience, whether ErrorLevel was removed or kept.)
- Control/Window functions would need a CoordMode parameter. Or separate CoordMode-based functions.
FUNCTIONS (COORDMODE)
- CoordMode affects: ToolTip/Pixel/Mouse/Caret/Menu functions.
ToolTip: Affects ToolTip.
Pixel: Affects PixelGetColor, PixelSearch, and ImageSearch.
Mouse: Affects MouseGetPos, Click, and MouseMove/Click/Drag.
Caret: Affects the built-in variables A_CaretX and A_CaretY. [CaretGetPos in AHK v2.]
Menu: Affects the Menu Show command when coordinates are specified for it.
- These would all need a parameter/setting to bypass the default CoordMode.
- I suggested an A_CoordModeControl variable for ControlClick/ControlGetPos/ControlMove, since AHK v1 uses Window coordinates and AHK v2 uses Client coordinates. This would need to be bypassed also.
<> no longer acceptable as a comparison operator - Page 3 - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 02#p242602
- It can be advantageous to have functionality that is not dependent on A_ variables.
- Or you could have a changeable default setting, but you should be able to force a certain mode, bypassing the default.
- I'm not particularly opposed to any use of A_ variables. And don't feel particularly that AHK needs to be changed. Although I find the question a fair/interesting one.
- My one objection re. A_ variables is having to set A_StringCaseSense/A_DetectHiddenWindows/A_TitleMatchMode on and off, in scripts and functions. This can overcomplicate code, making it less readable/maintainable.
- However, the need to add case-sensitivity functionality to StrReplace, and something like ahk_dhw/ahk_mode, have already been established.
ALREADY IMPLEMENTED
- The GUIs in AHK v2 have moved away from using A_ variables.
- AHK v2 seems to be phasing out the use of ErrorLevel.
- There are 'Delay' variables but delays can be implemented via Sleep.
- A_FileEncoding can already be bypassed.
UNSURE
- AHK uses various A_ variables for hotkeys/hotstrings.
While I don't feel a change is needed. I'm not sure how this could be changed if desired.
OPERATORS
- CONTAINS and IN are based on A_StringCaseSense.
Solution: StrContains and StrIn(/StrExact) functions with a case-sensitivity parameter/setting.
- The following 5 operators: < <= > >= <> are based on A_StringCaseSense.
Solution: StrCmp with a case-sensitivity parameter.
LOOPS
- Loop File and Loop Reg use A_ variables.
Solution: custom enumerator classes, I've almost finished two such enumerator classes.
FUNCTIONS
- Case-sensitivity parameters should probably accept 'L' or 'Locale' for Locale. Not that I personally use Locale mode.
FUNCTIONS (EXTRA PARAMETERS)
- StrReplace would need a case-sensitivity parameter.
- I suppose the following would be necessary, if you wanted consistency:
- Reg functions would need a x64/x32 bitness parameter.
- InputBox would need a result parameter for OK/Cancel/Timeout if ErrorLevel was removed. (I would make this an A_ variable for convenience, whether ErrorLevel was removed or kept.)
- Control/Window functions would need a CoordMode parameter. Or separate CoordMode-based functions.
FUNCTIONS (COORDMODE)
- CoordMode affects: ToolTip/Pixel/Mouse/Caret/Menu functions.
ToolTip: Affects ToolTip.
Pixel: Affects PixelGetColor, PixelSearch, and ImageSearch.
Mouse: Affects MouseGetPos, Click, and MouseMove/Click/Drag.
Caret: Affects the built-in variables A_CaretX and A_CaretY. [CaretGetPos in AHK v2.]
Menu: Affects the Menu Show command when coordinates are specified for it.
- These would all need a parameter/setting to bypass the default CoordMode.
- I suggested an A_CoordModeControl variable for ControlClick/ControlGetPos/ControlMove, since AHK v1 uses Window coordinates and AHK v2 uses Client coordinates. This would need to be bypassed also.