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

Discuss the future of the AutoHotkey language
User avatar
nnnik
Posts: 2187
Joined: 30 Sep 2013, 01:01
Location: Germany

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

29 Mar 2017, 01:44

Btw the function has to pass the output variable name as a string rather than as a ByRef variable, I don't know if there's a workaround for this.

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



A function which works in a similar way to SplitPath:
If someone has written a similar function, please post a link.

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


Please use Arrays instead of pseudo Arrays. They are always better than pseudo Arrays. As things are right now I would advertise against using your Converter.
Recommends AHK Studio
User avatar
jeeswg
Posts: 2199
Joined: 19 Dec 2016, 01:58
Location: UK

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

29 Mar 2017, 14:31

@nnnik

I've explained above the advantages of using 'StringSplit' for a small number of numbered variables (and a custom variant for named variables), over a numbered array. Btw I intend to use both arrays, and pseudo-arrays (of most likely fewer than 10 variables). There are some situations like the frequency counting of strings where arrays are far better than pseudo-arrays.

As ever, any converter of mine has everything *optional*, and keeping StringSplit in AHK v2 by replacing it with a custom function, would be turned *off* by default. It's a mindset, are variables evil? Do we have to use arrays for *everything*?

Sometimes I think this is the problem with programmers and indeed people generally, you get stuck in one paradigm, and then you get stuck in the opposite paradigm. I often move back and forth between ideas and explore numerous possibilities, by experience you find out what works best, what tweaks to make to your own programs, and the external programs you use.

For every paradigm, there is an equal and opposite anti-paradigm.

An example of developing functions. At the moment I am thinking that my StrIn and StrStarts/StrContains/StrEnds functions, should treat the needle text literally by default rather than as a comma-separated list, and that they should only be seen as lists if a character is specified in the delimiter parameter such as pipe or comma. I've also decided that Str(Trim)Left/Right should assume 1 character, if the length parameter is omitted, I'm somewhat surprised that the existing AHK functions don't do this already.

I have a converter script essentially finished, I'm just trying to make it more complete by making it ready for (almost) all outgoing commands, i.e. I'm adding in support for the commands I don't use personally.

My script converter, you might just lllike it.

==================================================

List of commands/functions being removed (58):

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



[EDIT:] List of commands/functions being removed (58) (replacement options):

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



The more awkward conversions, i.e. not one-liners that are easily parsed:
- pseudo-arrays to arrays (StrSplit, WinGetControls/WinGetControlsHWND/WinGetList, RegExMatch?/RegExReplace?)
- 'notification' functions currently have no replacements: Progress/SplashImage/SplashTextOff/SplashTextOn
- 'if var in/contains' currently have no replacements
- SetFormat (use the Format function on individual items, versus a SetFormat mode on all subsequent items)
- Return: the last parameter is returned (rather than the first parameter)
- objects: ComObjUnwrap and ComObjEnwrap
- also being removed: #MaxMem, #NoEnv, AutoTrim, SetBatchLines, FileReadLine, IfMsgBox, Transform (e.g. HTML subcommand, note that Deref will be a separate function)
- note: Process, WinGet and WinSet will no longer exist, and will be replaced with separate functions, however, this is reasonably easy to parse, the exception being the functions involving arrays: WinGetControls/WinGetControlsHWND/WinGetList
- note: the most awkward parameter changes: MsgBox/InputBox, InStr/SubStr, StrReplace (also: TrayTip, Sort, Loop, RegRead/RegWrite)
- note: inconvenient command removals that I plan to replace with custom functions: StringSplit, StringTrimLeft, StringTrimRight, StringLeft, StringRight

Key summary of changes:
v2-changes
https://autohotkey.com/v2/v2-changes.htm

[EDIT:]
Process, WinGet, WinSet will be removed, and replaced with more specific functions:

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



==================================================

Btw I have been making parameter summaries for each command: e.g. 'SplitPath IBBBBB', (or which is in effect simply 'BBBBBB'), there basically seems to be 2 types of parameter, 'ByRef' and normal, but sometimes parameters can be a bit of both, so if all the possible parameter properties can be clearly defined and given names, that would be helpful. I.e. how many 'types' of parameter are there, 'ByRef', 'normal', is there only one type of 'hybrid' or multiple types of 'hybrid'. If I recall correctly PostMessage/SendMessage had particularly flexible parameters.

ByRef:
Cmd, var -> Func(var) (stays the same)
Cmd, var%var2% -> Func(var1%var2%) (stays the same)

