Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

AutoHotkey_L v1.1.03


  • Please log in to reply
36 replies to this topic
fragman
  • Members
  • 1591 posts
  • Last active: Nov 12 2012 08:51 PM
  • Joined: 13 Oct 2009
Very very nice update! I especially like named GUIs and +Owner on out-of-process windows. This makes my ToolWindow() library mostly obsolete, but I see this as a good point since it was written to work around a missing feature in AHK that has now been added.

While at GUI updates, what do you think about adding an A_GuiControlHWND variable for g-label notifications to make it possible to identify a control by hwnd that doesn't have a gui variable assigned? This would greatly help me for the OOP GUI library.

guest3456
  • Members
  • 1704 posts
  • Last active: Nov 19 2015 11:58 AM
  • Joined: 10 Mar 2011
great work. thanks a lot.

Added support for GUI names.
Added support for identifying a GUI by its HWND.


examples of usage? i think this should be in the docs

jethrow
  • Moderators
  • 2854 posts
  • Last active: May 17 2017 01:57 AM
  • Joined: 24 May 2009

examples of usage? i think this should be in the docs

Well, the usage is the same as it was before, just you can use Names rather than numbers. I agree that an example in the docs would be nice, but not high priority:
; Creating Multiple GUI Windows Documentation
Gui, 2:Add, Text,, Text for about-box.
Gui, 2:Show

; Same as above, but using a Name
Gui, MyGui:Add, Text,, (MyGui) Text for about-box.
Gui, MyGui:Show

; Same as above, only first finding & then using the HWND
Gui, MyGui: +LastFound
MyGui_HWND := WinExist()
Gui, %MyGui_HWND%: Show, x10 y10

Also, and please forgive any ignorance since GUIs aren't my specialty, but is there any way to create multiple generic GUIs - w/o a name/number - so you can get their HWNDs to reference them? I know it's been discussed before, but (specifically because of this update) it would be nice to specify a variable that would receive the HWND when creating the GUI (like controls can).

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

How does the new Gui names interact with the old Gui, +Labels?

It doesn't. The general rule is that Gui names work exactly the same as Gui numbers did in the past. Technically, Gui numbers are now just numeric Gui names.

While at GUI updates, what do you think about adding an A_GuiControlHWND variable for g-label notifications to make it possible to identify a control by hwnd that doesn't have a gui variable assigned?

A_GuiControlHWND would not be useful in combination with GuiControl and GuiControlGet, since they do not yet support identifying a control by HWND due to a compatibility issue. Although it's unlikely for one Gui control to contain the HWND of another Gui control (thus causing a conflict), it is easier to avoid the issue by postponing HWND support until v2. Perhaps it is worth breaking such scripts?

If there's no associated variable, A_GuiControl returns the first 63 characters of the control's text. That's no good for non-text controls or controls which don't contain unique text, so I can see why HWND support may be needed. (As a workaround, you can use global or static variables like %GuiName%_Control%N%.)

Also, and please forgive any ignorance since GUIs aren't my specialty, but is there any way to create multiple generic GUIs - w/o a name/number

No. However, there are as many possible Gui names as there are variable names. You can use something like Anon%Counter%. Empty names are disallowed in order to help detect errors.

Perhaps something like Gui *:Default could be added for an unnamed Gui, in which case A_Gui should contain a HWND instead of a name.

it would be nice to specify a variable that would receive the HWND when creating the GUI

Specifically, Gui +hwndVar?

jethrow
  • Moderators
  • 2854 posts
  • Last active: May 17 2017 01:57 AM
  • Joined: 24 May 2009

No. However, there are as many possible Gui names as there are variable names. You can use something like Anon%Counter%.

Yep - we're on the same page with that. What I had in mind was particularly for GUI Libraries - where you wouldn't want to create a GUI Name that might interfere with the user's coding. I guess I had in mind something along the lines of:
Gui, New, hwndVar
... where a New Gui would be created & the HWND would be assigned to Var. I'm not requesting this syntax (I trust your judgement much better than mine there), just wanted to demonstrate the functionality I had in mind. If this isn't practical, there are work-arounds for unique Gui Naming Conventions, as you stated.

  • Guests
  • Last active:
  • Joined: --

It doesn't.

