conversion logic, v1 = -> v1 := -> v2, two-way compatibility

Discuss the future of the AutoHotkey language
User avatar
jeeswg
Posts: 4782
Joined: 19 Dec 2016, 01:58
Location: UK

Re: conversion logic, v1 = -> v1 := -> v2, two-way compatibility

05 Jan 2018, 18:59

GENERAL REPORT ON CONVERSION ISSUES
- See also the 3 posts above.

GENERAL: VAR = VALUE -> VAR := VALUE
- You have to be careful with numbers with leading/trailing zeros e.g.:

Code: [Select all] [Download] GeSHi © Codebox Plus

var = 06
;goes to:
var := "06"
;not:
var := 06

- However, it has been suggested that when you do var = value, to var := "value", to always assume it's a string.

GENERAL: BLANK PARAMETERS: COMMANDS -> FUNCTIONS
- With commands, blank parameters and omitted parameters look identical.
- So parameters that I perceived as being omissible, were in fact compulsory, e.g. FileAppend (Text), RegWrite (Value). (Note: RegWrite's Value parameter is stated as compulsory but appears to be omissible.)
blanks in ternary operator - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=37&t=41575&p=189956#p189956

GENERAL: CONVERTING FUNCTIONS
- Let's say you have a script, and you've converted some lines, but not others. It will be easy to identify which lines are AHK v2 ready, and which lines still need to be converted.
- An exception is functions where the functionality has changed i.e. InStr/SubStr/RegExMatch/RegExReplace.
- E.g.

Code: [Select all] [Download] GeSHi © Codebox Plus

InStr(vPath, "\", 0, 1) ;not ambiguous: works the same in AHK v1/v2
InStr(vPath, "\", 0, -1) ;ambiguous: works differently in AHK v1/v2
InStr(vPath, "\", 0, vPos) ;ambiguous: works differently in AHK v1/v2 if vPos is non-positive

- It is like dates: 10/01/2017 is ambiguous (10 Jan or 1 Oct), but 20/01/2017 is not.
- So, if you want to be sure how the code is supposed to work for ambiguous cases of StartingPos, you should leave a comment (i.e. to say that it was written for AHK v1/v2). Although there could be multiple functions with ambiguities on the same line making this less feasible.
- What I do instead, is, whenever InStr is ambiguous, I replace it with JEE_InStr, which has the AHK v2 behaviour in both AHK v1/v2.
- I fully support the changes to InStr/SubStr/RegExMatch/RegExReplace. But I would warn that any *changes* to functions, that aren't simply extending the functionality, can cause a lot of complications and awkwardness. And that this should not be underestimated.
- A possible solution is to convert instances with a non-positive StartingPos, to (subtract 1 and) use InStr2 (AHK v2 behaviour on AHK v1/v2), and any instances that have a variable for StartingPos to use InStr1 temporarily (AHK v1 behaviour on AHK v1/v2) (which then have to be manually converted to use InStr2).
- I would also suggest a mode for AHK v1, where, if set, the 4 functions behave like they do in AHK v2. So that people can write more forwards compatible code that won't have to be converted manually later, and so that code can be more easily reused between AHK v1/v2, and because the StartingPos values are more logical/easier to use (more newbie-friendly). This is not an argument primarily inspired by two-way compatibility, the JEE_InStr idea can achieve that.

GENERAL: FUNCTIONS WITHIN FUNCTIONS
- When converting from commands to functions, some things become clear, like the benefit of not having subcommands.
- One other thing worth considering, is avoiding, where possible, functions within functions. These are the sorts of things you discover while playing around in AHK v2.

Code: [Select all] [Download] GeSHi © Codebox Plus

;e.g. proposal:
DateAdd(DateTime, Time, TimeUnits, Format)
;versus:
FormatTime(DateAdd(DateTime, Time, TimeUnits), Format)


GENERAL: CONTROLXXX FUNCTION NAMES
- I made some comments here, at the bottom of this post:
why was LoopParse (no space) removed? - Page 2 - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=37&t=41821&p=190742#p190742

GENERAL: XXXGETLIST FUNCTIONS
- Window list: WinGet-List -> WinGetList.
- Control list: WinGet-ControlList -> WinGetControls/WinGetControlsHwnd.
- Item list (items within control): - ControlGet-List -> ControlGetList (perhaps ControlGetItems).
- Re. counting items:
- WinGet-Count -> WinGetCount.
- WinGet-ControlList: There is no 'window get control count' option (unless you retrieve the pseudo-array).
- ControlGet-List has a count option.

CONTROLGETLIST (CONTROLGETITEMS?): STRING -> ARRAY
- Although returning an array as the default, instead of an LF-delimited string, makes sense (e.g. theoretically an item could contains LFs). It can be slow to build a string from an array, and to search for an item within an array. Thus an option to return a string may be sensible.
jeeswg's benchmark tests - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=7&t=37876&p=192029#p192029
- Also, this suggests the need for a StrJoin function, which many have already talked about. Here's *a* version, one question is whether a capacity parameter should be present or not (I would suppose not, and, perhaps AHK can roughly estimate the lengths of all strings in an array, and so the parameter wouldn't be necessary).

Code: [Select all] [Download] GeSHi © Codebox Plus

JEE_StrJoin(vSep, oArray*)
{
vOutput := ""
VarSetCapacity(vOutput, 1000000*2)
Loop, % oArray.MaxIndex()-1
vOutput .= oArray[A_Index] vSep
vOutput .= oArray[oArray.MaxIndex()]
return vOutput
}


CONTROLSETTAB
- Pretty awkward to convert. (This is not a complaint, just an interesting curio.)

Code: [Select all] [Download] GeSHi © Codebox Plus

;before:
Control, TabLeft, 3, SysTabControl321, A
Control, TabRight, 3, SysTabControl321, A
;after:
ControlSetTab(-3+ControlGetTab("SysTabControl321", "A"), "SysTabControl321", "A")
ControlSetTab(3+ControlGetTab("SysTabControl321", "A"), "SysTabControl321", "A")


DEREF: SHOULD IT BE KEPT?
- I have had a lot of problems in my scripts relating to Deref not being available. One use is to handle entries of the form '%dir%\MyFile.txt' loaded from ini files, or from the selected text.
- I think that this function, (including possible options to change the deref character(s), and support for environment variables, and perhaps for objects with keys, that I've previously mentioned,) would be very useful.
- I think it would be good to have Deref available and backport it to AHK v1 (which currently has it as a subcommand of Transform).
- This function cannot be recreated as a custom user-defined function.

FILEINSTALL
- I don't personally use FileInstall, but the FileInstall function does seem like a good candidate for being backported to AHK v1. Perhaps the only function that would *need* backporting, other than Deref.
FileInstall
https://autohotkey.com/docs/commands/FileInstall.htm
Extract file that was added with fileinstall - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?p=188235#p188235

PIXELGETCOLOR/PIXELSEARCH
- If these two functions allowed you to specify 'BGR', it would make automatic conversion a lot easier. Also RGB and BGR both appear commonly with regard to image scripts.
- The silliest (most nuanced) part of my converter so far, checks whether the pixel colour is the same in RGB and BGR, if it can't be sure, then it cannot safely convert that line, and so it omits it from the conversion, and adds it to the error list.

Code: [Select all] [Download] GeSHi © Codebox Plus

JEE_ColRGBIsBGR(vNum)
{
if RegExMatch(vNum, "^0x\d{6}$")
return (SubStr(vNum, 3, 2) = SubStr(vNum, 7, 2))
else if RegExMatch(vNum, "^\d+$")
return ((vNum && 0xFF0000 >> 16) = (vNum && 0xFF))
else
return 0
}


PROGRESS/SPLASHIMAGE: RECREATING THEM
- These are due to be removed from AHK v2.
- I am going to try to recreate these 2 commands as custom functions.
- AHK v2 doesn't let you specify the class of a GUI window, so there's at least that aspect that cannot be recreated currently, and so some of my scripts, that depend on the class name to identify the Progress windows, would have to be altered.
- I do feel that there will be other obstacles, perhaps some of them insurmountable, in trying to exactly recreate these commands with no loss of functionality, for example, to avoid making a script #Persistent.
- I am not sure, but I think that there are subtle optimisations and advantages that AHK GUI-like notification commands have, that a custom user-defined function can't reproduce.
- I have found these commands very useful when sharing scripts on forums, and doing diagnostic image/text/font tests. Once you have to manually include a custom function inside a script, and copy and paste it every time you want to use it on the forum, it's no longer newbie-friendly. Also, even if I did copy and paste the recreated Progress function, it might be exceedingly long and complicated.

REGEXMATCH: PSEUDO-ARRAY -> ARRAY
- RegExMatch will return an object in AHK v2, never a pseudo-array.
- However, the RegExMatch object is read-only, and so you can't edit the array items.
- I attempted to create a function that approximately recreates it, partly to understand everything that's in the object. I also provided an example script to recreate part of the object.
RegExMatch
https://autohotkey.com/docs/commands/RegExMatch.htm#MatchObject
RegEx: edit RegEx match object - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=5&t=40679

STRINGSPLIT -> STRSPLIT: PSEUDO-ARRAY -> ARRAY
- There are two options re. conversion with StringSplit. Create a pseudo-array manually, or replace the pseudo-array with an array (via StrSplit).
- Although I would recommend converting to StrSplit, and using a proper array, it can be very time-consuming and awkward to make all of the necessary adjustments, and this would have to be done manually. So for one of my big scripts with around 100 uses of StringSplit, I converted it to still use a pseudo-array, until I have the time to manually review the (very old) code.
- StringSplit can be replaced automatically (without the need for manual conversion to StrSplit) like so:

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus


- I would leave the comment 'string split' to indicate what is going on, and as a reminder to review the code at a future date.
- The following function could be useful for some circumstances:

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus



WINSETSTYLE
- The use of + and ^ presents a subtle problem in the move to function-style parameters.

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus


- It is mentioned in these two links:
WinSet
https://lexikos.github.io/v2/docs/commands/WinSet.htm#Style
Control Functions
https://lexikos.github.io/v2/docs/commands/Control.htm#SetStyle

GENERAL COMMENTS
- It's curious, instead of just manually fixing a particular code line, intellectualising it, in order to automate its conversion.
- Combining registry keys and subkeys is a bit awkward, after having already experienced most conversion problems, I suddenly found the need to 'clean' a function parameter, e.g. "a" "b" "c" -> "abc" (e.g. "HKEY_CLASSES_ROOT" "\" "txtfile" -> "HKEY_CLASSES_ROOT\txtfile").
- Some changes really make the simplicity clearer:

Code: [Select all] [Download] GeSHi © Codebox Plus

;before:
ControlGetFocus, vCtlClassNN, A
;after:
vCtlClassNN := ControlGetFocus("A")

- I also like how the parameters in RegWrite and WinMove have been rearranged to always be consistent. And I now really like the change from "" to `", which I wasn't initially sure about.
- I have already had this problem a few times, that of 'unconverting', e.g. to share an AHK v2 script in AHK v1 form on the forum, I will have to do work on an 'unconverter'. Luckily, my work on two-way compatibility has made this easier.
- For using AHK v1 and AHK v2 simultaneously for different scripts, an /inc switch, and also allowing A_AhkPath with #Include, would be incredibly useful.
- Perhaps every function that lacks a return value at present, should return 1 if there are no errors. And WinWait/WinWaitActive, could return an hWnd.
- 'GuiCtrlFromHwnd', 'Ctl'? 'Ctrl' seems a bit odd, and more reminiscent of keyboard keys.
- There has been mention that ahk_dhw/ahk_mode wouldn't break existing scripts so could be added at a later date, but I've always found the use of things like Last Found Window/A_StringCaseSense/A_DetectHiddenWindows/A_TitleMatchMode most unsatisfactory, and a huge amount of my code could be improved by WinWait/WinWaitActive returning an hWnd, ahk_dhw s/c(ontains)/(e)x(act)/e(nds)/r and ahk_mode vh/v/h being available, and a case sensitive StrReplace parameter being available (although in that case, RegExReplace could be used instead). There is also this issue:
DetectHiddenWindows bug? - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=14&t=30010
- I am reminded that, if feasible, having a way to redefine a built-in function, whilst having access to the original built-in function, could have advantages, allowing users to backport certain functionality manually. Otherwise, AHK users are completely dependent on changes to the source code.
- I would consider having ControlGetChoice as part of ControlGetList (aka ControlGetItems). Or as part of 'LBGetItems'/'CBGetItems', if they were separate functions. I am not against ControlChoose/ControlChooseString being one function per se, however, realistically this will add '+0' workaround awkwardness to yet another function. Sometimes the item strings are integers. (Note: I am quite neutral, and don't have strong opinions re. the topics in this bullet point.)
- It's interesting how ControlGet and Control have been combined in the AHK v2 help.
Control Functions
https://lexikos.github.io/v2/docs/commands/Control.htm
- What happened to the colour table from the Progress/SplashImage page?
Progress/SplashImage
https://autohotkey.com/docs/commands/Progress.htm#Object_Colors
Color Names
https://lexikos.github.io/v2/docs/misc/Colors.htm
- I have posted comments about parsing issues here:
parsing AutoHotkey scripts - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=5&t=40471
- Thanks for reading.
User avatar
jeeswg
Posts: 4782
Joined: 19 Dec 2016, 01:58
Location: UK

Re: conversion logic, v1 = -> v1 := -> v2, two-way compatibility

07 Jan 2018, 04:57

USING THE SAME LIBRARIES WITH BOTH AHK V1 AND AHK V2 SCRIPTS

- I've been thinking about the worst-case scenario, what if no changes are made, to the source code, that will deliberately or inadvertently make two-way compatibility easier.
Here is a potential approach (untested):
- AHK v1/AHK v2 are in completely different folders.
- The original library functions are in the AHK v2 Lib folder.
- The cloned library functions are in the AHK v1 Lib folder.
- When AHK v2 library scripts are saved, or AHK v1 scripts are run, the datestamps of the AHK v2 library scripts are checked, if a date has changed, then the AHK v2 script is converted/copied, 'converticopied', for use with AHK v1.
- This special conversion/copying is made as simple as possible.
- Loop lines have '% ' added, to force expression. I.e. lines that start with Loop that aren't within continuation sections.
- Any instances of `" are replaced with "". A potential false positive is an escaped grave e.g. "``". The simplest workaround is to replace "``" with Chr(96). There will be far fewer Chr(96)s needed than Chr(34)s. At present I'm using Chr(34)s to store double quotes, so I could just stick with that approach, and avoid converting double quotes.
- I haven't tested this all out yet, but it seems plausible.
- Perhaps now you can see why I'm tempted to hold out to see if the situation will get a little easier, before plunging into a particular strategy.
- These curious workarounds are preferable to maintaining separate/diverging versions of 40 libraries.
- Btw if I ever need/want to add something to a library that is AHK v2 only this is absolutely fine and doable, e.g. I can make addendum libraries resulting in something like 'MyClipboardLib', with the core functions, and 'MyClipboardLib+', with the additional AHK v2-only functions. Furthermore scripts can potentially become AHK v2 only, but it helps if libraries remain two-way compatible for the foreseeable future. Cheers.

- [EDIT:] I'm reminded of a fundamental problem with #Include, it is optimised to specify files relative to the path of the *script*, and not to the path of the *AHK exe*.
There is this:
Functions
https://autohotkey.com/docs/Functions.htm#lib
path-to-the-currently-running-AutoHotkey.exe\Lib\ ; Standard library.
- It's currently difficult however, AFAIK, for multiple exes to have both *shared* and *unique* (i.e. exe settings) library scripts at the same time.
- Hence a suggestion of something like:

Code: [Select all] [Download] GeSHi © Codebox Plus

#Include, %A_AhkPath% settings1.ahk
#Include, %A_AhkPath% settings2.ahk
;or:
#Include, %A_AhkPath% Dir\settings1.ahk
#Include, %A_AhkPath% Dir\settings2.ahk
coffee
Posts: 65
Joined: 01 Apr 2017, 07:55

Re: conversion logic, v1 = -> v1 := -> v2, two-way compatibility

09 Jan 2018, 21:29

jeeswg wrote:- [EDIT:] I'm reminded of a fundamental problem with #Include, it is optimised to specify files relative to the path of the *script*, and not to the path of the *AHK exe*.
There is this:
Functions
https://autohotkey.com/docs/Functions.htm#lib
path-to-the-currently-running-AutoHotkey.exe\Lib\ ; Standard library.
- It's currently difficult however, AFAIK, for multiple exes to have both *shared* and *unique* (i.e. exe settings) library scripts at the same time.
- Hence a suggestion of something like:

Code: [Select all] [Download] GeSHi © Codebox Plus

#Include, %A_AhkPath% settings1.ahk
#Include, %A_AhkPath% settings2.ahk
;or:
#Include, %A_AhkPath% Dir\settings1.ahk
#Include, %A_AhkPath% Dir\settings2.ahk

For manual includes, if you don't specify a folder then yes, it's relative to script dir. If you specify an allowed directory with the % signs, or a directory path, manual includes are relative to that directory.
Directory: Specify a directory instead of a file to change the working directory used by all subsequent occurrences of #Include and FileInstall. Note: Changing the working directory in this way does not affect the script's initial working directory when it starts running (A_WorkingDir). To change that, use SetWorkingDir at the top of the script.

https://autohotkey.com/docs/commands/_Include.htm

Unless i'm misinterpreting, why a_ahkpath? that's a full path to the executable file... why not a_ahkdir? You can just do

Code: [Select all] [Download] GeSHi © Codebox Plus

#include %a_ahkdir%
#include file_in_ahkdir.ahk
;or
#include dir_in_ahkdir\file.ahk



In script.cpp @ isdirective function, look for

Code: [Select all] [Download] GeSHi © Codebox Plus

		StrReplace(parameter, _T("%A_ScriptDir%"), mFileDir, SCS_INSENSITIVE, 1, space_remaining); // v1.0.35.11.  Caller has ensured string is writable.
StrReplace(parameter, _T("%A_LineFile%"), Line::sSourceFile[mCurrFileIndex], SCS_INSENSITIVE, 1, space_remaining); // v1.1.11: Support A_LineFile to allow paths relative to current file regardless of working dir; e.g. %A_LineFile%\..\fileinsamedir.ahk.


Add under it

Code: [Select all] [Download] GeSHi © Codebox Plus

		StrReplace(parameter, _T("%A_AhkDir%"), mOurEXEDir, SCS_INSENSITIVE, 1, space_remaining);

Compile.

For the function autofind, you just tweak the FindFuncInLibrary function in script.cpp

For example, for a v2 executable, adding a "Lib v2" lookup, before "Lib", in the same directory of "Lib" (documents\autohotkey)
Look for

Code: [Select all] [Download] GeSHi © Codebox Plus

	#define FUNC_LIB_EXT EXT_AUTOHOTKEY
#define FUNC_LIB_EXT_LENGTH (_countof(FUNC_LIB_EXT) - 1)
#define FUNC_LOCAL_LIB _T("\\Lib\\") // Needs leading and trailing backslash.
#define FUNC_LOCAL_LIB_LENGTH (_countof(FUNC_LOCAL_LIB) - 1)
#define FUNC_USER_LIB _T("\\AutoHotkey\\Lib\\") // Needs leading and trailing backslash.
#define FUNC_USER_LIB_LENGTH (_countof(FUNC_USER_LIB) - 1)
#define FUNC_STD_LIB _T("Lib\\") // Needs trailing but not leading backslash.
#define FUNC_STD_LIB_LENGTH (_countof(FUNC_STD_LIB) - 1)


Add under

Code: [Select all] [Download] GeSHi © Codebox Plus

	#define FUNC_USER_LIB_V2 _T("\\AutoHotkey\\Lib v2\\") // Needs leading and trailing backslash.
#define FUNC_USER_LIB_V2_LENGTH (_countof(FUNC_USER_LIB_V2) - 1)


Increase #define FUNC_LIB_COUNT by 1

Add before user library look up (// DETERMINE PATH TO "USER" LIBRARY:)

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus


Which is the same code for the user library just using the changed definitions.
As dirty and quick as it can get.
User avatar
jeeswg
Posts: 4782
Joined: 19 Dec 2016, 01:58
Location: UK

Re: conversion logic, v1 = -> v1 := -> v2, two-way compatibility

09 Jan 2018, 22:06

What I want is something like this:

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus



So you are saying that it's relatively straightforward to implement? Are you sure it's that simple to implement? See lexikos's comment 'More variables supported = larger code', made here:
A_UserName to be allowed in #include - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=13&t=15926

Do you want to submit to GitHub, to add in support for A_Desktop/A_UserName/A_AhkPath to #Include. Or to add A_AhkDir to AutoHotkey? A lot of people have asked for #Include to support more variables.

Btw you also commented there about junction links. Could you expand on your comments, I couldn't work out how to implement a junction link solution.

- [EDIT:] I think you added some comments re. searching for an AHK v2 Lib since I posted. Having AHK look for a folder called 'Lib v2' is a nice idea, although I tend to look for pure, general solutions, e.g. add support for a few more variables to #Include, and add an /inc command-line switch.
- Thanks again for sharing your C++ expertise. I will be doing more work in C++, and thus I should be able to propose base code in C++ for my wish list ideas. It doesn't mean that they'll be implemented, but I can at least do that.
coffee
Posts: 65
Joined: 01 Apr 2017, 07:55

Re: conversion logic, v1 = -> v1 := -> v2, two-way compatibility

09 Jan 2018, 22:24

jeeswg wrote:What I want is something like this:

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus



So you are saying that it's relatively straightforward to implement? Are you sure it's that simple to implement? See lexikos's comment 'More variables supported = larger code', made here:
A_UserName to be allowed in #include - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=13&t=15926

Do you want to submit to GitHub, to add in support for A_Desktop/A_UserName/A_AhkPath to #Include. Or to add A_AhkDir to AutoHotkey? A lot of people have asked for #Include to support more variables.

Btw you also commented there about junction links. Could you expand on your comments, I couldn't work out how to implement a junction link solution.

Well, it is what he said, str replace after str replace. It's true. What I posted does an extra str replace for a_ahkdir and the autofind is just a copy of the user lib look up.
the a_ variables in include dont use the same functions as the a_variables in script body. Basically, a_ahkdir not existing for the script to use, does not prevent you from using a_ahkdir in #include. The variable holding exe dir already exists in the script class.
The a_Ahkdir BIV can probably be copied from autohotkey_h's source. As it is implemented there.

For A_Desktop or others, it's a little bit different.
You edit the isdirective function, just a little bit lower than what I posted, after the a_appdatacommon replacement, adding

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus


Bunch of str replaces, in the purist sense of the word, it may not be "good maintainable code", as you are repeating yourself. If you decide to change implementation on one, then you probably will have to change the others manually. I'm pretty sure that can be done in a more speedier manner by shortcircuiting each replacement since they are absolute paths, i.e they are mutually exclusive for #include. Probably making the rest "else ifs" instead of "ifs" is the fastest way to achieve it. I just followed the pattern, i'll try else ifs later. You can also redo that entire block inside a loop using an array of the variables to replace maybe? *shrugs*

Then you have to go into the BIV_SpecialFolderPath in script2.cpp and add inside the switch

Code: [Select all] [Download] GeSHi © Codebox Plus

	case 'M': // A_MyDocuments(Common) -> C:\Users\Username\Documents
aFolder = aVarName[13] ? CSIDL_COMMON_DOCUMENTS : CSIDL_MYDOCUMENTS;
break;
case 'U': // A_UserProfile -> C:\Users\Username
aFolder = CSIDL_PROFILE;
break;


As for whatever it is you are trying to do with the includes, I wouldn't use the same folder for autohotkey executables versioning. It will fuck up ahk2exe and is not organized.


I'm not really doing any expertising here, i'm just copy pasting what's already in the code. It's just that, opening the solution in visual studio makes the code more visualizable (may not be a valid word) as you can jump into definitions/declarations, view call hierarchies, find all references, etc. Unlike opening it with a text editor.

edit:

Code: [Select all] [Download] GeSHi © Codebox Plus

;note: using A_AhkDir may not be necessary since you can do:
;path-to-the-currently-running-AutoHotkey.exe\Lib\ ; Standard library.

"#include path-to-directory" does not change the behavior of autoincludes, the standard library is only for auto includes or pulling with < > and it doesnt exist either in user or local. You can pull from a subfolder in one of the libraries if you use <subfolder\file> but you can't choose from which library to do it (fringe/testing case).
I've only used that very very few times, for testing stuff only, and it wasn't for the lib folder, but for another folder inside ahk dir when ahk dir is not script dir, or a file in a subfolder inside the standard library that also existed in the same directory tree format in the user library. They are simply QOL, you can always type the path statically.

By default "#include file.ahk" is relative to scriptdir. If I want a file in ahk's dir (even in ahk dir root), then it's just QOL using a_ahkdir over c:\parent folder\autohotkey <insert variant/version/suffix>\subfolder-or-file.ahk
If i want a guarantee that the pull will be from the standard library for a given executable, #include %a_ahkdir%\lib\file.ahk when file.ahk can exist in the other two.
For a_ahkdir they are such fringe cases, that can be fixed by moving files around during normal use, that doesnt really warrant a permanent addition. But this is in no one else's binary so I dont give a shit.
I also a use a mini preparser that selects the executable to use at runtime based on what the script has specified, for whatever I was using it then, i'm sure it was easier than typing full paths for whatever I was trying to test.
In the same usage, if <file> is pulling from local, and you want to pull from user, %a_mydocuments%\autohotkey\lib\file.ahk. I mean, the real world use cases are spotty almost always if you maintain an organized library, which is why I understand the hesitation of adding a bunch of variables for a < 1% scenario.

edit2:
CSIDL_PROFILE in the switch statement is for the user's folder full path. Not just the username. I don't see username in here as it is obviously not a folder, could just be a matter of grabbing it from the string.

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus

User avatar
derz00
Posts: 495
Joined: 02 Feb 2016, 17:54
GitHub: derz00
Location: Middle of the round cube

Re: conversion logic, v1 = -> v1 := -> v2, two-way compatibility

10 Jan 2018, 07:54

Looks like Lexikos is working on it: v1.1.28.00 is beta-release, and has support for all built-in variables in #include. https://autohotkey.com/boards/viewtopic ... 24&t=42628
try it and see
...
User avatar
jeeswg
Posts: 4782
Joined: 19 Dec 2016, 01:58
Location: UK

Re: conversion logic, v1 = -> v1 := -> v2, two-way compatibility

18 Jan 2018, 11:17

Yes, this is pretty special. Force-local in the Christmas updates, and now, since 10th Jan, #Include %A_XXX%. AutoHotkey now has the two main features that I felt it really needed. I was sat staring at the screen for two days. I had no idea that these updates were coming. Cheers.
User avatar
jeeswg
Posts: 4782
Joined: 19 Dec 2016, 01:58
Location: UK

Re: conversion logic, v1 = -> v1 := -> v2, two-way compatibility

23 Jan 2018, 04:30

AUXILIARY FUNCTIONS: PIXELGETCOLOR / PIXELSEARCH

v2-changes
https://autohotkey.com/v2/v2-changes.htm
PixelSearch and PixelGetColor use RGB values instead of BGR, for consistency with other functions.
- To convert such lines using built-in functionality only, you would need a 'BGR to RGB' function, unless BGR parameters were added to the PixelXXX functions.

AUXILIARY FUNCTIONS: CONTROLXXX

v2-changes
https://autohotkey.com/v2/v2-changes.htm
ControlMove, ControlGetPos and ControlClick now use client coordinates
- To convert such lines using built-in functionality only, you would need separate window-mode functions (or some other more fiddly solution), unless something like A_CoordModeControl := "Window" was added to AHK v2.

VAR++ / VAR-- / VAR += N / VAR -= N

- In the past, incrementing/decrementing an empty string, was equivalent to incrementing/decrementing 0. But no longer since AHK v2.0-a084-72186a7 (alpha). It could be difficult to spot instances of this, although this change seems like the right thing to do (tough but right).
- Link:
AutoHotkey v2 alpha (UPDATES) - Page 2 - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=37&t=2120&p=195810#p195810

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus

- Some ideas for recreating the existing var++ functionality, that treats a blank string as 0.

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus

- For most situations just add var := 0, to make a script work as before, but for some hotkey subroutines, you don't want the value reset to 0 when you run it, hence, the workarounds can be useful.
User avatar
jeeswg
Posts: 4782
Joined: 19 Dec 2016, 01:58
Location: UK

Re: conversion logic, v1 = -> v1 := -> v2, two-way compatibility

26 Jan 2018, 20:07

CONVERTING COMMANDS THAT I DON'T USE

I'm nearing completing my converter script, still to do: [EDIT: All done.]
- make sure all commands are supported (i.e. commands that I don't use) (DONE)
- (check that all ControlXXX/DriveXXX/ProcessXXX/WinXXX subcommands are fully supported)
- tidy converter script, ready to present
- test converter script on my main function libraries
- (update AHK v2 functions for AHK v1)
- (update general conversion advice list)

- After writing code to convert the functions I don't use, I would say:
- StringXXX. Make it absolutely obvious that StringGetPos, StringMid, StringReplace and StringSplit are deprecated. They are a barrel of fun to convert. [EDIT: Done. 'Deprecated' warnings have been added to the documentation for multiple functions.]
- OnExit. The OnExit command supports a label, but the new OnExit function does not. So this would have to be converted manually.
- SysGet/MonitorGetXXX. I wasn't sure if any of the MonitorGetXXX functions outputted arrays. In fact, they don't. MonitorGet/MonitorGetWorkArea each output 4 ByRef variables, similarly to WinGetPos. Which is a good solution.
- FileReadLine. This will be removed, I have a curious replacement for it below. I.e. a converter script should make it possible to convert anything, wherever possible (although certain command conversions may be turned off by default).
- WinGetActiveStats. This will be removed, it is a curious command, as you need two functions to replace it, see an example below.
- GetKeyState. It was awkward to convert from the GetKeyState command to the GetKeyState function, without using any temporary variables. I have made an attempt below. Hacker's delight.
- ... Since any scripts using the GetKeyState command will expect D/U/(blank), my conversion script should retrieve 1/0/(blank) as the function does, and convert it to D/U/(blank). The trick is to pass the 1/0/(blank) to an array, which then outputs D/U/(blank) accordingly.
- ... I would recommend that users convert the GetKeyState command to the GetKeyState function manually, and remove all references to 'D' or 'U'.
- Transform. The command is curious, and it has a lot of functionality duplicated elsewhere, but it is reasonably straightforward to convert.

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus

User avatar
jeeswg
Posts: 4782
Joined: 19 Dec 2016, 01:58
Location: UK

Re: conversion logic, v1 = -> v1 := -> v2, two-way compatibility

02 Mar 2018, 07:44

CONVERTER COMPLETED

AHK v1 to AHK v2 converter - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=37&t=36754

MOUSECLICK REVISITED

- I've improved my ideas from here slightly by introducing Swap0/Swap1:
conversion logic, v1 = -> v1 := -> v2, two-way compatibility - Page 5 - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=37&t=27069&p=180247#p180247
- I would suggest MouseClick (or Click) and MouseDrag (or MouseClickDrag).
- I don't like the 'clever' parameters in Click. I find '2' to mean double-click, but '2,3' to mean single-click at (2,3) to be confusing.
- I would have a writable variable A_MouseSwapButtons (or another name) that has a default value equal to SM_SWAPBUTTON (1 or 0). SM_SWAPBUTTON corresponds to:
Control Panel\Hardware and Sound, Mouse,
'Switch primary and secondary buttons'

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus


My expectation would be something like this, to allow mathematics to be performed on the coordinates, and then a space-separated list of options. 'D' for destination.

Code: [Select all] [Download] GeSHi © Codebox Plus

MouseClick(11, 22, "R Rel")
MouseDrag(11, 22, 33, 44, vOpt)
Send("{Click X11 Y22 R Rel}")
Send("{Click X11 Y22 DX33 DY44 " vOpt "}")

Options with approximate likelihood of usage:
WhichButton Rel Speed ClickCount Event Swap0/Swap1

There could also be options to temporarily override:
SendMode Input|Play|Event|InputThenPlay
e.g. SMI/SMP/SME/SMIP and/or A_SendModeMouse. Perhaps a 'Normal'/'Basic' mode (or another name) is needed. [EDIT:] Reading through the documentation, I think that 'Event' *is* the normal/basic mode in AHK v1, so 'Normal'/'Basic' modes wouldn't be needed.
User avatar
jeeswg
Posts: 4782
Joined: 19 Dec 2016, 01:58
Location: UK

Re: conversion logic, v1 = -> v1 := -> v2, two-way compatibility

01 May 2018, 09:48

THREAD COMMAND
- Maybe 'ThreadBlockTimers'?
- I'd be tempted to replace 'Thread' and most of the settings commands with writable 'A_' variables.
- Otherwise IMO 3 having separate ThreadXXX functions is preferable to having 1 Thread function, as double quotes are avoided, and it looks neater.

VARSETCAPACITY
- (Essentially 'length' is the size of something, 'capacity' is the size of something plus the size of extra available unused space.)
- This is an idea:

Code: [Select all] [Download] GeSHi © Codebox Plus

VarSetLen(Var, Size, FillByte) ;[bytes] [or 'VarSetSize']
VarSetCapacity(Var, Capacity, FillByte) ;[bytes] [as it is now]
StrSetLen(Var, Len, FillChar) ;[chars]
StrSetCapacity(Var, Capacity, FillChar) ;[chars]
- One question is whether all of these would overwrite any existing data. If so, then StrSetLen could cause people to accidentally lose their data.

OBJECT IDEAS
- I've tried to collect/anticipate the solutions to the core problems regarding objects that general users face.
objects/object classes: new features from a newbie-friendly perspective - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=5&t=42135&p=214283#p214283

ORIGINAL AUTOHOTKEY V2 DISCUSSION THREAD
- Interesting. I enjoyed infogulch's comments in particular.
AutoHotkey v2 Alpha Release - Scripts and Functions - AutoHotkey Community
https://autohotkey.com/board/topic/65311-autohotkey-v2-alpha-release/
guest3456
Posts: 2355
Joined: 09 Oct 2013, 10:31

Re: conversion logic, v1 = -> v1 := -> v2, two-way compatibility

01 May 2018, 10:01

for function name changes such as RegisterCallback -> CallbackCreate, we used this solution in the GDIP v2 lib:

https://github.com/mmikeww/AHKv2-Gdip/b ... 2819-L2820

User avatar
jeeswg
Posts: 4782
Joined: 19 Dec 2016, 01:58
Location: UK

Re: conversion logic, v1 = -> v1 := -> v2, two-way compatibility

02 Aug 2018, 19:08

- I've been considering using the double-deref hack in my function libraries to make loops forwards compatible. 'Write once, run anywhere' to coin a phrase. (It's a little verbose however, requiring 4 extra lines prior to the file loop in the example below. In case anyone has any suggestions.)
- I also present 'is version 1' checks for InStr/RegExMatch/RegExReplace/SubStr. I.e. to check the behaviour of the function itself, is more reliable than depending on A_AhkVersion.

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus


- Here are some small ideas for 'Loop' and 'if var is type' that would make it easier to write forwards compatible code in AHK v1:

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus

guest3456
Posts: 2355
Joined: 09 Oct 2013, 10:31

Re: conversion logic, v1 = -> v1 := -> v2, two-way compatibility

02 Aug 2018, 21:11

jeeswg wrote:- I also present 'is version 1' checks for InStr/RegExMatch/RegExReplace/SubStr. I.e. to check the behaviour of the function itself, is more reliable than depending on A_AhkVersion.

why is it more reliable?


jeeswg wrote:

Code: [Select all] [Download] GeSHi © Codebox Plus

;before
if var is % vType

;after [two-way compatible if use parentheses]
if (var is vType)

eh, no.
in v1, if var is type is an if-command, and so parens wouldn't work because is isn't an expression operator in v1:

Code: [Select all] [Download] GeSHi © Codebox Plus

var := "hello"

if (var is integer)
msgbox true
else
msgbox false


we do it this way in GDIPv2:
https://github.com/mmikeww/AHKv2-Gdip/b ... .ahk#L2773

User avatar
jeeswg
Posts: 4782
Joined: 19 Dec 2016, 01:58
Location: UK

Re: conversion logic, v1 = -> v1 := -> v2, two-way compatibility

02 Aug 2018, 21:41

- It's possible that the user might replace the function with a custom function.
- Also, in the future, there *might* be an 'AHK v2' mode for AHK v1. Where the function behaviour could change, or always be 'AHK v2' style within a script.
- (Then there's the question of reliably checking A_AhkVersion. It's unlikely to go wrong, but this method is a pure one.)

- Good point re. 'is', thanks, I see that contains/in/is are only listed for AHK v2.
Variables and Expressions - Definition & Usage | AutoHotkey
https://autohotkey.com/docs/Variables.htm#Operators
Variables and Expressions - Definition & Usage | AutoHotkey v2
https://lexikos.github.io/v2/docs/Variables.htm#Operators
- (I'm aware of the 'breaking backwards compatibility' argument, but reserving those 3 words in AHK v1 seems justified, the current behaviour breaks the principle of least astonishment and leads to bugs. How many people use those as variable names, and should they!? As long as no silent errors are created.)
- Well I'd said I'd be happy with function version of contains/in/is in AHK v1/v2, (easier to implement,) and that still stands.

Return to “AutoHotkey v2 Development”

Who is online

Users browsing this forum: TAC109 and 3 guests