AutoHotkey Community

Hello,

I am still using the v1 version, just a rough look at the v2 version of the introduction, the change seems to be quite a lot, the v1 code needs to be changed a lot. Now upgrading to v2 is a good idea?

Well v2 isn't completed yet. Its being worked on slowly, but lexikos hasn't released it fully. If you want it for the newer style and how everything flows I say you can go for it, but in terms of stability and usability I would stick with v1 for now.

Ok, I will stay in v1 for a while before I figure out the changes in v2.

I'd say one of the biggest changes is with GUI's and controls. Pretty much everything has moved to functions now, so labels are now gone. Other than that everything else has pretty much stayed the same except being function calls for everything.

I would stick with v1, but read over the major changes in v2 and try to avoid commands and syntaxes that will be gone in v2, so that you'll be able to transition and update your scripts more smoothly when the time comes. Particularly, try to use expression syntax as much as possible, meaning ":=" instead of "=" and things like "If(WinActive())" that use functions, instead of commands like IfWinActive.

i doubt very many people will start rewriting their existing scripts in v2 when v2 finally releases if ever
this is mainly a concern for library authors

- I would use AHK v1, unless the script makes heavy use of GUIs, in which case I would consider using AHK v2 now.
- Use more forwards compatible AHK v1 code where possible. E.g. 'var := value', not 'var = value', and avoid using any functionality marked in the documentation as 'deprecated'.
- An advantage of using AHK v1 is that more libraries are available.
- Note: if you convert your code to AHK v2 too early, you may need to make further adjustments to the AHK v2 code as AHK v2 changes. Whereas if you keep your code as AHK v1, you can convert it in one go at a later date.
- Note: you can automate conversion for most things (the one key exception is GUIs).
commands as functions (AHK v2 functions for AHK v1) - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=37&t=29689
- Some AHK v2 (custom backport) functions I would consider using in AHK v1 (for convenience, and to reduce the future conversion burden):
- DateAdd/DateDiff, DirExist, WinGetList. (And possibly: ControlGetList ('ControlGetItems')/WinGetControls/WinGetControlsHwnd.)

- I would advise any serious AHK developers to use #Warn in all their scripts, AHK v1 or AHK v2. This typically requires the use of 'local' in functions, and giving variables a value (e.g. 0/blank string) before using them.

- @swagfag: If anyone *does* want to update their scripts to AHK v2, my converter script will make this pretty easy, and my backport functions (AHK v2 functions for AHK v1), mean you will still be able to use those fully/partially converted scripts on AHK v1.
AHK v1 to AHK v2 converter - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=37&t=36754

MannyKSoSo wrote: ↑

01 May 2019, 11:17

I'd say one of the biggest changes is with GUI's and controls. Pretty much everything has moved to functions now, so labels are now gone. Other than that everything else has pretty much stayed the same except being function calls for everything.

