bypassing A_ variables

[jeeswg]

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.

[nnnik]

Autohotkey has to deal with PixelPositions a lot.
Implementing a built in class/type whatever that deals with this should be a goal regardless of this specific suggestion.
The specific usage of said type should not only be based on global settings.

[jeeswg]

- Ah OK, like X Y W H R B perhaps? Interesting.
- I had thought that storing a date as an object could be useful. Just to get a date including milliseconds reliably.

- Btw are there not some things a little like A_ variables in other languages/situations, e.g. these perhaps (cf. ErrorLevel, A_RegView x64/x32):
GetLastError function (Windows)
https://msdn.microsoft.com/en-us/librar ... s.85).aspx
Wow64DisableWow64FsRedirection function (Windows)
https://msdn.microsoft.com/en-us/librar ... s.85).aspx

- Also, would you really be happier if every time you used the Reg functions, you specified 64-bit or 32-bit? Do you sometimes value the convenience of A_ variables?

[nnnik]

- Btw are there not some things a little like A_ variables in other languages/situations, e.g. these perhaps (cf. ErrorLevel, A_RegView x64/x32):
GetLastError function (Windows)

The WinAPI is backwards compatible with its earliest versions. Not everything was a good decision.

Also I think that you are skipping a few steps here. You are asking me if I like the syntax you suggested then I would say no.
Saying that your syntax is the one and only possibility here is the first mistake.
I would turn the reg functions into a reg class and make the user pass the type upon construction.