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

Discuss the future of the AutoHotkey language
User avatar
nnnik
Posts: 2275
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: 2646
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: 2275
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: 2646
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: 4790
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: 5415
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: 2646
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: 2275
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: 2646
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 yd20}, d for destination (or drag), 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).

[EDIT:] dx10 dy10 for drag destination coordinates would be easier to parse, and are possibly easier to remember, and look better. E.g. {Click x10 y10 dx10 dy20} {Click x10 y10 r c2 rel}.
Last edited by jeeswg on 03 Nov 2017, 17:04, edited 2 times in total.
User avatar
jeeswg
Posts: 2646
Joined: 19 Dec 2016, 01:58
Location: UK

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

24 Sep 2017, 23:49

A_SCRIPTNAME: REMAIN READ-ONLY / GUI WINDOW TITLES

- It had been a minor wish list item of mine, to introduce something like 'A_DefaultTitle' or 'A_GuiTitle', but it was sufficiently minor that I never mentioned it on any of my wish lists.
- It appears that A_ScriptName in AHK v2 is now intended to fulfil this role, it is designated as read/write at present.
- But I see the potential for mishaps here, as scripts expect A_ScriptName to be a robust, certain variable with fixed contents (cf. A_ScriptFullPath, A_AhkPath).
- Note: I believe that A_InitialWorkingDir was introduced for greater consistency, while at the same time the current change to A_ScriptName would reduce consistency.

Variables and Expressions
https://lexikos.github.io/v2/docs/Variables.htm
The default title for MsgBox, InputBox, FileSelect, DirSelect and GuiCreate.

INPUTBOX FUNCTION: 'DEFAULT' AS 2ND PARAMETER

- MsgBox and InputBox are used very widely, so the parameter order is very important here.
- When I created my own InputBox function I had Text and Default as the first 2 parameters, I use the Text and Default parameters all the time, whereas I almost never use the Title/Options parameters.
- Also, an Options parameter is generally expected as the last parameter.
- So, if this applies to users generally and not just to me, then the following should be contemplated:

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

;currently:
InputBox(Text, Title, Options, Default)
;may be preferable to most users:
InputBox(Text, Default, Title, Options)

;note:
MsgBox(Text, Title, Options)
Last edited by jeeswg on 09 Nov 2017, 21:34, edited 3 times in total.
User avatar
jeeswg
Posts: 2646
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: 2646
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: 2646
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)
User avatar
jeeswg
Posts: 2646
Joined: 19 Dec 2016, 01:58
Location: UK

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

03 Nov 2017, 17:12

In anticipation of needing to write a Click/MouseClick 'AHK v2 function for AHK v1' at some point in the future, I've produced a JEE_MouseClick function, that may or may not be like the eventual AHK v2 function, however, the logic will be similar.

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.

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:
Options: WhichButton Rel Speed ClickCount Event IgnoreCP Swap

'Swap' and 'IgnoreCP':
- MouseClick: press the left button, a left click is sent.
- Click: press the left button, depending on the control panel setting, a left or a right click is sent.
- My function: use control panel setting (same as Click).
- My function plus 'Swap': opposite of control panel setting (opposite of Click).
- My function plus 'IgnoreCP': ignore control panel setting, 'left means left', 'right means right' (same as MouseClick).
- My function plus 'IgnoreCP' and 'Swap': ignore control panel setting, 'left means right', 'right means left' (opposite of MouseClick).
- Perhaps an 'A_' variable could be introduced, something like 'A_MouseButtonSwap' or 'A_MouseSwapButtons', with a value initially based on the Control Panel value, but that can bypass it, giving the user the ability to choose whether buttons are swapped or not.

I might have used the Click command as the basis instead of the MouseClick command, however, I find the statement on the MouseClick documentation page, that Click is 'easier to use' to be untrue. For example, how can I safely handle if one or more of X/Y/click count may or may not be blank. How exactly does it handle commas. Do I need to use MouseGetPos to explicitly state one or two of the values, if X or Y is blank.

Re.
v2-thoughts
https://autohotkey.com/v2/v2-thoughts.htm

Click doesn't support the R (relative coords) parameter, which could be ambiguous with "R" for "Right".

I'm a bit confused by this, by looking at the documentation for Click, I believe we can just specify 'Rel' or 'Relative'.

Maybe the other Mouse commands should be changed to support flexible parameter ordering similar to Click.

I'm not sure if this means something like:

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