normal:
Cmd, text -> Func("text")
Cmd, %var% -> Func(var)
Cmd, % "text" -> Func("text")
Cmd, % var -> Func(var)
Cmd, % var%var2% -> Func(var%var2%)

normal (nonstandard):
Cmd, var -> Func(var)

[EDIT:]
E.g.
Variables and Expressions
https://autohotkey.com/docs/Variables.htm
For backward compatibility, command parameters that are documented as "can be an expression" treat an isolated name in percent signs (e.g. %Var%, but not Array%i%) as though the percent signs are absent. This can be avoided by enclosing the reference in parentheses; e.g. Sleep (%Var%).
Last edited by jeeswg on 30 Mar 2017, 08:53, edited 14 times in total.
User avatar
nnnik
Posts: 2187
Joined: 30 Sep 2013, 01:01
Location: Germany

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

29 Mar 2017, 14:41

Using individual variables is slower and doesn't free ressources properly. You can use arrays with normal code and object code. You can't do that with variables.
Recommends AHK Studio
User avatar
jeeswg
Posts: 2199
Joined: 19 Dec 2016, 01:58
Location: UK

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

30 Mar 2017, 19:17

@nnnik. Interesting comments re. performance. If you or anyone has any further details as to why arrays would be faster than variables, that would be interesting to read up on.

You might say that variables are like walking, and objects are like running, and therefore you should never walk in your daily life. I, in fact, like arrays, especially for operating on big lists. And indeed some benchmark tests I have done, on reversing a list, suggest their speed.

How to optimize the speed of a script as much as possible. - Page 5 - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=7&t=6413&p=140139#p140139

Also, reflecting my love of objects/arrays, see:

case sensitive/case insensitive arrays (maintain key order, no key autosort) - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=5&t=29198
Firefox/Chrome, get tab names/focus tab - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=6&t=26947
log hotkeys, get extended hotkey info, interact with the *right* window (Hotkey command with FunctionObject example) - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=6&t=29560

==================================================

For the most part I have found workarounds for issues relating to AHK v2.

However this is one that really dismays me:

v2-changes
https://autohotkey.com/v2/v2-changes.htm
RegExMatch options O and P were removed; O (object) mode is now mandatory.


Note: it was StringSplit and not RegExMatch that caused my initial concern about variables v. arrays.

My obvious recommendation would be: V (variable) mode, otherwise, *potentially*, I could write a go-between function for RegExMatch, to achieve the old functionality. You have to understand that if there is no realistic benefit to using objects in such circumstances, (unless I want to, and I can already,) and if it's easier to write a go-between function than go through the hell of converting all the scripts, then reluctantly, I like the RegExMatch function, I will always use JEE_RegExMatch instead of RegExMatch, because presented with the situation, that is the best outcome, and that is what must happen.

I have done all sorts of conversions, and accepted all of the necessary burdens, but I really don't want to go through *ALL* my RegEx uses and convert all of these to objects.

As someone who supports the syntax changes, parameter alterations, command renaming and splitting, and general direction of travel, I hate it whenever I have the mindset, whenever I catch myself thinking: 'I wish we were still using AutoHotkey v1'.

The deep impact of some changes may not be immediately obvious.

These things were there for a reason, I wish people were more vocal about it. I don't mind a *LOT* of conversion, and I mean a *LOT*, for changing the names of things, or restructuring commands/functions, but removing functionality should really be advised against.

==================================================

I have collected some information which is crucial for conversion. It determines, when converting command parameters to function parameters, whether to treat them as variable names or as literal text. If anyone has done some similar lists I would be interested to know.

I think of the AHK commands as '1', '1X' and '2':
- '1' are the old commands to be kept.
- '1X' are the old commands to be removed.
- '2' are the new commands(/functions), some of which replace old commands.

Key:
'C' command name
'X' convert to expression style
'I' input variable name, don't convert
'O' output variable name, don't convert
'B' ByRef variable name, don't convert (e.g. WinGetPos, X Y W H variables)

The 'O' is very important because you get:
CmdOrFuncName, OutputVar, Param2, Param3
which becomes:
OutparVar := CmdOrFuncName(Param2, Param3)
The 'O' should only appear once per command. When there are multiple 'output' parameters, I usually label these as 'B'.

If I could introduce a 'hybrid' category, or different types of 'hybrid' category (if there is more than one type of 'hybrid'), this could help improve the converter. I don't mind not adding it in, however, if someone already had the information, or found it easy to produce a list, I could incorporate it. Otherwise, it just means a few more occasional manual corrections are required, after doing automatic conversion.