...you say "It doesn't." but it appears too...setting a Gui name, does change the default Label right?...that means it does interact. It changes the Label, like +Label does, but you can then still use +Label to change the Label from what the Gui name set it to, that is them "interacting", they are fighting to set the Label.

You never said if my examples were correct as-is. I have to guess (or ask) since the new help file only has a small blurb about the new functionality -- all the examples are still the old way, using numbers. When you put new, recommended, functionality in, you should change all the examples to use it. In the Docs, I think, you should teach new users the right way instead of teaching the old way & having small bits of text mention "...or in v1.1.03+: you could do it this better way".

Perhaps it is worth breaking such scripts?

...yes, I think it is.

Gui, New, hwndVar
...this is what I suggested 100 years ago...
Gui, New: Drop Gui Window Numbering
...I hope that makes sense after all this time, you could do...

Gui, New[, Options]
...which would create the new Gui & set the options, no need to use any "Gui, *:Default" when creating the Gui (you would, however use "Gui, %Var%:Default"...or some other syntax, like "Gui, Select, Var" to reset the default back to it later, if needed). The presence of "Gui, New" changes the default/assigns an automatic name/number (just use the hwnd?), then returns the hwnd (if you gave a var to return it to, in the options). You exclusively use the hwnd (the returned var) to refer to it later. Note I suggested "Gui, New, vhwndmain" which uses "v"...I'm fine with "Gui, New, hwndhwndmain" which uses "hwnd" (other than that doubles the "hwnd" in my var naming convention, so perhaps "v" is still better?), I just used "v" at the time, to be like "Gui, Add"...setting the "variable" associated with the Gui. Actually, I think all commands need changed so that there is 1 var, containing the hwnd, to refer to anything single thing. So, even with "Gui, Add, Text, vExample"...the var "Example" would be how you refer to it later, but it would also contain the hwnd.

This might be better for v2 where more breaking changes are allowed, but I'd still like it for 1.1, if possible.

The point is: I want to "drop Gui numbering" everywhere...in 1.1 start by changing all the examples in the docs to not use & not suggest using Gui numbers, in v2 remove them from working at all.

In that thread, Veovis suggested...

Gui, New, vMain xc y200 w100, Title
...which means the syntax becomes...

Gui, New[, Options, Title]
...which I support, putting the title on the same line. In this regard, "Gui, New" would be like "Gui, Show" except it don't show it...& I know about "Gui, Show, Hide"...& I use it extensively!...but I don't think that would be a workaround for a "Gui, New", even if they are similar in syntax.

  • Guests
  • Last active:
  • Joined: --

they are fighting to set the Label

they don´t fight. +Label takes precedence over the Name

Gui, Some: +LastFound ; +LabelMyWindow
Gui, Some: Show, w200 h200,
ThisFormhWnd := WinExist()
Return

SomeGuiClose:
    Soundplay *32
Return

MyWindowClose: ; no effect, if +LabelMyWindow is set
    Soundplay *64
Return


Seidenweber
  • Moderators
  • 638 posts
  • Last active: Sep 06 2015 01:51 PM
  • Joined: 10 May 2011
wrong comment. This should be
Gui, Some: +LastFound ; +LabelMyWindow
Gui, Some: Show, w200 h200,
Return

SomeGuiClose: ; NOT used, if +LabelMyWindow is set
    Soundplay *32
Return

MyWindowClose:
    Soundplay *64
Return

All questions & answers are related to AHK 1.1.19.03 x64 Unicode

 


fragman
  • Members
  • 1591 posts
  • Last active: Nov 12 2012 08:51 PM
  • Joined: 13 Oct 2009

While at GUI updates, what do you think about adding an A_GuiControlHWND variable for g-label notifications to make it possible to identify a control by hwnd that doesn't have a gui variable assigned?

A_GuiControlHWND would not be useful in combination with GuiControl and GuiControlGet, since they do not yet support identifying a control by HWND due to a compatibility issue. Although it's unlikely for one Gui control to contain the HWND of another Gui control (thus causing a conflict), it is easier to avoid the issue by postponing HWND support until v2. Perhaps it is worth breaking such scripts?

If there's no associated variable, A_GuiControl returns the first 63 characters of the control's text. That's no good for non-text controls or controls which don't contain unique text, so I can see why HWND support may be needed. (As a workaround, you can use global or static variables like %GuiName%_Control%N%.)