The AHK v2 documentation still refers to Labels (https://lexikos.github.io/v2/docs/misc/Labels.htm). It's arguably a bad idea to remove Labels because they are much easier to use than functions in various cases, and work with gosub and goto. It provides a tremendous amount of flexibility in programming, versus forcing a particular style of programming.

By removing Labels, it would make rewriting code from v1 to v2 even more daunting and difficult, because that's more than changes in syntax, but change in style, that requires entire sections and subroutines to be reevaluated to fit the new style.

AutoHotkey's v1 GUI system is easy to understand in comparison to other programming languages and is automatically generated when using AutoGUI. As AutoGUI works with v1 and not v2, there isn't any advantage to use or switch to the GUI system of v2 unless the editor/IDE tools are ready too. If you are going to code the GUI completely by hand, I don't really see that much of an advantage of using v2 syntax outside of it looking a bit visually cleaner. It's not easier to understand, as v2 syntax is mostly based on v1 syntax. The main problem is converting v1 GUI syntax to v2, if you already have existing scripts, which can be a high workload the bigger the v1 scripts that the person has. Really would like to see v1 to v2 script conversion tools to ease the transition. I think the jump from v1 to v2 should be done holistically, when the time comes, where there are editors, IDEs, and conversion scripts to aid the switch.

Lastly, as was mentioned, a lot of v2 functions can be backported to v1. This decreases the need to push any switching over from v1 to v2, when you can get most of the benefit and convenience in v1.

Manny refers explicitly to GUIs and controls. There, g-labels and "automatic" labels like Guiclose are actually removed, afaik...

@SOTE Sorry for the confusion, but gregster is correct, I was more referring to the g-labels, which in v1 make it easy to go to pre-made labels, but moving to v2 you have to set up each button or label to a function if you want that control to do something when it changes (this is where v1 is easier to understand).
This is mainly why I wanted to start to write a class that handles this transition easier https://www.autohotkey.com/boards/viewtopic.php?f=76&t=63988&p=274826 is an example of a simple class that I have wrote to help with the eventual transition (though it is not yet completed).

Labels are horrible and if you honestly don’t think the v2 GUI system gives anything more than a cleaner look then you still have a lot to learn in the ways of controlling and organizing code imo

I have quickly checked following document and concluded, I do not have to change anything.
Because, It is all about.. minor stuffs. Nothing worth to spend my time and energy.

Changes from v1.1 to v2.0
https://www.autohotkey.com/v2/v2-changes.htm

Language
-Legacy Syntax Removed
-Variables
-Expressions
-Objects

Library

GUI

Error Handling

Other

The main script, which I am rely on to process everyday jobs, has almost 50 thousands lines.
Change it just for minor cosmetic purpose ?

MannyKSoSo wrote: ↑

02 May 2019, 07:17

@SOTE Sorry for the confusion, but gregster is correct, I was more referring to the g-labels, which in v1 make it easy to go to pre-made labels, but moving to v2 you have to set up each button or label to a function if you want that control to do something when it changes (this is where v1 is easier to understand).

Thanks for clarifying on what you were referring to, g-labels as oppose to labels. And I agree that both g-labels and Labels, in v1, are easier to understand and work with. In v2, the g-label is replaced with a Gui.OnEvent() function, in which say a click would refer to a function, Example- ButtonX_Click(), that does something.

When a user understands that the g = g-label for a GUI and links to a Label, v1 GUIs become extremely easy to understand and use. And the use of Labels are easy to see as a task or group of tasks (subroutine) within the larger script. I believe the dividing line may come from formally trained programmers coming from a different language (to include doing OOP) and have expectations on what a programming language "should look like" versus non-programmers or casuals that are looking for convenience and ease of use that want to put a GUI on a script quickly. AutoHotkey's v1 GUI system is the easiest one that I've seen, and works very well in context to what most people would use a scripting language for.

kczx3 wrote: ↑

02 May 2019, 20:12

Labels are horrible and if you honestly don’t think the v2 GUI system gives anything more than a cleaner look then you still have a lot to learn in the ways of controlling and organizing code imo

How a person chooses to control and organize their code is a matter of preference. I would saying flexibility is better than rigidity. Dividing up tasks done in a script by using Labels is just as valid as using functions or Classes. And that Procedural programming is just as valid as OOP or Functional. I don't believe people are attracted to using AutoHotkey because it's as complex and difficult as other languages. There is C++, C#, Java, etc... just waiting for anybody that wants to do it the hard way. I always thought the point of AutoHotkey (along with AutoIt and WinBatch), was to do things the easier way, when possible.

I'm not saying that the v2 GUI system won't have some advantages in particular areas, but rather is the differences, elimination of features, or complexity worth the benefit and sacrificing ease of use for the majority? To include what's the point of removing features to force a particular style of programming? I'm not clear on why g-labels became "villains" and needed to be eliminated in v2, to force calling a function or not allowing both the use of Labels and functions.

In the v1 GUI system, the g-label can link to a Label that contains A_GuiEvent, functions, or even extend a Class (from inside a Label). So the v1 GUI g-label gives multiple options and flexibility. In many cases the Label can be doing a task which is composed of a number of actions, which can be the equivalent of a Class (which is composed of a series of functions/methods). I'm not saying that a Label or a Class are the same thing, but rather the task(s) they are accomplishing can be equivalent. So to use one or the other (Labels or functions) can come down to preference and style.

For me, the v2 GUI system allows for separation of concerns. No more worrying about naming a gui something unique. Far less occurrences of having to %% deref variables. Elimination of 99% of global namespace pollution. Little to no concerns about dealing with setting the default GUI or ListView/TreeView.

Maybe v2 is more rigid. But that is often times a good thing. I think labels cause more confusion than they offer flexibility.

One thing I think is really important. In the last few months, there have been a surge in the number of posts regarding moving to AHK v2. This is fantastic. The community appears to be seeing the development that Lexikos has done and gaining interest. I think this might be the second biggest driving factor to getting v2 into at least beta (other than Lexikos' motivation of course). I truly hope this interest continues to grow and flourish and will continue to push its acceptance as best I can.

SOTE wrote: ↑

03 May 2019, 04:03

When a user understands that the g = g-label for a GUI and links to a Label, v1 GUIs become extremely easy to understand and use. And the use of Labels are easy to see as a task or group of tasks (subroutine) within the larger script.

Code: Select all

Gui, Add, Button, x3 y250 w75 h50 vHoldIt gDoIt, ClickMe

DoIt:
Do Something
Return

I believe the dividing line may come from formally trained programmers coming from a different language (to include doing OOP) and have expectations on what a programming language "should look like" versus non-programmers or casuals that are looking for convenience and ease of use that want to put a GUI on a script quickly. AutoHotkey's v1 GUI system is the easiest one that I've seen, and works very well in context to what most people would use a scripting language for.

I would argue that this is just as easy to understand and frankly, requires no additional understanding of g-labels. The code is quite self-explanatory which is a key indicator of good code.

SOTE wrote:

Code: Select all

Gui, Add, Button, x3 y250 w75 h50 vHoldIt gDoIt, ClickMe

DoIt:
Do Something
Return

Good example, it is a common mistake in v1.

Btw, labels are much more useful in v2 since functions have local labels which you cannot jump into.

I do agree that the transition of the gui isn't that hard to understand (since all it really is now is just becoming a function call) I can still see some people becoming confused on the removal of the g-label to the onEvent(). I generally see that most people (at least for a while) won't know what they could make the command without having to look it up. In the example main.addButton("x3 y250 w75 h50 vHoldIt", "ClickMe").OnEvent("Click", "DoIt") since it is a button its easy to think that oh yeah, button and click go together, but for other things like Treeview for example has these options: Click, DoubleClick, ContextMenu, Focus, LoseFocus, ItemCheck, ItemEdit, ItemExpand, ItemSelect which most people just starting may not directly remember.
On the other side people that have lots of experience will use most if not all of these types for creating very interesting options. Once everyone gets over the initial bump of converting I can see a lot of great scripts coming out from this change.

kczx3 wrote: ↑

03 May 2019, 07:47

For me, the v2 GUI system allows for separation of concerns. No more worrying about naming a gui something unique. Far less occurrences of having to %% deref variables. Elimination of 99% of global namespace pollution. Little to no concerns about dealing with setting the default GUI or ListView/TreeView.

Maybe v2 is more rigid. But that is often times a good thing. I think labels cause more confusion than they offer flexibility.

I would strongly disagree about such an assessment of Labels, which might be a misunderstanding of them if a person comes from OOP programming which they aren't used or they are used differently in a different programming language. For instance in Object Pascal, Labels are often linked to Goto statements, where they are often used with exiting from loops and then executing some code prior to ending the program. As there isn't a Gosub statement in Object Pascal, the same kind of functionality isn't there. Where say in Visual Basic, they had Gosub and Goto, along with Labels. But they were often maligned because of the fad of demonizing Goto, so many didn't use them the way that they could have. However when you talk to or see discussions among old timer programmers or Assembly programmers, they are perfectly fine with Goto, Gosub, etc... in higher level languages.

In AutoHotkey, Labels are used with Gosub and Return. This makes them arguably as powerful as using functions, but easier to use and understand. When I've discussed the use of AutoHotkey to other IT people with no programming in their backgrounds, they picked up on using Labels much quicker than functions. It's often trying to explain and use functions that cause confusion and difficulty, not the other way around. Even then, there is often a progression with using functions, such as using them with no parameters or a single parameter, like- function(), which makes their usage somewhat like Labels.

It's easy to stack sections of code under a Label to do various tasks and return to where you jumped from. And actually the script is less spaghetti (the knock on Goto), because the name of Labels can refer to the tasks which are being done, rather than having a bunch of functions clustered at the bottom of the script. To avoid function clutter, programmers will stuff a group of functions into a Class. But doing so has much of the same purpose of a Label, a subroutine assigned to doing a task or group of tasks. And people that make liberal use of comments in their scripts, are much less likely to create confusion.

I don't see rigidness and unnecessarily eliminating features as being of value to most programmers. Allowing for different styles of programming, including what is easier, is an advantage of v1. I get that there was some "highbrow" insulting of v1 syntax, but a lot of that was from hypocrites among the AutoIt crowd (who were just hating on AutoHotkey period), and are somehow in love with Visual Basic cloning and $ spam syntax. I never saw %% as being the problem it was made out to be, especially since %% is used by Microsoft with .bat and .cmd files. Nor did I see := vs = being a real issue either, when such is used in Object Pascal, so don't see why it's a problem for AutoHotkey to use it. Cleaning up the syntax should arguably not be the same as reducing ease of use or at the expense of taking away what many think makes AutoHotkey worth using. Don't get me wrong, I'm not totally against v2, just that I think it's not ready for prime time, to include if other tools like Editors, IDE, conversion scripts, etc... are not there. I think a big enough benefit to justify switching has to be there first.

@SOTE
just lol @ labels being flexible. anything but. sure, for ur run-off-the-mill hotkey/hotstring scripts and toy gui scripts they might get the job done, but try doing anything even moderately more sophisticated than that and ur options are waste hours of ur life trying to come up with hacks to mold them to fit ur needs, and waste hours of ur life trying to come up with hacks only to realize what u need is actually impossible and be forced to give up

Goto has only one legit use - breaking out of n-nested loops cleanly. if ure using Goto for anything else other than that, do urself a favor, Ctrl + A, Del and start over. ur future-self will love u for this.

discussions among old timer programmers or Assembly programmers, they are perfectly fine with Goto, Gosub, etc... in higher level languages.

so what? their being fine with it doesnt mean it should be used, especially not given the availability of more powerful constructs. noone in their right mind uses Goto in lieu of while loops, so why should this apply any differently to other cases(the cases being functions v. labels)

Labels are used with Gosub and Return. This makes them arguably as powerful as using functions, but easier to use and understand.

haha, nice try but no. only as powerful as a parameterless assume-global function.
vs
idk what kinda people u tried explaining this to, but u have to be a LITERAL baboon to not understand functions. u must have been explaining it wrong

And actually the script is less spaghetti

its absolutely, invariably more spaghetti. global state, namespace pollution, mutations all over the place, and u cant even know its happening unless u specifically check for it. delicious and a whole lotta fun! u might not think its a problem since u already know whats going on in the script, after all, it was u who wrote it. but give it to some other random person, ask them to make sense of ur goto-carbonara main course and just watch them reach for the closest gun barrel to choke on.

To avoid function clutter, programmers will stuff a group of functions into a Class.

yes, functions will be stuffed into a class(which isnt the way its intended to be used) because AHK lacks namespaces(oh hey, heres a feature request for v2). what can one do to avoid label clutter, again?
liberal use of comments should be frowned upon, especially for the purposes of clarifying the behavior of built-in language constructs. yes, u could write a msg right before the Goto: "okay, listen up, the label requires a, b, c to even WORK PROPERLY(make sure those are defined prior to jumping, tee-hee), and mutates x, y, z which are scattered all over the rest of the script, in the global namespace ofc. have fun!". great, now u have actual code to maintain AND a comment to go with it. OOOOR u could just use a function instead - no comment needed, parameters are immediately visible, return values are immediately visible, and if u adhere to best practice coding standards which u should btw, ie no global, u can be SURE of it, without even looking.

Allowing for different styles of programming, including what is easier, is an advantage of v1

no, no no no no, absolutely not. many ways to do similar(but not quite identical) things are absolutely detrimental to AHK's usability. take Traditional v. Expression syntax for example. u have a noob start off with traditional, he learns it fairly quickly, lets say. now time comes, turns out he needs to do something which traditional doesnt support, say, double-deref a variable or whatever. what happens next? great, now hes gotta spend time learning expression syntax. thats time wasting learning the parts already covered by traditional syntax and he'll be more prone to fukups in the long run, since he'll be more used to traditional syntax, and its likely his grasp of expression syntax will stay poorer for longer. Now, imagine a world where traditional syntax was pruned and all u had was expressions. He'd spend more time upfront(arguably tbh) learning expression syntax, but then he'd be set for life, he'd be able to do anything and everything with expression syntax alone. he would have to keep track of two things at the same time. u know, there's a reason why some languages(python comes to mind) strive toward coming up with the most idiomatic ways to write code. u dont praise cpp for its ease of use: "just look how flexible it is, 20 or so ways of initializing stuff!! amazing!"

I don't see rigidness and unnecessarily eliminating features as being of value to most programmers.

eliminating redundant, inferior, superseded features is totally of value to most programmers. to those that were using them - they get to expand their horizons and learn of newer better ways of doing things; to those that werent using them - they get to avoid the pitfall of wasting their time learning them and becoming overly reliant on them; to those maintaining the language - theres now less to maintain; to those developing tooling for the language - also less to care about. Rigidity is not all bad stuff. Imagine if we had no commands, mandatory endofline delimiter, function keyword(var maybe too, or immutable), mandatory parens. my god, the kind of syntax highlighters u could write. linters, intellisense even maybe! what a world to live in!

I get that there was some "highbrow" insulting of v1 syntax,

command syntax is horrendous. its objectively bad, inferior, less flexible and promotes bad coding practices. proliferated byref/errorlevel usage(abuse really, lets call it what it is), wonky(or lacking) expression support. not convinced? go take a peek at some ol' AHK Basic scripts. if a thread from 2006 come up during research while im writing a script, just thinking about opening it sends shivers down my spine.

and $ spam syntax

$ spam syntax is shit, same as %% spam syntax. % is directionless and it totally is a problem. its ugly, its noisy, i dont care if Microsoft uses it and if they do, well, guess what? they made a mistake. Im indifferent towards := v =. actually, scratch that, := is nice, it can stay.

@Klarion
totally agree, itd be absolutely ludicrous to rewrite v1 scripts in v2 just cuz. Especially so if they make heavy use of dllcalls, i wouldnt touch that with a 10 ft pole. The only people concerned with rewrites should be library authors.

@jeeswg
frankly, ur converter script idea to me seems like a pipe dream, and im not saying this to demotivate u, diminish ur accomplishments or discredit the work uve put in. i simply doubt the extent to which it will be of any use. presumably, it will be able to only somewhat translate v1 syntax to v2 syntax, 1:1. but will it be able to transform GUIs? will it be able to turn labels into lambdas, use nested functions etc, ie the things that make v2 v2? even if u were to somehow copypaste port v1's parser from source, expanding upon it to factor in conversions of this nature, seems like a super massive undertaking.
besides, theres no way in hell im running a converter script alone on a production script. id have to write or rewrite the tests for v2 first and then id have to still manually touch things up(cuz lets be real, no chance its gonna do a full 100% accurate conversion), at which point u have to wonder - why even bother with the conversion script? after its done, at best, ud have a v2 script written in v1 style, at worst, a non functional mess. Who is this tool even aimed at? Noobs? Unless its gonna do 100% accurate conversions, theyre gonna be stuck with a non working script, which theyll have to still learn and figure out how to fix themselves. Pros? Yeah, its probably gonna save them some time, maybe, but then again they could instead rewrite manually to better take advantage of v2's newer features.

- @swagfag: Do you really think an AHK v2 script that uses regular functions only, with no lambdas or nested functions, is so bad?
- GUIs can be semi-converted, possibly better. I only had one or two complex GUI scripts, so haven't investigated it too much. I first converted my scripts within AHK v1 using backported GUI classes, it's easier to convert gradually within AHK v1 first, before moving over to AHK v2.
- One way or another, you have to convert things. My script does virtually everything, I even found a Loop Parse two-liner that can replace StringSplit.
- You can granularly set what you convert, and then compare before/after using something like WinMerge. Checking the differences can be enjoyable even, it can have an ASMR effect.
- For convenience, you can also list lines that need conversion, even if you don't convert them.
- For your production scripts, you'd be better off converting automatically and checking manually, than doing all of that manually, to avoid tedium and bugs.
- I converted all of my scripts, and my converter would help the expert, semi-expert, and possibly the newb. Experts/semi-experts could also use to it help newbs to do conversions.
- I regularly do perfect automatic conversion on AHK v1 snippets of code.