jeeswg's 3-item wish list (GUI class name+GUI no icon, A_ThisHwnd/A_ThisIfWinCriteria on hotkey launch, InputBox HFONT)

Propose new features and changes
User avatar
nnnik
Posts: 4486
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: jeeswg's 3-item wish list (GUI class name+GUI no icon, A_ThisHwnd/A_ThisIfWinCriteria on hotkey launch, InputBox HFO

21 Feb 2017, 20:32

But you could use a function/class with label combination that would conveniently solve the Hotkey issue.
Recommends AHK Studio
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: jeeswg's 3-item wish list (GUI class name+GUI no icon, A_ThisHwnd/A_ThisIfWinCriteria on hotkey launch, InputBox HFO

21 Feb 2017, 20:52

- Do you mean defining all hotkeys with the Hotkey command? That's an interesting approach.
- I suppose I could look up A_ThisLabel in a list, (that I used to define the hotkeys) to get the #IfWin criteria. But I'm not sure if that helps to retrieve the hWnd of the window that matched the #IfWin criteria.
- I just read the help, and it can use IfWinActive. So the hWnd could be retrieved via WinExist(). (Again I'd have to work out what to do to define 'any other window', I haven't resolved this yet.) This solution would also mean that no subroutines, would have to be moved.
- ... This is a really a good solution. Gosh, well there was a lot to unpack in your one sentence!

Btw you spoke on my 'conversion logic' topic about a 'CodeArea' approach, I wanted to read more about it, to understand it, do you have a link for that?

Thanks for your comments, much appreciated.
Last edited by jeeswg on 06 Sep 2017, 16:51, edited 1 time in total.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
User avatar
nnnik
Posts: 4486
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: jeeswg's 3-item wish list (GUI class name+GUI no icon, A_ThisHwnd/A_ThisIfWinCriteria on hotkey launch, InputBox HFO

21 Feb 2017, 21:31