From experience, testing it, the list is good enough for almost perfect conversion, but I cannot 100% guarantee the accuracy of the list.

To generate such a list. Basically you download the help htms, from GitHub, or extract them from AutoHotkey.chm (via HTML Help or 7-Zip), and get everything within 'syntax' tags. Then you parse them, checking for references in the parameter names for Output/Input. Then you manually check them. Some commands like 'Click' and around 10 of the AHK v2 commands are not currently in any syntax html blocks.

This link has example syntax lists for AHK v1/v2, links to source htms, and a link with code, for extracting syntax text from htms:
commands as functions (AHK v2 functions for AHK v1) - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=37&t=29689&p=139582#p139582

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



Btw I could do with a reliable list of commands/directives/functions/variables.

This is what I've got so far, people might think that it looks definitive, but ultimately it's just a custom user's list, that could have omissions.
list of every command/function/variable from across all versions - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=7&t=27321&p=131642#p131642

It was not easy to find the full list of 'ComObj' and 'Obj' functions for example, which if it had been available would have been a great way to start learning about AHK's treatment of objects. I found out about #DerefChar and #Delimiter by accident. I actually had a conversion script issue, where conversion wouldn't take place because one source listed 'URLDownloadToFile', and then I realised it should have been 'UrlDownloadToFile'.

Thanks for reading.
Last edited by jeeswg on 25 Aug 2017, 13:13, edited 2 times in total.
just me
Posts: 4685
Joined: 02 Oct 2013, 08:51
Location: Germany

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

31 Mar 2017, 03:57

jeeswg wrote:... I will always use JEE_RegExMatch instead of RegExMatch, because presented with the situation, that is the best outcome, and that is what must happen.
You are free to use whatever you want. But why should others want to use it?

You are hell-bent on defining a 'two-way compatible' conversion logic. So try your best respecting the existing syntax rules. If you don't get it, let it be. Why should anything in v2 be changed just to simplify this task?
Remaining with AHK 1.1.25.02 until v2 will become beta.
lexikos
Posts: 5410
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

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

31 Mar 2017, 05:21

jeeswg wrote:You might say that variables are like walking, and objects are like running,
No, I wouldn't. I believe that mindset comes from the fact that objects can be used to do many things that are impractical to do with variables, and some of those things are complicated. When it comes to returning a list/array/sequence/collection of items, there are fewer reasons to recommend pseudo-arrays than arrays, especially to beginners. I think there is not a single case where I would recommend pseudo-arrays to a beginner. Arrays aren't any more complicated than pseudo-arrays if the comparison is restricted to common grounds, and are simpler in some cases.
These things were there for a reason,
Pseudo-arrays were there because arrays did not exist.
... removing functionality should really be advised against.
Functionality, especially redundant functionality, does not inherently have value just because it existed.

It was not easy to find the full list of 'ComObj' and 'Obj' functions for example,
It's not easy to find something when you're looking in the wrong place.

