AutoHotkey Community

#If + WinActive/Exist() is already infinitely better in terms of flexibility and composability than the counterpart #IfWin, so why not deprecate the latter?
also convert StrUpper/Lower to functions and deprecate the commands.

For StrUpper/Lower there is Format. There is no need to keep either around.

swagfag wrote:#If + WinActive/Exist() is already infinitely better in terms of flexibility and composability than the counterpart #IfWin, so why not deprecate the latter?

From merged PR #228:

Lexikos wrote:#IfWinActive etc. are not deprecated. Do not recommend #If over #IfWinActive. #If is more flexible, but also slower and has a higher risk of causing input lag. For instance, copy a large file with FileCopy and try pressing an #If hotkey (without a global variant) before it completes. Assuming the FileCopy does not complete within the timeout period, the hotkey will not fire. On some systems, if #IfTimeout is exceeded the OS will also silently remove the hook.

sure there is Format, but from a readability point of view: the difference is subtle, but its there nonetheless

as for the FileCopy example i dont even understand what is meant by it or how its supposed to tie in with #IfWinXXX: ???

Well AutoHotkey receives Hotkeys by getting called by the system.
Every ms that AutoHotkey takes to return from that call is essentially time that prevents the system from relaying any keystrokes to any application.
If an application hinders the key chain too much it will get removed from that key chain.
At that point AutoHotkey will stop getting called by the system when a button is pressed.

#If is executing real AutoHotkey code where as #IfWinActive is something that AutoHotkey does internally.
internal things can happen while AutoHotkey executes AutoHotkey code however as we all know AutoHotkey code cannot be executed in parralel.

So the #If needs to wait until any other AutoHotkey code is finished. Due to tht it will make the system wait and keep it from relaying it's key properly.
The system might then remove Autohotkey from it's key chain.

- @swagfag: I agree with both of your proposals.
- However, I believe that #If WinXXX() was optimised in AHK v2, it would have to be similarly optimised in AHK v1.
- If we backport StrUpper/StrLower to AHK v1, someone will say but why not this other function also, and ultimately: why not backport all of the new AHK v2 functions? The question then becomes which functions and when. And, which functions are 100% decided in AHK v2.
- For the time being there is this:
commands as functions (AHK v2 functions for AHK v1) - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 37&t=29689
- The powers that be probably also agree with you, it's just a question of time and priorities.

thanks for the explanations, everyone
looking at it that way it does seem like backporting would be a waste of effort
#If and #IfWin too have to be left alone then, i guess. I read the docs on #If but thb hadnt given the caveats' implications much thought

Back porting anything to v1 seems like a waste of time to me

For me too.
Continuing to improve v1 seems like a waste of time to me (only to fix bugs is fine).
Also, I would prefer to remove the StrUpper and StrLower functions from v2.

From my Wish List 2.0, these are my current backport priorities (directives, A_ variables, functions without a good equivalent in AHK v1):
- #SuspendExempt
- A_AllowMainWindow, A_IconHidden, A_IconTip
- A_InitialWorkingDir
- DateAdd/DateDiff (EnvAdd/EnvSub and +=/-= are confusing to use, even for experts)
- DirExist (simple, but very useful, counterpart of FileExist)
- FileInstall
- (writable 'A_' variables)

Also, this would allow functions that have been modified in AHK v2 to have custom backports:
- redefine a built-in function, but maintain access to the original

I accept that backporting all AHK v2 functions and the GUI/Menu objects would be welcome but lower priority, as this may be possible via custom scripts:
commands as functions (AHK v2 functions for AHK v1) - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 37&t=29689
objects: backport AHK v2 Gui/Menu classes to AHK v1 - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 37&t=43530

Some of the benefits are:
- You can write more forwards-compatible AHK v1 scripts.
- When converting between AHK v1 and v2, you don't get tripped up because certain bits of functionality were never backported.
- Issues to do with A_ variables and backwards/forwards compatibility have already caused a lot of problems. Making possible try global A_XXX and try A_XXX := 1 might be worth considering.
- If any time has been wasted it has been because the current DateAdd/DateDiff equivalents in AHK v1 (EnvAdd/EnvSub/+=/-=) were never good enough.

Continuing to improve v1 seems like a waste of time to me (only to fix bugs is fine).

Adding new features to v1, has the benefit of them being tested before v2 is released. Anyways, I'm not going to complain to lexikos that he wastes my time by doing what he wants to do instead of what I want him to do . Personally, I wouldn't waste my time even looking at the v1 source code.

Cheers.

@Helgef: I do not care, I just say. But there is a reality, v2 has been for years in alpha phase, I will only say that.

Adding new features to v1, has the benefit of them being tested before v2 is released.

- @Helgef: I found this comment interesting. I see it as the reverse. Some features that made it to AHK v1, were tested first in AHK v2 alpha.
- Generally speaking, if you add something to AHK v1, then you're stuck with it. In AHK v2, it's anything goes, anything can be changed at any time up until the first official release.