jeeswg wrote:- MsgBox2 - version that doesn't use the MessageBox dll function.
The msgBox is meant for debugging and to display errors. I don't know what you try to do with it but whatever it is it's definitely one of the 2.
- [KEY] InputBox - make the Font parameter function parameter, allow specifying an HFONT.
Same goes for the InputBox. It's done in a quick and dirty sort of way.
- ToolTip - specify font and background colour via a command/parameters/a global variable. (Especially important if 'Progress' is removed).
And why would we need to do that?
- [KEY] Progress - keep this in AutoHotkey v2. Might as well keep SplashImage too.
Why?
- [KEY] Gui command - allow specifying class name and no icon for a window.
The entire GUI syntax has been very basic from the start. For many things you need to use Styles or Extended Styles. This is something an Extended style would do ( see: http://stackoverflow.com/questions/4905 ... ut-an-icon )
- Know the size of a window before it is created.
Or create a new GUI API were an information like this is unimportant ( e.g. Java Swing )
Note: Regarding using the Gui command to replace existing commands in AHK v2:
Gui commands cause Persistent,
if 'Thread, Priority' is on, you can't use SetTimer and a label,
some methods such as creating the GUIs yourself using dll functions
involve a callback function and checking
the message queue, which can be cause unnecessary complications for simple scripts,
hence the strong desire for robust/versatile/flexible MsgBox/InputBox/ToolTip functions,
and keeping the Progress command.
Once again the GUI stuff is where AutoHotkey lacks a bit. It would be a mistake to make up for this by adding alternative APIs that try to replace GUIs instead of enhancing the GUI API.
TWO-WAY COMPATIBILITY

AutoHotkey v2 (with backwards compatibility mind)
- [KEY] Keep the Progress command.
- [KEY] Keep StrTrimLeft/StrTrimRight. (Commonly used, also, the same argument for changing SubStr, applies to keeping StringTrimLeft.)
- [KEY] Keep StrLeft/StrRight (because SubStr with nonpositive param 2 is ambiguous, the Format function can cure some ills but not all).
- Announce proposals for In/Contains/Is Type functions in AHK v2, so that conversion can proceed. I.e. one can create a custom function with the same name as the function that will exist.
The main point of v2 is to break backwards compatability. Among the reasons of v2 is to reduce the clutter of commands that AutoHotkey has. This is that clutter ( also you could write your own functions here )
AutoHotkey v1/v2 (with two-way compatibility in mind)
You mean easy on the result of your attempt of 2 way compatability or? I told you from the start that your version isn't going to work.
- 'EASY TO SHARE' PARADIGM: two-way compatible scripts and bits of code should be easy to share on forums without additional functions.
Could you elaborate?
- InStr1/InStr2, SubStr1/SubStr2 - a solution to the InStr/SubStr inconsistency problem.
That would make the names kind of annoying
- Ability to check for/set A_ variables that don't currently exist, that may exist in future versions.
Yeah I support time travel too.
- Allow certain dummy commands/directives from old versions to be present and not cause errors if a certain 'no warning/compatibility' mode is on e.g. #NoEnv.
I see no real reason for this. Two way compatability is already out of the question unless you do some serious rewriting so why would you suddenly want to keep a Preprocessor Directive?
AutoHotkey v1 (with forwards compatibility in mind)
- [KEY] Deref function. A useful way to write some AHK v2 style code in AHK v1 to speed up uptake e.g. vPath := Deref("%A_Desktop%\%vNameNoExt%.txt"). It is also useful generally in AHK v1 for certain situations. (The Deref function already exists in AHK v2.)
- [KEY] vText := "`"hello`"" (or let AHK v2 support """hello""") (or perhaps let AHK v1 support '"hello"'). A common way to achieve double quotes in AHK v1/v2.
I agree
GENERAL - MAJOR

- [KEY] A_ThisHwnd/A_ThisIfWinCriteria on hotkey launch. Because virtually all my hundreds of subroutines must/should check that the active window matches the #IfWin criteria.
I think this is specific to your coding style.
- [KEY] StrReplace with case sensitive parameter.
Why? ( "Every newly launched thread (such as a hotkey, custom menu item, or timed subroutine) starts off fresh with the default setting for this command. That default may be changed by using this command in the auto-execute section (top part of the script)." )
- `s to create spaces: e.g. multiple spaces are lost in html,
and A_Space is too unwieldy.
I get that space is lost within HTML how does that relate to AutoHotkey?

- Can be done by custom functions, but common enough to warrant standard functions (some inspired by MS Excel):
- Dec2Hex - the Format function does this, although I've wanted a function
called Dec2Hex for so long that I still want it.
- StrRept - although StrReplace and the Format function can make this possible in a reasonably short form.
- StrCountOcc - the StrReplace function can do this reasonably succinctly.
but not as the output value of a function.
- File loops (handle long filenames).
- Registry loops (alphabetical order).
- StrStarts/StrEnds functions cf. 'if var contains'.
- A_NowMSec (17-digit date, date now with milliseconds).
- A_Recent variable (Recent folder).
- True/False functions - return true/false, whatever you put into it.
I never used StrStarts or StrEnds before. I don't handle long FileNames....

Code: Select all

trueFalse( val )
{
	return !!val ;makes me question whether it is even worth a function
}
The registry thing would just move the sorting code from your script to AutoHotkey and I don't see anybody using a registry loop very often.
- Traditional For loop, very useful when converting code from other languages.
I don't like the traditional For Loop. also:

Code: Select all

for( %initCode% ; %comparisonCode% ; %inLoopCode%  )
{
	%moreInLoopCode???%
}
%initCode%
While %comparisonCode%
{
	%inLoopCode%
}
- Script interaction:
- To another script: hide/show tray icon. Get Icon/NoIcon status of another script.
I genuinely believe that this is a bad idea due to technical stuff.
- Add Open Containing Folder to a tray icon's menu. Less needed now that the Recent menu has 'Open file location'.
Please elaborate
Recommends AHK Studio
guest3456
Posts: 3239
Joined: 09 Oct 2013, 10:31

Re: jeeswg's 3-item wish list (GUI class name+GUI no icon, A_ThisHwnd/A_ThisIfWinCriteria on hotkey launch, InputBox HFO

21 Feb 2017, 21:41

nnnik wrote: Two way compatability is already out of the question
he doesn't listen to anyone and just writes multiple paragraphs anyway.

you are a better man than me to continue to engage him

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

Re: jeeswg's 3-item wish list (GUI class name+GUI no icon, A_ThisHwnd/A_ThisIfWinCriteria on hotkey launch, InputBox HFO

22 Feb 2017, 00:56

Your reactions to my feature suggestions are really fascinating, I will enjoy this response. Each opening line is paraphrased.

>>> 'MsgBox/InputBox are for debugging.'
- I am in no way lazy, it is ridiculous the lengths I have gone to solve some problems. But I *never* use the Gui commands except for 'software' scripts like file search / registry viewer / Explorer replacement / Notepad replacement / image browser. Even my AutoHotkey master script and minimiser scripts just use InputBoxes.
- I sometimes use Progress windows to put a border around a window. Also Gui commands cause persistence so I never use them in a library function. Progress I like to use together with Input, for an interactive menu that can update, and as a super ToolTip, with big font, I also use coloured backgrounds to inform me of things. [EDIT: I put temporary coloured borders around controls to indicate their positions.]

>>> 'Why big ToolTip?'
If I lose Progress perhaps I could use ToolTip instead.

>>> 'Why SplashImage?'
- I use this for example, when I go to save a file in Internet Explorer, and it already exists, to 'splash' the image, so I know whether to download the image or not.
- I could write a function that in AHK v1 uses Progress/SplashImage, and in AHK v2 use clones. (That's two separate scripts btw.)

However there may be some unforeseen issues when replicating Gui as functions, perhaps some sort of message queue interference or babysitting is required, I've heard that AHK v2 won't enforce persistence though. The benefit of any default AHK GUI-like function like MsgBox, is that AHK handles everything for you. [EDIT: There are problems relating to creating multiple GUIs via the Gui command cf. MsgBox.]

>>> 'Regarding GUI class/no icon.'
- The GUI class can only be set on its creation. In Windows 7 the icon can be hidden retrospectively, but in Windows XP, I believe you had to set hIcon to 0 in the WNDCLASS before you create the window, that was the only way.
- There were some workarounds regarding window shown/hidden, style on/off, to always hide the icon on XP, but you had to be very careful handling show/activate window messages (something like that).

- Ultimately in one script, half the script was on keeping the icon hidden, a key spur for my GUI via functions project, amongst other things.
- To me it was symbolic that this was never addressed, many people asked about it years ago, it said 'AutoHotkey is not for making GUIs'.
- It's such a shame really, so much about the Gui commands is actually excellent, and it's very good for beginners, although surprisingly hard and confusing I remember.

>>> 'Gui size.'
I want to know its size in advance.

>>> 'Stick with Gui commands, don't use custom functions.'
- What I would do is stick with things like 'ControlGet', 'Control' (i.e. 'control set'), they are excellent.
- I'm creating similar functions for interacting with treeviews, and modifying listviews for example, and replicating the existing ones for completeness.
- Then there is creating the GUI windows in the first place.

Ultimately it's so much easier to do it by dll functions. Plus what you do is more transferable to other languages, and you understand how everything works. Plus you know what the Gui commands are doing. I think any medium-level AHK user, should have some appreciation of the source code for all the functions they use.

- Also a project to recreate all the AHK commands/functions/variables, as custom functions would be excellent (some would be not applicable).
- I've already done some work on this, code, pseudocode, or first attempts would be really useful for this. [EDIT: This would be really useful, perhaps for half the commands I've had to look up some aspect of how they work to resolve a problem, or I've had to write a modified version of the function.]

>>> 'The main point of v2 is to break backwards compatibility.'
From my experiments, scripts that work on both AHK v1 and v2 are entirely possible, they are not especially difficult, subject to one or two issues I've highlighted on the thread, mainly the double quotes issue, also ParamFirst and SubStr1.
- Those three issues apply just as much to converting scripts, whether you break or maintain compatibility.

- For me, I think that all the scripts I've written or use, can be made two-way compatible, and I'm far far better off if I do it that way. Currently the one stumbling block is a consistent way to handle double quotes. I have some quite ugly workarounds for this at present.
- I'm tempted to just wait around a bit, see if the double quotes issue is resolved somehow, preferably by adding `" to AHK v1.
- Unfortunately that means I'm not converting to AHK v2 right now when otherwise I would be.

Btw I want to always use " " for variables and never ' '. `" versus "" was an excellent idea, I never felt satisfied with the lack of clarity that "" presented, and this neatly resolves the problem and is consistent with other escaped characters.

>>> 'Among the reasons of v2 is to reduce the clutter of commands that AutoHotkey has.'
- I think that about half-a-dozen commands are being removed. [EDIT: Obviously I know the exact number, I made a list of every command etc, however, in terms of functionality that you can't easily replicate in AHK v2 via one-liner, this number is roughly correct.]
- I see AHK v2 as primarily about removing 'var = text' etc, command-style v. expression-style, and also daring to make some of the bigger changes, like 'SubStr2' and 'ParamLast', making SubStr and Return the way they should have been from day one.

>>> 'Elaborate on the 'EASY TO SHARE' PARADIGM.'
- It's my coinage btw. For example, if I want to share code on forums, sometimes I have to provide additional functions at the bottom, I would like to keep this to a minimum.
- It's irritating to always provide WBGet for example.
- There might be situations where I'd want to share scripts that use my clone of the Deref function for AHK v1.
- I'd also have to specify each time, don't use it in AHK v2, because AHK v2 doesn't have the Transform command.
- If the Deref function was a standard part of AHK v1, all this is avoided.

Also, every time I use MsgBox or InputBox, I have to modify my script before I share it, because I use custom functions. If MsgBox/InputBox were introduced as function versions now in AHK v1, I could share the code as is, yet maintain the advantages of my own custom MsgBox/InputBox functions (with the names 'MsgBox'/'InputBox') when I run the script.

>>> 'InStr1/InStr2, SubStr1/SubStr2, kind of annoying.'
- Btw I am thinking of SubStr1/SubStr2 as well as SubStr etc.
- In general I would use SubStr whenever it acted the same in both versions, and StrRight when I needed to get the last n characters.
- StrRight currently is not and won't be a function in either AHK v1 or v2, but it would be based on the StringRight command if added in.

- InStr/SubStr issues will be a massive massive issue for noobs and for future problems generally, I think I should stress that. So many scripts use them. At least as a quick fix, you could replace SubStr with SubStr1 on old scripts.
- There could be a compatibility library, with some of the functions I've come up with so far, but they are actually few enough in number to consider for AutoHotkey proper.
- Plus you'd have to share the custom functions on forums every time you used them.

- In general I could do things like this:
vIsAhkV1 := (SubStr(A_AhkVersion,1,2) = "1.")
vMonth := SubStr("0" vMonth, vIsAhkV1-2)
- I'm loathe to put that in the scripts I'm currently sharing on forums. If a StrRight function was created now, for both AHK v1 and v2, that would solve a lot of problems.
- The Format function can be used for padding with zeros.

>>> 'Future A_ variables.'
For example A_ScriptPID, would be useful enough, that I'd want it, perhaps I could create a super-global variable.
Unfortunately this doesn't work:
vVarName := "A_ScriptPID"
global (%vVarName%) := DllCall("kernel32\GetCurrentProcessId", UInt)

Out of interest, I'm not sure how I might do this in AutoHotkey Basic. Perhaps this, though it would be global only and not super-global:
if (A_ScriptPID = "")
vVarName := "A_ScriptPID", %vVarName% := DllCall("kernel32\GetCurrentProcessId", UInt)

>>> 'Allow defunct directives.'
(I plan to have 2 scripts one for AHK v1 one for AHK v2, the scripts would have different versions of the same functions, to allow two-way compatibility. I now believe that having the #NoEnv directive anywhere in the AHK v1 script would add #NoEnv to any script making use of a function in that script.)

However, I think the principle of potentially allowing old functions etc to exist in a script without causing crashes is an interesting one relating to forwards/backwards compatibility, that I thought of quite early on when new features were being added in AHK v1, regardless of AHK v2.

Btw removing #MaxMem for example does worry me, I see it as useful protection for the script, it's saved me quite often, however, I may have missed something regarding this.

>>> 'Agreement.'
- Thanks so much for liking the Deref idea, that's really nice to hear.
- Thanks also for liking the double quotes idea. I did get some feedback from Lexikos on double quotes, saying that the idea was good. Which is nicely encouraging. One might say: the only issue being multiple conflicting deadlines and priorities, that we all have.
- Unlike other ideas I've recommended, I really can't gauge how difficult it would be to add this in.

>>> 'A_ThisHwnd/A_ThisIfWinCriteria, individualistic.'
There are quite a few things similar to A_ThisHwnd, that already exist, so it is somewhat surprising that it doesn't exist. E.g. A_Gui, A_ThisLabel, A_ThisHotkey.

>>> 'StrReplace with case sensitive parameter. Why?'
- For me a key programming paradigm I've developed from using AutoHotkey is not to have what I call 'ghost' variables, that affect the function, even without being explicitly visible.
- I have A_StringCaseSense and A_DetectHiddenWindows, in mind, I hate having to turn them on and off every time I use a command, for safety, then make sure I reset them every time there's a Return. Also I have to use them every time I define a function, especially sort filters.
- Anyway we might as well remove the case sensitive option from InStr then! And use A_StringCaseSense instead. Anyway in my custom functions, these options are present.

>>> '`s to create spaces.'
For me this feels like quite a radical suggestion to make. There are some instances where `s already produces spaces. However, many times now, I've felt I've absolutely wanted this to exist.

>>> 'But common enough to warrant standard functions.'
- Dec2Hex and StrRept I wanted since day one.
- StrCountOcc since very early on.
- One of the first things I wanted to do with AutoHotkey, was list long filenames. Utilities regarding simply listing filenames/sizes/dates were so poor on the Internet at the time, and probably still are, the same with listing duplicates. It was interesting at the time writing a simple utility to list filenames that was quicker to write, than it was to search for online. It was a massive effort for me to rewrite the file loop functions to handle long filenames. Although years after I first wanted them.
- I use StrStarts/StrEnds all the time. I've since found out, very recently, that I can do this in RegEx, which is incredibly valuable to me. Although compare with this RegExReplace being used as a function version of StrReplace, when StrReplace didn't exist, it's fiddly having to escape the characters.
- The lack of A_Recent is surprising.
- My True function would always return 1. My False function would always return 0. It is for some really nice code, kind of a hack. You could use the two-way compatible:
if (1, a:=x, b:=y, c:=z, 1)
or
if True(a:=x, b:=y, c:=z)
Anyway the True/False functions are a simple idea that I invented and I haven't seen them anywhere else.

>>> 'The registry things.'
I've used registry loops a lot, including for backing up the registry, and checking for changes to it.

>>> 'The for loop.'
- I love the for loop, especially for mathematics, which I've studied some of.
- Because AutoHotkey doesn't have it, it's less clear how much I would have used it.
- I have found some useful custom functions that do it, and also tried writing my own.
- This one is partly about the AutoHotkey ethos, we look like we don't care about programming if we don't have it.

>>> 'Get/set systray icon hidden for other scripts.'
- Quite often I'd launch a script, but then realise I wanted to hide the icon, so that I didn't then accidentally right-click and reload it.
- I think I could use a general technique to remove any systray icons now. I really wanted this as a beginner.

>>> 'Add Open Containing Folder to a tray icon's menu.'
- For convenience I would have liked to be able to click a script's tray icon, and select Open Containing Folder, in Windows XP. But now in Windows 7, the Start menu's Recent Items menu has 'Open file location'.
- I did add in 'Open Containing Folder' to the registry on Windows XP though. [EDIT: For when you right-click files on the Recent menu.]

Anyway thanks for so much for your comments, they've been really enlightening.
Last edited by jeeswg on 21 Jan 2018, 10:40, edited 3 times in total.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
lexikos
Posts: 7651
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: jeeswg's 3-item wish list (GUI class name+GUI no icon, A_ThisHwnd/A_ThisIfWinCriteria on hotkey launch, InputBox HFO

22 Feb 2017, 03:56

Is there
a reason
that you
use hard
line breaks
in the middle
of sentences?
FYI, it's annoying.
jeeswg wrote:However, there appears to be a difference when using '#IfWinActive' alone versus '#IfWinActive, MyCriteria', which unfortunately very much limits the usefulness of the method.
#IfWinActive alone is the same as #IfWinExist alone, or #If alone, or never having used #If' at all. Why should the active window at the time the hotkey was pressed be recorded? It has no significance to the script as far as the program can possibly determine. If you want it recorded, record it yourself.

In any case, the problem you present is easily solved by writing the code differently. For instance, use functions for code-reuse, not stacked labels.

If you use #IfWinExist A, the hotkey will fire when any window is active (and visible if DetectHiddenWindows is Off), and WinExist() will return its handle.
As a second-best I can check that the active window matches the #IfWin criteria,
The active window never matches the criteria of a global hotkey, because a global hotkey has no criteria.
The benefit of any default AHK GUI-like function like MsgBox, is that AHK handles everything for you.
What that really means is that the developer of AHK already wrote and tested the code for you. It is also included in every copy of the application, regardless of how useful it is or who uses it. What you're asking is for perfectly functional, well-tested and simple code to be replaced (or worse, redundantly supplemented) with new, somewhat larger code, and for that code to be written and tested by someone who isn't you, just to add a few minor features - features which are merely cosmetic or trivial to do in script, and that probably wouldn't see heavy use.
In Windows 7 the icon can be hidden retrospectively, but in Windows XP, I believe you had to set hIcon to 0
Given that XP has been on the way out for a long time now, I would put zero priority on trivial, harmless cosmetic differences between XP and 7. Having or not having a window icon is a trivial, harmless cosmetic difference. (AutoHotkey Setup hides its icon on 7...)
Also a project to recreate all the AHK commands/functions/variables, as custom functions would be excellent
So, the real reason you have been requesting built-in features is so that you can make them completely redundant by recreating them as scripts? ;)

Sometimes, if it can be written as a script, it shouldn't be built-in.
I think that about half-a-dozen commands are being removed.
Your counting skills need improving. :P How many legacy IF commands are there? 18? All removed. String commands? All removed. And 17 others by my count from the v2-changes list, not including functions and directives.
I have A_StringCaseSense and A_DetectHiddenWindows, in mind, I hate having to turn them on and off every time I use a command, for safety, then make sure I reset them every time there's a Return.
I don't like it either, but it's an issue only rarely for me, and adding a sixth parameter to a function seems like it would be replacing one problem with an equal but different problem.
`s to create spaces.
...
However, many times now, I've felt I've absolutely wanted this to exist.
That's useless to know. I'd already assumed you wanted it to exist, since you wished for it. I haven't wanted it to exist, so hypothetically speaking, if you want to change my mind, you'll have to explain why you want it to exist in some way I can relate to. For instance, why can't you use an actual space, escaped or otherwise?
For convenience I would have liked to be able to click a script's tray icon, and select Open Containing Folder, in Windows XP.
There's nothing stopping you from adding that to the Tray menu yourself.
But I *never* use the Gui commands except for 'software' scripts like file search / registry viewer / Explorer replacement / Notepad replacement / image browser.
That's your prerogative, but I think it is unreasonable to ask for redundant functions to be added just because you don't want to use what's already available (and no doubt took a great deal of time for Chris to develop).
Also Gui commands cause persistence so I never use them in a library function.
Gui commands don't cause persistence in v2 (though the presence of a visible Gui does).
guest3456 wrote:perhaps turning off context sensitivity should be changed to #IfWinActive, off
"off" is a perfectly valid window title (or window title substring).
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: jeeswg's 3-item wish list (GUI class name+GUI no icon, A_ThisHwnd/A_ThisIfWinCriteria on hotkey launch, InputBox HFO

22 Feb 2017, 05:12

Re. line breaks, if I get a better response for the question below, I'll replace Notepad with my own text editor, and do word wrap.
Edit control alternative for GUI commands, colour individual lines - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=5&t=27117
Curiously enough it's something that Stack Overflow does quite well, whereas it needs 4 spaces for a code line. [EDIT: I.e. Stack Overflow does a lot of things badly e.g. a lack of clarity about what post content is acceptable, wasting the time of users and moderators.]

Thanks re. '#IfWinExist A'.

- What I mean by 'AHK handles everything for you', is that there may be all sorts of complications trying to use the Gui commands or dll calls to replace or tweak things like MsgBox/InputBox/Progress/SplashImage/ToolTip. Including persistence, 'Thread, Priority' and message queue handling, OnMessage, using SetTimer and hacky workarounds. You may have two conflicting OnMessage functions for example.
- I need to replace all 5 of the commands above. They see heavy or daily use. (When my GUI via functions are more complete, I'll be more precise on the issues.)
- Out of interest, has anyone cloned Progress or SplashImage yet?

Regarding icons/class names. Lots of people asked about these a long time ago. I want to make professional-looking software in AutoHotkey. Removing the icon on certain windows, and having a recognisable class name is the mark of excellence, and that's why I've abandoned the Gui commands.

Roughly 6 functions without a direct alternative.

Glad that you don't like A_StringCaseSense and A_DetectHiddenWindows either. JEE_StrReplaceCI and JEE_StrReplaceCS is a nice solution perhaps.

%A_Space% takes up too much real estate. Especially 5 in a row. Plus it's hard to count how many of them there are, at a glance. Multiple spaces can get lost in their 'Chinese whispers' html Internet journey. %A_Sp% or `s would be ideal. `s needs no "" or %%.
HELLO%A_Space%%A_Space%%A_Space%%A_Space%%A_Space%WORLD
HELLO%A_Sp%%A_Sp%%A_Sp%%A_Sp%%A_Sp%WORLD
HELLO`s`s`s`s`sWORLD
HELLO WORLD [is it a tab?]

'There's nothing stopping you from adding that to the Tray menu yourself.'
I last tried that some years ago, I can't remember if I had some issue with setting the pause/suspend icons or whatnot. I'll try again at some point.

- I don't understand where you say: 'and no doubt took a great deal of time for Chris to develop'. I appreciate everything Chris did, (it's changed my life really,) especially how he stood up for the necessary changes to AutoIt in the AutoIt forums.
- Btw where are all the old users like: Chris, majkinetor, SKAN, Sean, jethrow, Laszlo, polyethene? They must be doing something interesting and IT-related.

Your comments are much appreciated.
Last edited by jeeswg on 06 Sep 2017, 17:29, edited 1 time in total.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
User avatar
nnnik
Posts: 4486
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: jeeswg's 3-item wish list (GUI class name+GUI no icon, A_ThisHwnd/A_ThisIfWinCriteria on hotkey launch, InputBox HFO

22 Feb 2017, 05:55

jeeswg wrote:Your reactions to my feature suggestions
are really fascinating, I will enjoy this response.
Each opening line is paraphrased.

>>> 'MsgBox/InputBox are for debugging.'
I am in no way lazy, it is ridiculous the lengths
I have gone to solve some problems.
But I *never* use the Gui commands except for 'software' scripts
like file search / registry viewer / Explorer replacement
/ Notepad replacement / image browser.
Even my AutoHotkey master script and minimiser scripts
just use InputBoxes.
I sometimes use Progress windows to put a border around
a window.
Also Gui commands cause persistence so I never use them
in a library function.
Progress I like to use together with Input,
for an interactive menu that can update,
and as a super ToolTip, with big font,
I also use coloured backgrounds to inform me of things.
You have not disproven my point. I also don't think you are lazy. I am lazy. For me it would be fine if the script gets Persistence and I exit it using it's Taskbar Button.
>>> 'Why big ToolTip?'
If I lose Progress perhaps I could use ToolTip instead.
Just use GUIs already.
However there may be some unforeseen
issues when replicating functions as Gui, perhaps some sort
of message queue interference or babysitting is required, I've heard
that AHK v2 won't enforce persistence though. The benefit
of any default AHK GUI-like function like MsgBox,
is that AHK handles everything for you.
I don't get how you "replicate a function as GUI".
>>> 'Regarding GUI class/no icon.'
The GUI class can only be set on its creation.
In Windows 7 the icon can be hidden retrospectively,
but in Windows XP, I believe you had to set hIcon to 0
in the WNDCLASS before you create the window, that was the only way.
There were some workarounds regarding window shown/hidden,
style on/off, to always hide the icon on XP,
but you had to be very careful handling show/activate window messages (something like that).

Ultimately in one script, half the script
was on keeping the icon hidden, a key spur
for my GUI via functions project, amongst other things.
To me it was symbolic that this was never addressed,
many people asked about it years ago, it said 'AutoHotkey is
not for making GUIs'.
It's such a shame really, so much about the Gui commands
is actually excellent, and it's very good for beginners,
although surprisingly hard and confusing I remember.

>>> 'Gui size.'
I want to know its size in advance.
This would once again be solved with a better GUI API.
>>> 'Stick with Gui commands, don't use custom functions.'
Could you point out where I said that in the text?
What I would do is stick with things like 'ControlGet',
'Control' (i.e. 'control set'), they are excellent.
I'm creating similar functions for interacting with treeviews,
and modifying listviews for example, and replicating
the existing ones for completeness.
Then there is creating the GUI
windows in the first place.

Ultimately it's so much
easier to do it by dll functions. Plus what you do
is more transferable to other languages, and you understand
how everything works. Plus you know what the Gui commands
are doing. I think any medium-level AHK user, should have
some appreciation of the source code for all the functions they use.
I don't get what you try to say
>>> 'The main point of v2 is to break backwards compatibility.'
From my experiments, scripts that work on both AHK v1 and v2
are entirely possible, they are not especially difficult,
subject to one or two issues I've highlighted on the thread,
mainly the double quotes issue, also ParamFirst and SubStr1.
Those three issues apply just as much to converting scripts,
whether you break or maintain compatibility.

For me, I think that all the scripts I've written or use,
can be made two-way compatible, and I'm far far better
off if I do it that way. Currently the one stumbling block
is a consistent way to handle double quotes. I have
some quite ugly workarounds for this at present,
I'm tempted to just wait around a bit, see if the double quotes issue
is resolved somehow, preferably by adding `" to AHK v1.
Unfortunately that means I'm not converting to AHK v2
right now when otherwise I would be.

Btw I want to always use " " for variables and never ' '.
`" versus "" was an excellent idea, I never felt satisfied
with the lack of clarity that "" presented,
and this neatly resolves the problem and is consistent
with other escaped characters.
AHK v2 is not finished yet it might change some things about it's syntax that would break compatability ( e.g. change the GUI commands )
>>> 'Elaborate on the 'EASY TO SHARE' PARADIGM.'
It's my coinage btw.
For example, if I want to share code on forums, sometimes I have to provide
additional functions at the bottom, I would like to keep this to a minimum.
It's irritating to always provide WBGet for example.
There might be situations where I'd want to share scripts
that use my clone of the Deref function for AHK v1.
I'd also have to specify each time, don't use it
in AHK v2, because AHK v2 doesn't have the Transform command.
If the Deref function was a standard part of AHK v1, all this is avoided.

Also, every time I use MsgBox or InputBox,
I have to modify my script before I share it, because
I use custom functions. If MsgBox/InputBox were introduced
as function versions now in AHK v1, I could share the code as is,
yet maintain the advantages of my own custom MsgBox/InputBox functions
(with the names 'MsgBox'/'InputBox') when I run the script.
None of your suggestions actually make it easier to share a AutoHotkey script.
>>> 'InStr1/InStr2, SubStr1/SubStr2, kind of annoying.'
Btw I am thinking of SubStr1/SubStr2 as well as SubStr etc.
In general I would use SubStr whenever it acted
the same in both versions,
and StrRight when I needed to get the last n characters.
StrRight currently is not and won't be a function in either AHK v1 or v2,
but it would be based on the StringRight command if added in.

InStr/SubStr issues will be a massive massive issue
for noobs and for future problems generally, I think I should stress that.
So many scripts use them. At least as a quick fix,
you could replace SubStr with SubStr1 on old scripts.
There could be a compatibility library, with some of
the functions I've come up with so far, but they are actually
few enough in number to consider for AutoHotkey proper.
Plus you'd have to share the custom functions on forums
every time you used them.

In general I could do things like this:
vIsAhkV1 := (SubStr(A_AhkVersion,1,2) = "1.")
vMonth := SubStr("0" vMonth, vIsAhkV1-2)
I'm loathe to put that in the scripts I'm currently
sharing on forums. If a StrRight function was created now,
for both AHK v1 and v2, that would solve a lot of problems.
The Format function can be used for padding with zeros.

>>> 'Future A_ variables.'
For example A_ScriptPID, would be useful enough,
that I'd want it, perhaps I could create a super-global variable.
Unfortunately this doesn't work:
vVarName := "A_ScriptPID"
global (%vVarName%) := DllCall("kernel32\GetCurrentProcessId", UInt)
Once again v2 is for breaking compatabily.
>>> 'Allow defunct directives.'
(I plan to have 2 scripts one for AHK v1 one for AHK v2,
the scripts would have different versions of the same functions,
to allow two-way compatibility.
I now believe that having the #NoEnv directive anywhere in the AHK v1
script would add #NoEnv to any script making use of a function in that script.)

However, I think the principle of potentially allowing
old functions etc to exist in a script without causing crashes is an interesting
one relating to forwards/backwards compatibility,
that I thought of quite early on when new features were being added in AHK v1,
regardless of AHK v2.

Btw removing #MaxMem for example does worry me,
I see it as useful protection for the script,
it's saved me quite often, however, I may have missed
something regarding this.
You should read up on Preprocessor Directives.
>>> 'A_ThisHwnd/A_ThisIfWinCriteria, individualistic.'
There are quite a few things similar to A_ThisHwnd,
that already exist, so it is somewhat surprising
that it doesn't exist. E.g. A_Gui, A_ThisLabel, A_ThisHotkey.
A_ThisHWND would be for Hotkeys. The rest is for GUIs. A_ThisHotkey is consistent with A_ThisLabel.
>>> 'The for loop.'
I love the for loop, especially for mathematics,
which I've studied some of.
Because AutoHotkey doesn't have it, it's less clear
how much I would have used it.
I have found some useful custom functions that do it,
and also tried writing my own.
This one is partly about the AutoHotkey ethos,
we look like we don't care about programming if we don't have it.
There many languages that don't have a for loop. Towards me it is one of the worst loop conventions out there. Use the while loop just like I have shown you.
Recommends AHK Studio
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: jeeswg's 3-item wish list (GUI class name+GUI no icon, A_ThisHwnd/A_ThisIfWinCriteria on hotkey launch, InputBox HFO

22 Feb 2017, 07:12

>>> Re. Mx/Ix for debugging.
The typical AHKer will 'hack' whatever for a new purpose.

>>> Re. 'replicating Gui as functions'.
It should be 'replicating functions as Gui', I've corrected it.

>>> Re. 'Stick with Gui commands, don't use custom functions.'
Could you point out where I said that in the text?

I was thinking of this quote most likely:
'Once again the GUI stuff is where AutoHotkey lacks a bit. It would be a mistake to make up for this by adding alternative APIs that try to replace GUIs instead of enhancing the GUI API.'

- In all fairness to the Gui command, there is nothing I would want to keep.
- It might be good to knock up a quick GUI, but I think my GUI functions will make it significantly easier than that.
- Quirky commands, odd things, inconsistencies, weird 'A_' variables, different letters reporting back about the listview, referring to controls by variables names, instead of hCtls (hWnds) stored in variables.
- It's actually *easier* to use GUI functions, plus you can get converts from other programming languages able to get going without having to relearn everything they knew.
- The Gui commands are very limiting, they are not at all easy to add new features to.
- Funnily enough I think all the AutoHotkey commands are excellent other than the broad Gui command. [EDIT: Including the ones that relate to *external* GUIs.] GuiControl/GuiControlGet are good, although messy, and the LV_/TV_ functions are good, but then again Control/ControlGet do the same things, and the LV_/TV_ functions need to be replicated for external controls.

>>> Re. 'I don't get what you try to say'.
- Although the 'Gui' commands have issues, there are 'GUI' commands that are excellent: 'ControlXXX' 'WinXXX', that can be used as part of the GUI 'new regime'.
- Why not keep things simple by having the same functions/commands for internal/external windows.
- I would then need to add similar functions e.g. for listviews/treeviews, and also provide ways of creating GUI windows/controls.
- I've already done about 90% of the work, including all the core components.

- If instead of the Gui commands you use the GUI functions I'm making, and look after the message queue, everything is actually a lot easier to understand and maintain, and also it's easier to bring in other types of GUI control.
- Also if you know the dll functions/messages, behind the GUIs, that makes you better able to learn from/write code in other programming languages.

>>> Re. 'easy to share'.
For me personally if there were Deref/MsgBox/InputBox/SubStr1/StrRight functions available now, it would make it a lot easier for me to share code.

- Also if there were actually some discussion of what steps we should take now, regarding best practice for writing code that is AHK v1/v2 compatible, we might get some interesting results.
- I don't like sharing code that I know will be fiddly to correct in future. I.e. if people just let go of the idea that AHK v1 is here, AHK v2 is there and 'never the twain shall meet', and consider that if they *did* try and make all their code two-way compatible how would they go about it. They might encounter some interesting paradigms.
- Essentially we are asking 'what's the best hack', 'what's the best compromise', if we could have just one default command to aid the transition, what would it be.
- Let's say we want a consistent method for getting the last 2 characters in a string, what is the best compromise? There are not *that many* questions of this kind that need to be addressed maybe 10 or 20, I've seen some great solutions to questions of this nature on the forum.

- If the community would take two-way compatibility seriously, I'd already be writing nice code with the label 'two-way compatible' on it.
- It's really not that hard, but people aren't opening their eyes to it. I'm not actually that concerned with total convenient two-way compatibility, but starting with that mindset, is the best approach.

- I hear sometimes the dramatic 'breaking compatibility', well all of my scripts are/can be made two-way compatible.
- The moment people start thinking of conversion as a hill rather than a mountain, and consider practical steps, not necessarily any of my suggestions, people will start moving to AHK v2.

>>> Re. proposed 'A_ThisHwnd' or 'ThisHotkeyHwnd'.
There is also, A_ThisHotkey, A_TimeSincePriorHotkey, A_TimeSinceThisHotkey.

>>> Re. for loop.
Interesting, the dislike of for loop, it seems pretty harmless to me.
Last edited by jeeswg on 06 Sep 2017, 17:34, edited 1 time in total.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
User avatar
nnnik
Posts: 4486
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: jeeswg's 3-item wish list (GUI class name+GUI no icon, A_ThisHwnd/A_ThisIfWinCriteria on hotkey launch, InputBox HFO

22 Feb 2017, 07:48

It would be a mistake to make up for this by adding alternative APIs ( MessageBoxes/Tooltips... ) that try to replace GUIs instead of enhancing the GUI API ( remodelling the built in GUI API using AutoHotkey/built in code ).
What you understood was the opposite of what I meant.A new GUI API has to be class based.
Recommends AHK Studio
guest3456
Posts: 3239
Joined: 09 Oct 2013, 10:31

Re: jeeswg's 3-item wish list (GUI class name+GUI no icon, A_ThisHwnd/A_ThisIfWinCriteria on hotkey launch, InputBox HFO

22 Feb 2017, 09:09

lexikos wrote:Is there
a reason
that you
use hard
line breaks
in the middle
of sentences?
FYI, it's annoying.
i told him about that a month ago. he doesn't listen to anybody. i'm about to put him on ignore

lexikos wrote:
guest3456 wrote:perhaps turning off context sensitivity should be changed to #IfWinActive, off
"off" is a perfectly valid window title (or window title substring).
yes i thought about that right after i posted.. maybe #IfWinActiveOff ? (edit: or #EndIf to work for all #Ifs)

jeeswg wrote: The moment people start thinking of conversion
as a hill rather than a mountain,
and consider practical steps, not necessarily
any of my suggestions, people will start
moving to AHK v2.
thats why i went through the effort to extend the v1 -> v2 script converter. you could have just added the feature to make the output two-way compatible if you wanted to. but apparently you like starting work from scratch, instead of building upon existing solutions (since you also plan to write your own text editor as a notepad replacement)
Last edited by guest3456 on 22 Feb 2017, 11:12, edited 1 time in total.

User avatar
Flipeador
Posts: 1204
Joined: 15 Nov 2014, 21:31
GitHub: Flipeador
Location: Argentina
Contact:

Re: jeeswg's 3-item wish list (GUI class name+GUI no icon, A_ThisHwnd/A_ThisIfWinCriteria on hotkey launch, InputBox HFO

22 Feb 2017, 09:21

This topic makes no sense to me, most requests are useless and others are not significantly important.
This user (jeeswg) is unable to propose a thing, as guest3456 says, he doesn't listen to anybody.
lexikos wrote:Is there
a reason
that you
use hard
line breaks
in the middle
of sentences?
FYI, it's annoying.
For God's sake, listen to him!. Your writing gives me 'ocular cancer'.
Helgef
Posts: 4495
Joined: 17 Jul 2016, 01:02
Contact:

Re: jeeswg's 3-item wish list (GUI class name+GUI no icon, A_ThisHwnd/A_ThisIfWinCriteria on hotkey launch, InputBox HFO

22 Feb 2017, 11:07

@ jeeswg
I don't get the point of checking the class, if hWnd!=hWnd2 then the active window changed from the #ifwinactive ... to the hWnd2:=WinActive("A"), which I couldn't reproduce.
For your purposes, you could consider this, in pseudo code

Code: Select all

#ifwinactive notepad
q::
	Run, WinWaitNotActive_Notepad.ahk
	RunWait, MyCriticalNotepadRoutine.ahk
	WinClose,  WinWaitNotActive_Notepad.ahk
return

; Script WinWaitNotActive_Notepad.ahk
WinWait, MyCriticalNotepadRoutine
WinWaitNotActive, Notepad
WinClose, MyCriticalNotepadRoutine.ahk
In AHK_H, you could use AhkThread
guest3456 wrote: #IfWinActiveOff
It improves readabillity and could possibly reduce confusion about the #ifs. :thumbup:
guest3456
Posts: 3239
Joined: 09 Oct 2013, 10:31

Re: jeeswg's 3-item wish list (GUI class name+GUI no icon, A_ThisHwnd/A_ThisIfWinCriteria on hotkey launch, InputBox HFO

22 Feb 2017, 11:10

Helgef wrote:
guest3456 wrote: #IfWinActiveOff
It improves readabillity and could possibly reduce confusion about the #ifs. :thumbup:
or something like #EndIf which would work for all of #If/IfWin[Exist|Active].
that may even be better

lexikos
Posts: 7651
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: jeeswg's 3-item wish list (GUI class name+GUI no icon, A_ThisHwnd/A_ThisIfWinCriteria on hotkey launch, InputBox HFO

23 Feb 2017, 03:01

jeeswg wrote:Re. line breaks, if I get a better response for the question below,
I'll replace Notepad with my own text editor, and do word wrap.
Do you mean to say that you use Notepad to type your posts and then copy-paste into your web browser? I know Notepad inserts line breaks at wrap points if you have word wrap enabled, which is why I turn it off before copying text, and turn it back on afterward if needed. I don't understand why anyone would use Notepad to write posts (and don't want to know).
jeeswg wrote:'There's nothing stopping you from adding that to the Tray menu yourself.'
I last tried that some years ago, I can't remember if I had some issue with setting the pause/suspend icons or whatnot. I'll try again at some point.
The tray icon has nothing to do with adding an item to the tray menu.
referring to controls by variables names, instead of hCtls (hWnds) stored in variables.
What are you saying? If you want to use hWnds, use hWnds.
plus you can get converts from other programming languages able to get going without having to relearn everything they knew.
No one has to relearn everything they know. If you mean "without having to relearn anything", that's impossible. Even if the API uses the same paradigm that they are used to, it will be different.
Let's say we want a consistent method for getting the last 2 characters in a string, what is the best compromise?
Calculate it. It's not as though every language has a "index from the end" feature.
guest3456 wrote:yes i thought about that right after i posted.. maybe #IfWinActiveOff ?
Also, it makes no sense to have another set of directives that all do the same thing (#IfWinActiveOff, #IfWinExistOff, #IfWinNot...). #EndIf is perhaps a better idea, but I just use #If. One can use #If ; end to be more obvious.
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: jeeswg's 3-item wish list (GUI class name+GUI no icon, A_ThisHwnd/A_ThisIfWinCriteria on hotkey launch, InputBox HFO

23 Feb 2017, 09:51

Hypothetical forum question:
Q: I want to get the last 2 characters from a string?
A: SubStr(vText, -1)
Q: Is that going to work in AutoHotkey v2?
A: To make it safe for AutoHotkey v2 as well, do the following:
vIsAhkV1 := (SubStr(A_AhkVersion,1,2) = "1.")
vText := SubStr(vText, vIsAhkV1-2)
or
vText := SubStr(vText, (SubStr(A_AhkVersion,1,2) = "1.")-2)
Whichever one inspires you more, pretty isn't it? Beautiful beautiful AutoHotkey. I hope you like the handy one-line version.
Q: SRSLY?
A: Well there is another way:
vText := SubStr(vText, StrLen(vText)-1)
Q: Yeah, but sometimes I'll be adding in text to the front of the variable at the same time.
A: In that case, do this simple workaround:
vText := SubStr(vPrefix vText, StrLen(vPrefix)+StrLen(vText)-1)
Q: What about a function version of StringRight? Has anyone suggested that?
vText := StrRight(vText, 2)
A: That's not a standard function and never will be, as an AutoHotkey veteran I think that's a stupid idea, absolutely shouldn't be added to the source code, I don't know why you even bothered to suggest it. Clearly if you like that idea it's because you never listen to anyone. Furthermore you don't know how to propose ideas, anyway feature requests are stupid and pointless.
Q: Wasn't AutoHotkey an AutoIt feature request that never happened, why are you using the language?
A: See you never listen, btw did you read the manual?

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

Beautiful beautiful AutoHotkey. A dumb suggestion and the best current workaround.
vText := StrRight(vText, 2)
vText := SubStr(vText, (SubStr(A_AhkVersion,1,2) = "1.")-2)

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

@lexikos
Re. 'relearn everything they knew'. Some things in other languages are different, but relatively similar. Which is why I can easily convert them to AutoHotkey. Gui in AutoHotkey is like learning another programming language or another RegEx, it's also particularly fiddly and unintuitive.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
User avatar
jNizM
Posts: 2792
Joined: 30 Sep 2013, 01:33
GitHub: jNizM
Contact:

Re: jeeswg's 3-item wish list (GUI class name+GUI no icon, A_ThisHwnd/A_ThisIfWinCriteria on hotkey launch, InputBox HFO

23 Feb 2017, 10:03

There is no need for SubStr(A_AHKVersion...)

Code: Select all

MsgBox % A_AHKVersion < 2 ? 1 : 2
or true/false

Code: Select all

MsgBox % A_AHKVersion < 2 ? 1 : 0
[AHK] 1.1.33.09 x64 Unicode (2.0-beta.1) | [WIN] 10 Pro (Version 21H1) x64 | [GitHub] Profile
Donations are appreciated if I could help you
guest3456
Posts: 3239
Joined: 09 Oct 2013, 10:31

Re: jeeswg's 3-item wish list (GUI class name+GUI no icon, A_ThisHwnd/A_ThisIfWinCriteria on hotkey launch, InputBox HFO

23 Feb 2017, 11:03

jeeswg wrote:Hypothetical forum question:
Let me fix that for you:

Q: I want to get the last 2 characters from a string?
A: SubStr(vText, -1)

Q: Is that going to work in AutoHotkey v2?
A: You didn't say you were using v2. Use this instead: SubStr(vText, -2)

Q: But I want it to work for both.
A: Why?

Q: Because I want my script forward compatible
A: Why?

Q: Because I'm writing a library and I want to share it so it can be used with both versions
A: Then use: SubStr(vText, (A_AhkVersion<2) - 2)

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

Re: jeeswg's 3-item wish list (GUI class name+GUI no icon, A_ThisHwnd/A_ThisIfWinCriteria on hotkey launch, InputBox HFO

23 Feb 2017, 11:33

Re. 'Because I'm writing a library and I want to share it so it can be used with both versions'.
When I write a library I don't mind using this method. The one and only thing I don't want to do when rewriting someone else's library is to add in functions at the bottom that aid two-way compatibility, therefore the hope is that the few default commands/functions ideally available would be standard commands. You were lucky with converting Gdip (to make it two-way compatible) for example, it doesn't have multiple items on any of the Return lines.

There is a good argument for a having a simple method that works now on AHK v1, that the vast majority of users use, that will also work in AHK v2. If that definitely won't happen then there is a good argument for sharing code that can work in both, but unfortunately that means using these ugly workarounds, that is unless something like StrRight comes along.

Btw 'why aren't you using the non-recommended AutoHotkey v2 already' or words to that effect is not a great argument. Btw also, why would anyone not want their scripts, or simple code lines like this, to be forwards compatible, especially on occasions when it is relatively easy to achieve forwards compatibility. I'm being eminently sensible, I don't know why people love to be unreasonable on this topic. Sometimes I even hear sentences like: AHK v2 is about breaking compatibility, *nothing* should be compatible.

3 methods, none of them pithy, especially when you
want to do something like the line underneath them:

Code: Select all

vIsAhkV1 := (SubStr(A_AhkVersion,1,2) = "1.")
vIsAhkV1 := (A_AhkVersion < 2)
vIsAhkV1 := RegExMatch(A_AhkVersion, "^1\.")

vText := SubStr(vText1, (A_AhkVersion<2)-2) SubStr(vText2, (A_AhkVersion<2)-2) SubStr(vText3, (A_AhkVersion<2)-2)
;versus
vText := StrRight(vText1, 2) StrRight(vText2, 2) StrRight(vText3, 2)
One thing to think about if AHK ever gets that far:

Code: Select all

vVersion := "1.1.24.05"
MsgBox % vVersion < 2 ? 0 : 1
vVersion := "2.1.24.05"
MsgBox % vVersion < 2 ? 0 : 1
vVersion := "3.1.24.05"
MsgBox % vVersion < 2 ? 0 : 1
vVersion := "10.1.24.05"
MsgBox % vVersion < 2 ? 0 : 1
Btw will AutoHotkey v2 always allow both of these?
vText := SubStr(vText, ((A_AhkVersion<2)-2) ;string v. number
vText := SubStr(vText, ((A_AhkVersion<"2")-2) ;string v. string
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
guest3456
Posts: 3239
Joined: 09 Oct 2013, 10:31

Re: jeeswg's 3-item wish list (GUI class name+GUI no icon, A_ThisHwnd/A_ThisIfWinCriteria on hotkey launch, InputBox HFO

23 Feb 2017, 13:10

jeeswg wrote: The one and only thing I don't want to do when rewriting someone else's library is to add in functions at the bottom that aid two-way compatibility, therefore the hope is that the few default commands/functions ideally available would be standard commands. You were lucky with converting Gdip (to make it two-way compatible)
The Gdip library used SysGet, Monitor commands that were replaced by MonitorGet in v2.
So, new functions had to be added to the bottom of the lib which queried the WinAPI directly

Also, when I initially ported the Yunit library, I was querying A_AhkVersion just as I showed. Since then, v1 has changed its Obj methods so that was unnecessary

jeeswg wrote:for example, it doesn't have multiple items on any of the Return lines.
I could easily argue that multiple items on a return line is a code smell, and should probably be removed entirely, as it does nothing but cause confusion. I would never write code which has multiple items on a return line, and personally consider it awful practice


jeeswg wrote:Btw also, why would anyone not want their scripts, or simple code lines like this, to be forwards compatible, especially on occasions when it is relatively easy to achieve forwards compatibility.
Because a sinlge user can only have one instance of AHK installed on their machine. Either v1 or v2. So whichever version you have installed, you write code for that version. Its simple. Thats what the v1->v2 script converter is for, for people's personal scripts.

You are overcomplicating it in order to prove your point. The only reason to worry about compatibility is for code that would be shared such as libraries, in which case its no big deal to have some extra code

jeeswg wrote: I'm being eminently sensible, I don't know why people love to be unreasonable on this topic.
You think you are being sensible, but you simply haven't thought things through thoroughly enough. You are just rambling off the top of your head. But if you think these things are so necessary, then fork the AHK source code, and add the features in yourself, and then you'll have your own 2-way compatible AHK. Perhaps Lexikos will even consider your changes for the main distribution


Return to “Wish List”

Who is online

Users browsing this forum: No registered users and 6 guests