I agree that this would be mostly useful for identifying a control without an assigned GUI variable. Right now the only options there are for identifying such a control are:
1) Use a unique g-label. This is bad because it needs to be done by the user of the GUI library and means further work for him.
2) Assign "dynamic" variables to the control like you mentioned there. Also not a very nice way because of "variable space" spamming, which some users may not like.
3) Handle all events by processing the window messages manually. This should be possible but it basically means rewriting things which are already there.

I'm not quite sure which would be the best route to go.
Are there any reasons that speak against introducing A_GuiControlHWND right now? (Work amount, compatibility,...?)

supercalifragilistic
  • Guests
  • Last active:
  • Joined: --

Guest, I believe there's a Firefox ActiveX control somewhere.

supercalifragilistic,
1) "To operate upon a window other than the default (see below), include its name or number followed by a colon ..."
2) Yes, for backward-compatibility, simplicity and consistency. Gui numbers are now really names, so for Gui 2's close label to be 2GuiClose, a Gui named "My" must use MyGuiClose. However, Gui names can be anything valid for variable names, and the labels can still be set via +LabelPrefix.

Thanks for your answer, Lexicos.
1) Sorry, I didn't red as carefully as I must.
2) OK thanks for the explanation. Just a precision : if my window name is MyGui, does the close label must be MyGuiGuiClose ? Does it make sense ? (sorry if the question is stupid).
Just a little thing more :
Congratulation for the redraw of the help file. It was probably a long work. Very good work. But in (at least) my help file, in "recent changes", there are very few links like the ones in the top of this topic, even for versions prior to 1.1.03.00.
A very big thanks again.

mikered
  • Members
  • 19 posts
  • Last active: Oct 14 2011 06:30 AM
  • Joined: 29 Aug 2011

1.1.03.00

Added support for GUI names.
Added support for identifying a GUI by its HWND.
Added +Parent%ParentGui% Gui option.
Added support for external windows as Gui owners via +Owner%HWND%.
Added Name sub-command for GuiControlGet.
Added support for ActiveX controls via the Gui command.

Fixed: Empty hotkey control returned "vk00".
Fixed: Crashes and memory leaks related to COM events/ComObjConnect.
Fixed: GuiControlGet OutputVar, Subcmd, %OutputVar% always failed.

Changed "Missing (/[/{" error messages to "Unexpected )/]/}" for greater clarity.
Changed ListLines to display While and Until lines which are executed each iteration.
Changed ~= to have higher precedence than =/!=/</>/<=/>= but lower than concat, and added it to the documentation.

Downloads (etc.)


Hi everybody ,

I joint today ;) and this is my very first post. i'm glad and sad! :(

sad for : the file version is not 1.1.03 and is 1.1.02.03

Posted Image
Posted Image

nimda
  • Members
  • 4368 posts
  • Last active: Aug 09 2015 02:36 AM
  • Joined: 26 Dec 2010
Clear your cache, or download it with Google Chrome in incognito mode :O

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

What I had in mind was particularly for GUI Libraries - where you wouldn't want to create a GUI Name that might interfere with the user's coding.

YourLibName%Counter% isn't likely to interfere with the user's coding.

Gui, New, hwndVar

Most of the other Gui commands already implicitly create a "new" Gui, so it might seem inconsistent to make it a separate command; on the other hand, maybe it would make the code more readable. Additionally, Gui SomeName:New, hwndVar would automatically be valid, but duplicate names are not allowed. What should happen if a Gui with that name already exists?

...you say "It doesn't." but it appears too...setting a Gui name, does change the default Label right?...that means it does interact.

If you have +Label in the script, the label names are not affected by the Gui name. Thus, they do not interact.

I have to guess (or ask) since the new help file only has a small blurb about the new functionality