Command, "a b c"
Command, "c b a"
;is the same as:
Command, "a", "b", "c"
Command, "c", "b", "a"

- Perhaps this was suggested so that you could perform mathematics on the numeric parameters, however, if the parameters can be in any order, including X/Y/click count, and if those 3 parameters are all numeric with no string prefix, you get the terrible situation of ambiguity that you get now with the current Click command.
- Personally I would be happy to keep the options as one parameter, but to split off X and Y. I don't see it as particularly useful to be able to split up the options.
Helgef
Posts: 2396
Joined: 17 Jul 2016, 01:02
Contact:

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

04 Nov 2017, 07:45

Hello :wave:
MouseClick(vPosX:="", vPosY:="", vOpt:="")

It is probably a good idea, instead of smart parameters. Some of the options could have thier own parameter perhaps, like whichButton. Calling the mouse functions MouseXXX benefits searching too. I don't think we should have both click and mouseclick :think:
I'm a bit confused by this
Probably just means exactly that you cannot use R by itself.
n anticipation of needing to write a Click/MouseClick 'AHK v2 function for AHK v1' at some point in the future

So the function should be used when someone wants to run a script written for v2, with the v1 executable? Or am I missing the point? :crazy:

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

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

04 Nov 2017, 10:28

- I've been working on these as you might know:
commands as functions (AHK v2 functions for AHK v1) - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=37&t=29689
- Eventually the nature of AHK v2's MouseClick/Click and MouseClickDrag(/MouseDrag?) functions will emerge, and I'll want to write functions for them also.
- This is me unusually writing demo versions of functions before I actually know what they'll look like.
- I had had some thoughts about how to overcome some of the current problems with the existing commands, but had felt that to be genuinely useful, I ought to try and create a working prototype function, in order to fully discover and truly resolve all of the problems.
- Funnily enough, I thought that everyone would understand what I meant, that this was part of my project to recreate AHK v2 functions for use in AHK v1, but if even you were a little unsure, then it just goes to show that you should always make yourself doubly clear on the Internet, to the point of being mind-numbing.
- I try to not to be too repetitive because if I say something twice on the forums, just me seems to think I've said it a million times.

- I listed Options above: WhichButton Rel Speed ClickCount Event IgnoreCP Swap.
- Looking back at whenever I've used the MouseClick/Drag functions, these values never vary, they always remain fixed. How many MouseClick lines are sometimes left-click, sometimes right-click? It doesn't seem very likely. Varyingly at a relative/absolute position? Fast/slow mouse move? One/two clicks? It doesn't happen. Clearly if it did, you can use variables within the parameter, like you can for any parameter.
- Since AFAICS, you rarely if ever need the parameter to vary, it made a lot of sense to lump all of the options into one parameter, and not give any of them a separate parameter.
- I'd like to know of any good examples where the Options parameter varies. Cheers.
Helgef
Posts: 2396
Joined: 17 Jul 2016, 01:02
Contact:

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

05 Nov 2017, 04:43

- I've been working on these as you might know:

