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.
bypassing A_ variables
Forum rules
Discuss Autohotkey related topics here. Not a place to share code.
Discuss Autohotkey related topics here. Not a place to share code.
bypassing A_ variables
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
Re: bypassing A_ variables
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.
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.
Recommends AHK Studio
Re: bypassing A_ variables
- 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?
- 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?
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
Re: bypassing A_ variables
The WinAPI is backwards compatible with its earliest versions. Not everything was a good decision.- 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)
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.
Recommends AHK Studio
Return to “General Discussion”
Who is online
Users browsing this forum: No registered users and 22 guests