I can understand why, If you want to further develop the script in V2.
Will v2 ever hit the stable state?
Re: Will v2 ever hit the stable state?
Re: Will v2 ever hit the stable state?
In case anyone is wondering about the actual question posed:
v2 is stable, as I have converted most of my scripts
Some observations:
v2 is stable, as I have converted most of my scripts
Some observations:
- TargetWindow does not exist is a very common error. Much of the time, this requires refactoring that will improve the reliability and quality of the code.
- Many helper functions can either be nested inside an existing function or made anonymous vis the fat arrow syntax.
- Callbacks are greatly simplified, and thus should be relied on to improve scripts.
- Command statements that formerly had an OutputVar parameter no longer need their own line. For example, MsgBox WinGetClass("ahk_id" hwnd) is a one liner now.
- As a result, many separate lines can now be condensed into a single line of code. WinWait(hwnd) && WinActivate(hwnd)
- Errors in general are much more helpful and can be used to guide development. Specifically the UnsetError which catches typos will save many hours.
Re: Will v2 ever hit the stable state?
Yes, you are correct, AHK v2 is relatively stable. But, the OP (swq), asked several other questions and expressed a number of concerns. His other questions and concerns are relevant too.
1) It is quite correct, that a number of AHK v1.1 libraries that various people use will probably never get translated to AHK v2.
There are AHK v1.1 to AHK v2 translators to help the process, but it can be the original authors moved on or feel it would be too much work based on their present life situation. To add to this, there are AHK v2 libraries that are not available to AHK v1.1. Where in other cases there are libraries that have both AHK v1.1 and AHK v2 versions. For some users, what they feel is best for them, can be a bit complicated. For some there might be various AHK v2 libraries or features that they must have, where with others there isn't or they are fine with what they have in AHK v1.1 for now.
2) How significant the differences are between AHK v1.1 and AHK v2 depends on the person and likely their programming experience and time they can invest.
The point that some were making, is various people don't want to deal with different versions of AHK at the same time. Some don't want to go back and forth between versions, while with others they don't mind doing that. For various people, they prefer to choose one or the other. If/when they decide to go with AHK v2, it will be both a significant and permanent move for them. As in, they will translate all their scripts from AHK v1.1 to AHK v2, so that they will keep in their minds, maintain, and update only a single version.
The timing of when such people will decide on making a permanent migration to the newer version, depends on many factors. It can be they are perfectly comfortable with AHK v1.1, based on their present needs and availability of libraries and help, despite AHK v2 being superior in various ways. Where with others, they will be jumping back and forth between AHK v1.1 and AHK v2 for all kinds of reasons, so their transition could be in various small steps versus one major transition at a designated time.
Re: Will v2 ever hit the stable state?
I'm considering convert my scripts to v2 too, the mixed syntax of v1 is ridiculous tbhiseahound wrote: ↑02 Sep 2022, 19:20In case anyone is wondering about the actual question posed:
v2 is stable, as I have converted most of my scripts
Some observations:The main benefits are a reduction in lines of code, a reduction in local variables formerly from OutPutVar, a reduction in named functions since () => () is great for functions that are only used once. This leads to cleaner, more consistent code, that is easier to maintain and understand.
- TargetWindow does not exist is a very common error. Much of the time, this requires refactoring that will improve the reliability and quality of the code.
- Many helper functions can either be nested inside an existing function or made anonymous vis the fat arrow syntax.
- Callbacks are greatly simplified, and thus should be relied on to improve scripts.
- Command statements that formerly had an OutputVar parameter no longer need their own line. For example, MsgBox WinGetClass("ahk_id" hwnd) is a one liner now.
- As a result, many separate lines can now be condensed into a single line of code. WinWait(hwnd) && WinActivate(hwnd)
- Errors in general are much more helpful and can be used to guide development. Specifically the UnsetError which catches typos will save many hours.
But the main problem that I concerned about is the libraries, v2 can't include library written with v1 syntax while I don't have sufficient skill or time to convert those myself
Re: Will v2 ever hit the stable state?
When it comes to the future of AutoHotkey, whether it is v1 or v2, I think there has been far too much time spent debating problems and not enough on creating solutions.
Re: Will v2 ever hit the stable state?
I think in some cases you can deal with it like this in your v2 script:
Code: Select all
shell := ComObjCreate("WScript.Shell")
exec := shell.Exec("ahk1_executable.exe ahk1_script.ahk" )
exec.StdIn.WriteLine()
output_var := exec.StdOut.ReadAll()
Code: Select all
FileAppend , % output_var, *
Re: Will v2 ever hit the stable state?
viewtopic.php?f=83&t=98890&p=439179&hilit=v1lib#p439179
@byzod
This is also a way to call the V1 library across processes.
@byzod
This is also a way to call the V1 library across processes.
Re: Will v2 ever hit the stable state?
One can also run v1 libraries in-process with AutoHotkey.dll.
The usage of an "imported" function or class can be the same as a native v2 one, except that they are essentially COM objects. Any objects passed between the two versions won't work like native objects (such as with for loops), but that shouldn't be surprising since the two versions aren't inherently compatible anyway.
The usage of an "imported" function or class can be the same as a native v2 one, except that they are essentially COM objects. Any objects passed between the two versions won't work like native objects (such as with for loops), but that shouldn't be surprising since the two versions aren't inherently compatible anyway.
Re: Will v2 ever hit the stable state?
It would be incredible if the #Requires directive could transition between interpreters.
I personally would only use it for libraries, which is essentially what I’ve been doing with thqby’s function.
Perhaps the UX Launcher could be designed in a way to integrate dual launching v1/v2? Hope this sparks some ideas!
Spoiler
I realize of course this is easier said than done, and v2 is meant to shed the plethora of v1 issues, thus self-defeating. If the v1 code isn’t clean it would certainly lead to debug nightmares and newbie confusion. I personally would only use it for libraries, which is essentially what I’ve been doing with thqby’s function.
Perhaps the UX Launcher could be designed in a way to integrate dual launching v1/v2? Hope this sparks some ideas!
Spoiler
Re: Will v2 ever hit the stable state?
To answer the main question:
In my opinion v2 is already stable enough for making the switch (if you can) and I cant wait for it to go mainstream.
Regarding when will that happen?
well, only Lexikos has the answer to that, but as far as I can tell, he is very active on the project atm, so hopefully soon.
For those scared of switching and not in special cases of having thousands of lines of code to convert or being in business settings with conditions and restrictions I would say that I found the switch to be a no brainer. The syntax is NOT that different. You can definitely understand v2 if you understand v1.
In my opinion v2 is already stable enough for making the switch (if you can) and I cant wait for it to go mainstream.
Regarding when will that happen?
well, only Lexikos has the answer to that, but as far as I can tell, he is very active on the project atm, so hopefully soon.
For those scared of switching and not in special cases of having thousands of lines of code to convert or being in business settings with conditions and restrictions I would say that I found the switch to be a no brainer. The syntax is NOT that different. You can definitely understand v2 if you understand v1.
Click to see my experience and "solutions" to the most common problems you might encounter if you decide to switch.
Projects:
AHK-ToolKit
AHK-ToolKit
Re: Will v2 ever hit the stable state?
@Helgef, it's pretty much summed up below:
The other reason is that, if I start updating / creating additional code that is sitting in a main file that is all written in v1, will AHK be able to interpret both concurrently?For those using v1 scripts, a significant percentage may feel a strong urge or pressure to convert them over because of also not wanting to be bothered with keeping different ways and conflicting versions in their mind. The situation could be viewed more as a permanent migration over to the new version, versus attempting to "dip their toes" or go back and forth between versions.
____________________________________
Check out my site, submeg.com
Connect with me on LinkedIn
Courses on AutoHotkey
Check out my site, submeg.com
Connect with me on LinkedIn
Courses on AutoHotkey
Re: Will v2 ever hit the stable state?
No, it would interpret a full v1 script OR a full v2 script. Not a mix of both.
Projects:
AHK-ToolKit
AHK-ToolKit
Re: Will v2 ever hit the stable state?
Makes sense. That's why I'd like to shift my code across, so I get used to coding in v2, as opposed to v1.
____________________________________
Check out my site, submeg.com
Connect with me on LinkedIn
Courses on AutoHotkey
Check out my site, submeg.com
Connect with me on LinkedIn
Courses on AutoHotkey
Re: Will v2 ever hit the stable state?
For me, V1 is a scripting tool, V2 is more like a "modern" language
I may be an extremist but I think that people should be forced to migrate
Don't forget this about gmail : Released on April 1, 2004, it was still in beta five years and tens of millions of users later.
I may be an extremist but I think that people should be forced to migrate
Don't forget this about gmail : Released on April 1, 2004, it was still in beta five years and tens of millions of users later.
Re: Will v2 ever hit the stable state?
“Extremist” is right. Why would it ever make sense to force anyone to do anything (as if that could be done)? How arrogant it would be to decide what’s best for everyone.
People are always welcome to use any version that best suits them, going back to 1.0.x. The question being discussed is when/how v2 would become the primary version — not whether to make prior versions unavailable.
Re: Will v2 ever hit the stable state?
Why are so many people still using V1?
because of the "beta" sticker on v2?
The contributions of v2 (i mean thing you can't do with V1) should be important enought to "force" the migration (at least not to make new scripts in v1)
because of the "beta" sticker on v2?
The contributions of v2 (i mean thing you can't do with V1) should be important enought to "force" the migration (at least not to make new scripts in v1)
Re: Will v2 ever hit the stable state?
That’s a very myopic view. For me, this is the reason.
Re: Will v2 ever hit the stable state?
The cost of legacy code is so underrated ...
https://www.diffblue.com/blog/2019/7/4/the-hidden-costs-of-legacy-code-and-how-to-fix-them
https://www.diffblue.com/blog/2019/7/4/the-hidden-costs-of-legacy-code-and-how-to-fix-them
Re: Will v2 ever hit the stable state?
None of the issues discussed in that article are applicable to this situation.dJeePe wrote: ↑ The cost of legacy code is so underrated ...
https://www.diffblue.com/blog/2019/7/4/the-hidden-costs-of-legacy-code-and-how-to-fix-them
Re: Will v2 ever hit the stable state?
yeah, nodJeePe wrote: ↑27 Oct 2022, 07:57The cost of legacy code is so underrated ...
https://www.diffblue.com/blog/2019/7/4/the-hidden-costs-of-legacy-code-and-how-to-fix-them
allow me to post a real link
https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
one of my apps with hundreds of end users still uses AHK Basic 1.0