I've seen it, I didn't make the connection for some reason, I'm sure it is clear to most people. To me it seems like the idea of writing functions for v1, that mimics those of v2, is flawed in the sense that it cannot be done in a meaningful way until v2 is done, and then there is no need for it. When it comes to conversion, you will have much bigger problems than converting v1 commands to v2 functions. I sincerely applaud your efforts though :clap: :salute:
MouseClickDrag(/MouseDrag?

MouseDrag is be sufficient imo :thumbup:
- I try to not to be too repetitive because if I say something twice on the forums, just me seems to think I've said it a million times.

While I'm not certain that is true, please don't limit your self for the benifit of others' negativism.

Regarding options and parameters. I do not really use these functions, so I don't know what is suitable.

Cheers.
User avatar
jeeswg
Posts: 2646
Joined: 19 Dec 2016, 01:58
Location: UK

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

05 Nov 2017, 06:01

- The only problems I've had with two-way compatibility are double quotes (there are workarounds) and Loop (no workarounds currently). There may be other problems that I'm as yet unaware of.
- As AHK v2 changes, it's easy to update/rename the 'AHK v2 functions for AHK v1' function definitions. The only inconvenience is if you've converted your AHK v1 scripts to 'pseudo-AHK v2 in AHK v1', or to AHK v2, and then the official AHK v2 functions change and you have to make multiple replacements. It's definitely easier for me to update my massive scripts gradually, than to try and jump to AHK v2 in one go.
- One or two functions required a bit more effort, but it's an interesting challenge, and usually not too difficult. It would be amazing if Coco and lexikos could return and give some feedback on it as AHK v2 becomes more finalised. One area needing review is error handling.
- I wanted function versions of AHK v1 commands anyway, so the nature of the project simply switched focus slightly. Plus polyethene had done the most laborious parts already, and Coco had done some key work on some of the harder functions.
- lexikos has suggested MouseDrag, I really don't mind, MouseClickDrag or MouseDrag.
- Haha it's not so much negativity, it's hard to get the balance right re. clarification/being repetitive. Tbh with just me that only happened once re. some StrXXX function proposal definitions.
- Funnily enough it's not a function that is used too frequently, so you might say it doesn't matter too much how the function ends up. I do find Click a little tricky to use though, still.
User avatar
jeeswg
Posts: 2646
Joined: 19 Dec 2016, 01:58
Location: UK

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

05 Nov 2017, 06:30

CONTROLS AND GETTING/SETTING TEXT

Re.
v2-thoughts
https://autohotkey.com/v2/v2-thoughts.htm

- I've written various functions for getting/setting control text, which I plan to share hopefully in the next week.
- I had thought that perhaps returning an array would be more logical than returning a string, however, by having all of the functions that get text creating variables and not objects as the default, it's easier in the mind to contemplate the situation: you always expect a variable unless you state otherwise. Note: I have 75 GUI get/set text functions, so it definitely helps to know that returning a variable is the default for all of them. Also, and crucially, if you only want one item's text, do you really want a one-item array, and not a direct string?
- So, I would suggest an options parameter, where you can specify to retrieve an array, as one of the options, which is how I'm writing my functions. This also avoids bother when converting to AHK v2, and options parameters can always be added to in future.
- Most of the time when I want the text of items, I want to retrieve the text of one item e.g. the focused item, a string is preferable here, or I want a list of all the items to look at or store in a text file, again a string is preferable.
- Getting item text as an array, would suggest the need for a StrJoin function e.g. StrJoin(Options, Var1, Var2), StrJoin(Options, Obj*).

WINDOW GROUPS

- This is relatively minor, but it would be nice to be able to use standard arrays for these e.g. oWinGroup.1.WinTitle. Although you could just delete and recreate a group each time as we do now. I remember when I first started using AHK, feeling surprise that we couldn't edit window groups in a granular way.
- This is a really nice summary, cheers lexikos. I guess it's kind of obvious how it worked, but it's still nice to see it in writing. I like the term 'window specs', although I'd been using the term 'window criteria' up till now, which I also like.

v2-thoughts
https://autohotkey.com/v2/v2-thoughts.htm
Each window group consists of a list of window specs. A window spec in v1 consists of WinTitle, WinText, ExcludeTitle and ExcludeText. Window specs are evaluated in the order they were added to the group.


I feel that pretty much all of the main conversion issues, have already been either addressed or anticipated by lexikos, and I don't feel particularly that there is anything that I want to address but haven't, so things kind of feel pretty settled at the moment. Perhaps there are some problems to come with control flow statements or directives, I wonder.
User avatar
jeeswg
Posts: 2646
Joined: 19 Dec 2016, 01:58
Location: UK

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

10 Nov 2017, 17:46

LOOP/LOOP PARSE VIA FOR LOOP

- I have two examples showing a way to do Loop and 'Loop, Parse' via the 'for' loop. This would provide a two-way compatible approach to loops.
- This would be potentially useful if someone had a script that would be fully two-way compatible with the sole exception of loops. Loops have been the major/only remaining obstacle to two-way compatibility at present.
- I had been curious if perhaps a directive (or command) could be used to make Loop in AHK v1, behave like Loop in AHK v2, i.e. treat parameters like function-style parameters. I don't know if the implementation difficulty for that would be easy, medium, or hard.
- Btw I do not plan to replace all instances of Loop and 'Loop, Parse' in my scripts, this is a proof of concept.
https://autohotkey.com/boards/viewtopic.php?f=13&t=36789
- This doesn't handle file or registry loops, although I have written custom functions to do this. Although I didn't write those functions for that purpose.
- Doing everything you can to make a script two-way compatible is an interesting challenge.

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


Return to “AutoHotkey v2 Development”

Who is online

Users browsing this forum: No registered users and 4 guests