There is a full list of ComObj and Obj functions in the help file index. ComObjParameter, ComObject, ComObjActive, ComObjMissing, etc. are not functions; they are aliases for one function, which is listed as "ComObj...()" (when I wrote it, I thought the "..." would be very obvious). This is explained in the documentation.
... would have been a great way to start learning about AHK's treatment of objects.
I don't think so. I would not recommend the Obj functions as a starting point. I would not recommend the ComObj functions as a starting point for learning about AutoHotkey's objects, unless there is a practical reason (for example, if the user wants to automate a program with a COM API, that provides a good motive to learn).
If anyone has done some similar lists I would be interested to know.
Scintillua-ahk/ahk.lua uses such a list to provide accurate syntax highlighting for v1 and v2 (a077?) scripts. It is based on data that I scraped from the parts of the AutoHotkey source code which define the syntax. (The data was collected by a script I wrote, but I don't know where I put the script.)
User avatar
jeeswg
Posts: 2199
Joined: 19 Dec 2016, 01:58
Location: UK

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

17 Apr 2017, 21:25

A post by just me, prompted me to ask whether future code examples in the AHK documentation would use function-style or command-style notation.

Object.HasValue/Contains/KeyOf/FindValue - Page 2 - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=37&t=30536&p=143377#p143377

My preference would be that function-style notation would always be used.

I have also responded to a few of the comments above.

Btw I might release my converter within the next few weeks.

==================================================

@just me
The RegExMatch/RegExReplace problem is not a two-way compatibility problem. You can use the object 'O' mode in both AHK v1 and v2, and a variable can be used that is equal to 'O)' or 'O' for AHK v1, or blank for AHK v2.

The burden of conversion aside, using objects creates a few problems.

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

MsgBox, % vDate1 " " vDate2 " " vDate3 " " vDate4 " " vDate5 " " vDate6
MsgBox, % oDate.1 " " oDate.2 " " oDate.3 " " oDate.4 " " oDate.5 " " oDate.6
MsgBox, % v1 " " v2 " " v3 " " v4
MsgBox, % o.1 " " o.2 " " o.3 " " o.4


It's quite (very) awkward when you use a mix of variables and object key references in the same line. Therefore you are tempted to add additional lines simply to create variables in place of the object references. This reason alone is enough for me to believe that the variable 'V' mode for RegEx is worth maintaining, and was something I discovered since originally flagging up this functionality-removal issue, whilst writing new scripts using the RegEx 'O' mode.

Regarding script maintenance, it's very awkward to make sure you always include the '.' in 'object key as variable' ('PSEUDO-VARIABLE') names. Or double check: was it 'v' or 'o.', or that the '.' was in the right place. It's one of those unfortunate mental burdens I like to avoid while doing rapid, accurate and complicated programming.

Plus it looks uglier and takes up more horizontal screen real estate, significant on longer lines.

@lexikos
Are there not any other programming languages that create variable names based on a pattern e.g. var1/var2/var3, varX/varY/varW/varH, varY/varM/varD?

==================================================

Re. the index / command lists.

An index of commands is like the dictionary, you expect all the words to be there, you don't contemplate on the intelligent and reasonable justifications for omitting command names. If the index is not 100% complete, you would want to know if and where the alternative complete index is available.

Many thanks, I believe that you have done significant work to the command index, since I last wrote.

It's essentially perfect now, possibly I would add 6 items:
ComObject
Exception
IL_...
LV_...
SB_...
TV_...
and replace 'Trim' with 'Trim / LTrim / RTrim'.

(#AllowSameLineComments, #DerefChar and #Delimiter are missing but will be removed in AHK v2.)

The 'Scintillua' link you provided is excellent, many thanks. (I discovered that my list was missing Exception and TV_SetImageList.) I would advocate that such a list be available on the AHK help somewhere, possibly referenced at the top or bottom of the command index page.

==================================================

Re. objects.

One problem I had re. objects, was certainty, and in this regard collecting a list of the AHK functions and AHK help urls was a great start.

jeeswg's objects tutorial (not yet complete) - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?t=29232

I see a lot of quite-good users having trouble with ObjAddRef/ObjRelease/ComObjEnwrap/ComObjUnwrap, I am going to start a new post on Ask For Help for this, after a bit more research. The MSDN links in the help didn't add much. Btw appreciating the concept of reference counting, is not the problem, individual queries come up as you program.

Unfortunately for some AHK issues I think that maybe only half-a-dozen AHK users, if that, *really* know the answers, otherwise it's the blind leading the blind or half-truths, or answers that are based on experience and experimentation but not sound knowledge, especially for questions that are less Winapi-related and more AHK-specific.

We need to 'train' our users, and promote AHK, (including examples based on function-style notation,) to improve our pool of talent. We need to confront any major issues that are confusing the beginners, or as in this case, the experts also. I've been writing tutorials, collecting command/struct/DllCall information, and have been trying to present AHK v2 conversion issues to a wider audience ... there is more to come, including tutorials for: beginners, strings, maths, notes on commands, useful dll functions.
User avatar
nnnik
Posts: 2187
Joined: 30 Sep 2013, 01:01
Location: Germany

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

18 Apr 2017, 05:33

jeeswg wrote:It's quite (very) awkward when you use a mix of variables and object key references in the same line. Therefore you are tempted to add additional lines simply to create variables in place of the object references. This reason alone is enough for me to believe that the variable 'V' mode for RegEx is worth maintaining, and was something I discovered since originally flagging up this functionality-removal issue, whilst writing new scripts using the RegEx 'O' mode.
There is no logical reason to do this. So I guess this is personal preference.

jeeswg wrote:Regarding script maintenance, it's very awkward to make sure you always include the '.' in 'object key as variable' ('PSEUDO-VARIABLE') names. Or double check: was it 'v' or 'o.', or that the '.' was in the right place. It's one of those unfortunate mental burdens I like to avoid while doing rapid, accurate and complicated programming.
This is because you lack training yourself.
Recommends AHK Studio
User avatar
jeeswg
Posts: 2199
Joined: 19 Dec 2016, 01:58
Location: UK

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

10 Sep 2017, 14:39

READ BINARY DATA FROM A FILE TO A VARIABLE

Since changes were made to FileRead, I needed to come up with a two-way compatible solution.

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



==================================================

STRSPLIT TO ARRAY (CUSTOM KEY NAMES CF. NUMERIC)
STRSPLIT TO VARIABLES

Dealing with variables instead of object keys can have its advantages.
- E.g. to deal with variables, rather than a mix of variables and object keys, which can be a little awkward to type when some have dots, and some have not.
- E.g. brevity, extreme case: variables: 'a' 'b' 'c' v. object keys: 'o.a' 'o.b' 'o.c'.
- If you are frequently/almost always going to convert the object keys to variables after using RegExMatch, this is an argument for maintaining the RegExMatch variable mode. Otherwise you convert the keys to variables afterwards, not so bad, although somewhat inconvenient.
- Neither StringSplit nor StrSplit output to named variables/keys, something that could be potentially useful.
- If you write a custom function, you can't specify to create variables local to where the function was called from, hence I couldn't make a version of RegExMatch to maintain the variable mode, and I couldn't create a function that works exactly like or similarly to StringSplit to create a pseudo-array (e.g. v1/v2/v3, vY/vM/vD), which can be useful for a small number of variables.

I'm posting this code, partly because if variable mode is removed from RegExMatch, then you need a bit of code to convert the object to variables.

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



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

w:: ;RegExMatch results from array to variables
vDate := 20060504030201
RegExMatch(vDate, "O)^(?P<Y>\d{4})(?P<M>\d{2})(?P<D>\d{2})", o)
MsgBox, % o.Y " " o.M " " o.D
vList := "Y,M,D"
Loop, Parse, vList, % ","
v%A_LoopField% := o[A_LoopField]
MsgBox, % vY " " vM " " vD
return


==================================================

AHK V1/V2 CONVERSION ISSUES UPDATE

- It will be easier to both convert and maintain my scripts, by using my JEE_FileReadBin function above, than via other routes. [EDIT: I mention this as an example of how exploring two-way compatibility can make one-way and two-way conversion easier. As it happens, I very much welcome the new support for binary variables in AHK v2, see the updated FileRead function and the new ClipboardAll function.]
- AHK v2 doesn't have a satisfactory way of dealing with the double quotes in command line parameters yet. I came up with a CdLn workaround function, and some other suggestions, here:
AHK v2 and strings - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=37&t=36833
- Anyhow, whatever is done regarding double quotes or Deref, I now have a fairly good workaround, my CdLn function, for the biggest string problem I've faced related to conversion. Note: this is not about compromising code appearance for the sake of compatibility, it is difficult to find a nice solution for this in AHK v2 full stop.
- I don't see any obstacles at present to two-way compatibility (although it's always possible), apart from Loop. This, if added to AHK v1/v2 would solve the problem, otherwise you go two-way compatible as far as you can:
AutoHotkey v2 alpha (UPDATES) - Page 2 - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=37&t=2120
Experimental: Loop, LoopFiles, LoopRead, LoopReg and LoopParse now support a function-like syntax, where the entire parameter list is enclosed in parentheses and all parameters are expressions. OTB is also supported.

It would be easy to jump on that and argue for it to solve the two-way compatibility question, but I'm finding the 3 choices quite tough:
- Loop XXX or LoopXXX [EDIT: LoopXXX looks better for LoopFiles/LoogReg/LoopRead, and OK for LoopParse]
- 'Cmd, Arg' or 'Cmd Arg', and Func(Arg) [EDIT: using commas looks better/cleaner, and is more consistent, because you have a separator character between function name and first parameter]
- allow function syntax version [EDIT: my one reservation was that it might look like a function definition, but having woken up the next day, it looks pretty good]

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



==================================================

[EDIT:] MOUSECLICK

The Click command as it is, is very confusing (cf. MsgBox's 'smart' parameters), so I would recommend:

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

MouseClick, X, Y, Options
MouseDrag, X1, Y1, X2, Y2, Options
;or possibly:
MouseClick, Options, X, Y
MouseDrag, Options, X1, Y1, X2, Y2

Where Options is a space-separated list.

Possible names:
- Click/MouseClick (I would merge the two commands, and keep one name).
- MouseClickDrag (or possibly MouseDrag) (not great: ClickDrag, Drag).
- MouseMove.
- I would keep the name 'Click' for use with Send/SendInput.

'MouseDrag' is logical, although 'MouseClickDrag' has a certain elegance, and since (a) hotstrings, (b) lack of frequent use, I don't mind the longer 'MouseClick'/'MouseClickDrag' names. Choices. [EDIT: I did also consider 'Drag' by itself, but I don't feel inclined towards it. 'MouseDrag' is not bad/not good. I'm not sure whether 'ClickDrag' is an oxymoron or not.]

[EDIT:] Potentially a mini one-parameter format for Send {Click} could be: e.g. to drag the mouse: Send {Click x10 y10 xd10 xd20}, d for destination, e.g. to double-click the right mouse button: Send {Click x10 y10 r dc}, 'dc' or perhaps better 'c2' for double-click, perhaps 's10' for speed or 'd10' for a 10-millisecond delay, 'rel' for relative or 'cmr' for CoordMode Relative, 'u'/'d' for up/down (hold/release).
Last edited by jeeswg on 25 Sep 2017, 08:56, edited 1 time in total.
User avatar
jeeswg
Posts: 2199
Joined: 19 Dec 2016, 01:58
Location: UK

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

24 Sep 2017, 23:49

I noticed that A_ScriptName in AHK v2 is designated as read/write at present.
Variables and Expressions
https://lexikos.github.io/v2/docs/Variables.htm
The default title for MsgBox, InputBox, FileSelect, DirSelect and GuiCreate.

Which is good in the sense that I wanted to be able to change the default title, but I see the potential for mishaps here, and I like the idea of A_ScriptName as a robust, certain variable with fixed contents (cf. A_ScriptFullPath, A_AhkPath). I had thought perhaps that 'A_DefaultTitle' (or some other name) could be introduced.

I believe that A_InitialWorkingDir was introduced for greater consistency, while at the same time this would reduce consistency. I tend to avoid suggesting new built-in variables, but in this case I think it could be the best course of action.

Btw, how often is 'Title' used with MsgBox and InputBox. Especially if you can set the default title via a variable.

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

;I would prefer:
MsgBox(Text, Options, Title)
InputBox(Text, Default, Options, Title)
;to the current:
MsgBox(Text, Title, Options)
InputBox(Text, Title, Options, Default)

For InputBox, I use the prompt and default text all the time, whereas the Options would typically be used only to change the dimensions of the InputBox.

[EDIT:] MsgBox and InputBox are used very widely, so the parameter order is very important here. When I created my own InputBox function I had it as Text parameter 1, Default parameter 2, and it has proved the most practical approach.
User avatar
jeeswg
Posts: 2199
Joined: 19 Dec 2016, 01:58
Location: UK

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

25 Sep 2017, 11:58

For double quotes: "" works in AHK v1, `" works in AHK v2 (or " within single quotes).

\x22 for double quotes, saves a lot of bother in RegEx.

Similarly Chr(34) for general use.
User avatar
jeeswg
Posts: 2199
Joined: 19 Dec 2016, 01:58
Location: UK

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

02 Oct 2017, 09:58

It appears that ControlGetPos and ControlMove use Window mode in AHK v1, and Client mode in AHK v2. It also appears that this choice cannot be set.

A possible solution would be:
CoordMode, Control, Window|Client
and an A_CoordModeControl variable.

Alphabetical Command and Function Index
https://autohotkey.com/docs/commands/
Alphabetical Function Index
https://lexikos.github.io/v2/docs/commands/index.htm

[EDIT:] And ControlClick.
User avatar
jeeswg
Posts: 2199
Joined: 19 Dec 2016, 01:58
Location: UK

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

06 Oct 2017, 22:12

I mentioned here:
Wish List 2.0 - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=13&t=36789

>>> SetAhkV2Mode (or an alternative name)
- one mode, or granular settings, on/off, to make certain things function more like they do in AHK v2


I think it would be good to anticipate, in general, this as a solution, when changes are made in AHK v2 to control flow statements/directives/functions/variables. Note: I did not include commands in that list.

So far:
- InStr/SubStr/RegExMatch/RegExReplace (negative offset, RegExMatch object mode)
- A_OSVersion (number rather than string)
- Loop (a mode that when on interprets parameters as expression style in AHK v1)

Return to “AutoHotkey v2 Development”

Who is online

Users browsing this forum: No registered users and 3 guests