Which part of the documentation is unclear? FYI, "For windows other than number 1, the window's name or number is used as a prefix for the special labels ..." (The implication is that they are both prefixed in the same way; there's no reason to think otherwise.)

no need to use any "Gui, *:Default"

Having a "New" command change the default Gui would be inconsistent and less flexible than having it not change the default.

I want to "drop Gui numbering" everywhere...in 1.1 start by changing all the examples in the docs ...

FYI, the docs are on github, and I would accept patches for those changes...

Gui, New[, Options, Title]

This might make it worth implementing as a separate sub-command. Having to "Show" the Gui to set its title isn't particular intuitive. This would be a little closer to Gui Add, Type, Options, Title.

Are there any reasons that speak against introducing A_GuiControlHWND right now? (Work amount, compatibility,...?)

See my earlier comment about its limited usefulness...

Just a precision : if my window name is MyGui, does the close label must be MyGuiGuiClose ?

Yes. My previous answer to your question may have been inaccurate. The correct answer was that Gui names do not need to end in "Gui". It is added to the label name automatically, exactly the same way it was for Gui numbers. ("Two" and "2" should have the same behaviour; they're both names.)

jethrow
  • Moderators
  • 2854 posts
  • Last active: May 17 2017 01:57 AM
  • Joined: 24 May 2009

Most of the other Gui commands already implicitly create a "new" Gui, so it might seem inconsistent to make it a separate command;

Yes - though that gets back to the discussion of creating multiple GUIs that way...

... on the other hand, maybe it would make the code more readable.

Maybe it's just me, but I always found the initial creation of GUIs to be somewhat awkward.

Additionally, Gui SomeName:New, hwndVar would automatically be valid, but duplicate names are not allowed. What should happen if a Gui with that name already exists?

Either it Destroys the original & creates a new one, or it fails. I would say Destroy the first, just like it would with an object.

  • Guests
  • Last active:
  • Joined: --

Additionally, Gui SomeName:New, hwndVar would automatically be valid...

...I think I prefer "Gui, New, SomeName, hwndVar" or "Gui, New, vSomeName hwndVar" more...but as I mentioned vSomeName would make hwndVar redundant...v would be the new hwnd...& all comamnds changed to accept that.

What should happen if a Gui with that name already exists?

...hmm, this is a good question. Part of me wants to say "make it fail" & let the user fix it...but part of me says Destroy the existing Gui & start over. Perhaps Destroy & Recreate is the best option? "Gui, New" does imply you want a New Gui, right?

Which part of the documentation is unclear?

...I'm not sure, I didn't re-read all of it: my point is, long-time AutoHotkey users have read that part of the Docs & we aren't looking for the "small changes" to the existing sentences. For example: "name or number"...I'm sure that used to say "number" before, so you only added "name or" to make it current, but the examples don't show that. You may have carefully altered the existing text to mention the new behavior, but it doesn't pop out at you when glancing over the Docs for evidence of the new behavior. So the Docs may mention the new behavior, but like I said, the examples are where it's at: they need to demonstrate the current/recommended way to code & any new behavior.

Having a "New" command change the default Gui would be inconsistent...

...perhaps I need a longer example?...no, actually, the example in the thread I linked to does it nicely, it shows creating 2 different Gui's right next to each other, no "Gui, Default" in sight. But having "Gui, New" not change the default would be more annoying. If not "change the default" then perhaps I mean "create & select that Gui for any further Gui-building code"?...if that's different...so you don't need Gui, Default while defining/building a new Gui. I think this code, that works right now, demonstrates what I think I currently want (it's a little different from my existing proposal tho)...
Gui_New()...however, it does not, currently, handle what to do for an existing Gui (I may add that later). But it does show how I want "Gui, New" to behave. I didn't put the code in this post, cuz I wanna be able to edit it later, but please look at it anyway.

FYI, the docs are on github...

...hrm, OK...is there anyway to "use Git" (or any VCS) without fully installing it? I really don't think I wanna "install Git" on my comp (it apparently takes over Windows Explorer with alot of new menus), but I wouldn't mind downloading files, making changes & uploading them somewhere & having the website "do the Git/VCS thing" to the file I upload. I think someone needs to make a new website (or enhance GitHub & other VCS hosting sites) to allow direct, in-browser uploads to be able to "upload to VCS" or "upload to the repo"...you upload a file that is changed & the online service (or GitHub internally) would then "do the VCS thing" with that file...it would make a diff/changeset/merge/whatever & send that on to the repo, without me having to "do the VCS thing" on my local comp.

This might make it worth implementing as a separate sub-command.

...exactly...it never made sense to set the title at the end of the Gui-building code...& also have to Show it too.