Jump to content

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

Problems with the GUI "+owner" and "-disabled


  • Please log in to reply
11 replies to this topic
jballi
  • Members
  • 1029 posts
  • Last active:
  • Joined: 01 Oct 2005
v1.0.44.06

Let me be the first to admit it. I am still very new GUI arena so these GUI "bugs" may just be a lack of understanding on my part. If this is the case, please accept my apologies in advance.

The problems I found can be best explained (at least for me) with the following 4 examples:

Example 1:
;-- 1st GUI
Gui, Add, Edit, r20 w450
Gui, Show, AutoSize, GUI-1

;-- 2nd GUI
Gui, 2:Add, Edit, r1 w200
Gui, 2:Show, AutoSize, GUI-2
Return

GuiClose:
ExitApp

2GuiClose:
Gui, 2:destroy
return
In this example, two independent windows are created. The larger window, GUI-1, is created first, and the smaller window, GUI-2, is created next.

The windows operate as expected.

If the GUI-1 window is clicked on while the GUI-2 is displayed, the GUI-1 window is put into focus and the GUI-2 goes to background.

If either window is minimized, the window will go to the task bar.

If the GUI-2 window is closed, it is destroyed. If the GUI-1 windows is closed, the application is closed, thereby destroying the GUI-1 window and the GUI-2 window (if it exists).


Example 2:
;-- 1st GUI
Gui, Add, Edit,r20 w450
Gui, Show, AutoSize, GUI-1

;-- 2nd GUI
Gui, +Disabled
Gui, 2:+Owner
Gui, 2:Add, Edit, r1 w200
Gui, 2:Show, AutoSize, GUI-2
Return

GuiClose:
ExitApp

2GuiClose:
Gui, -Disabled
Gui, 2:Destroy
return
In this example, the same two windows are created. I wanted to disable the GUI-1 window while the GUI-2 is displayed so I added the following statment before the GUI-2 window is created:
Gui, +DisabledI also wanted to force the GUI-2 window to belong the GUI-1 window so I added the following statement before the GUI-2 window is created.
Gui, 2:+OwnerI wanted to re-enable the GUI-1 window before the GUI-2 window is destroyed so I added the following statement in the 2GUiClose subroutine before the statement to destroy the GUI-2 window:
Gui, -DisabledMany window operations don't work as expected. As expected, one independent "window" is created but I'm not sure which one (if any) is the owner.

Problem 1: If you click on the GUI-1 while the GUI-2 is displayed, it appears to work as expected because the GUI-1 window has been successfully disabled. But if you click on any other window and then try to bring the windows back up, you'll quickly see that the two windows are not attached to each other at all. In addition, if you minimize the GUI-2 window, it goes to the bottom left corner of the desktop, not the to task bar.

Problem 2: If you close the GUI-2 window, the GUI-2 is successfully destoyed but the GUI-1 window is not enabled.


Example 3:
;-- 1st GUI
Gui, 1:Add, Edit,r20 w450
Gui, 1:Show, AutoSize, GUI-1

;-- 2nd GUI
Gui, 1:+Disabled
Gui, 2:+Owner
Gui, 2:Add, Edit, r1 w200
Gui, 2:Show, AutoSize, GUI-2
Return

GuiClose:
ExitApp

2GuiCLose:
Gui, 1:-Disabled
Gui, 2:Destroy
return
To try to fix the problems I found in the Example 2, I qualified all of the GUI statments by adding a number prefix before the first GUI option. For example:
Gui, 1:Add, Edit,r20 w450The disable/enable problem is fixed, but the ownership problem persists.


Example 4:
;-- 1st GUI
Gui, Add, Edit, r20 w450
Gui, Show, AutoSize, GUI-1

;-- 2nd GUI
Gui, 1:+Disabled
Gui, 2:+Owner1
Gui, 2:Add, Edit, r1 w200
Gui, 2:Show, AutoSize, GUI-2
Return

GuiClose:
ExitApp

2GuiCLose:
Gui, 1:-Disabled
Gui, 2:Destroy
return
In this final example, everything is the same as same as in Example 3 except that I qualified the Owner option as follows:
Gui, 2:+Owner1Everything (IMHO) works like it is supposed to. The only thing that I don't like is that the GUI-2 window blinks 2 or 3 times when you click on the GUI-1 window. But it works, so I'm not (really) complaining.


Conclusions
The following statement appears to work correctly:
Gui, +Disabled..but the following 2 statement don't appear to do anything:
Gui, 2:+Owner
Gui, -Disabled
I checked the documentation on the Owner option. Here's the example (and comment) for an unqualified Owner:
gui, 2:+owner ; Make #2 window owned by script's main windowQuestion: Is the "script's main window" supposed to be the 1: window or something else?

I see a lot of "Gui, 2:+Owner" code in a lot of scripts out there but I also see that it doesn't work, at least like I expect it to. Many folks add the "+AlwaysOnTop" option to the 2nd window to give it the illusion of ownership but if you click around, you'll quickly see that the window is not attached to anything other than itself.

There may be problems with other GUI options of this type but these were the ones I was having problems with.

Thank you for your attention.

d-man
  • Members
  • 290 posts
  • Last active: Jun 28 2015 09:26 AM
  • Joined: 08 Jun 2006
I've not anything to add, but I must say that was beautifully presented and I learned something too. Good job!

PhiLho
  • Moderators
  • 6850 posts
  • Last active: Jan 02 2012 10:09 PM
  • Joined: 27 Dec 2005
Like d-man wrote, this is an excellent bug report, showing minimum code to reproduce the problem, analyzing it by steps. Excellent.

The difference in behavior between Gui +Disable and Gui 1:+Disable is baffling, I thought they were strictly equivalent.

To answer your question, I believe that the script's main window is actually the one shown with the Open context menu item. So Gui 2:+Owner1 is probably the right command to use.

Perhaps the manual should be clarified here, and either explain what is the use of Gui 2:+Owner (I have no clear idea) or maybe omit this example (if it is useless).
Posted Image vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

Roland
  • Members
  • 307 posts
  • Last active: Mar 09 2014 07:55 PM
  • Joined: 08 Jun 2006

The difference in behavior between Gui +Disable and Gui 1:+Disable is baffling, I thought they were strictly equivalent.


I only just found this out about two days ago, but it's because the 2GuiClose subroutine uses Gui2 as it's default window (which makes perfect sense). To quote the docs:

The default window number for a GUI thread is that of the window that launched the thread. Non-GUI threads use 1 as their default.


So, if you write:

2GuiClose: 
Gui, 1:-Disabled 
Gui, Destroy 
return

Gui2 is destroyed and Gui1 is re-enabled!


You are right about "Gui, 2:+Owner" though; it doesn't do what the doc says it does. This is quite confusing, especially since it is used in a lot of examples only to hide a Gui from the taskbar.

PhiLho
  • Moderators
  • 6850 posts
  • Last active: Jan 02 2012 10:09 PM
  • Joined: 27 Dec 2005
Thanks, Roland, for clarifying.
So I suppose a good practice, as soon as you have more than one GUI, is to always provide explicitely the GUI number...
And I didn't knew (or forgot) that Gui 2:+Owner was used to hide the window from the taskbar. I suppose that's one of its main uses.
Posted Image vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004

Perhaps the manual should be clarified here, and either explain what is the use of Gui 2:+Owner

I've clarified the example to read:
gui, 2:+owner ; Make #2 window owned by script's main window to prevent display of a taskbar button.

In other words, you're right: the most common use of having a GUI window owned by the script's main window is to avoid giving it a taskbar button (there may be other, more obscure uses).

So I suppose a good practice, as soon as you have more than one GUI, is to always provide explicitely the GUI number...

That is definitely not recommended. The whole reason for giving each thread a default window number is to avoid having to specify the number. To put it simply, each GUI thread uses its own window's number as its default. I wish more people would take advantage of this to simplify their scripts.

Are there any remaining issues or points-to-clarify in this topic?

Thanks.

PhiLho
  • Moderators
  • 6850 posts
  • Last active: Jan 02 2012 10:09 PM
  • Joined: 27 Dec 2005
I am a bit confused by this concept of default GUI number and threads.
I suppose I should re-read the corresponding manual pages.

I am working on a pure AHK PCRE wrapper.
It reports errors in a GUI, so I can use fixed width fonts to point out where a problem is in the line:
PCRE_ShowLastError()
{
	local errorMsg

; Skip stuff here

	Gui 66:Add, Text, , Error compiling pattern: (%#PCRELastError_errorCode%) %errorMsg%
	Gui 66:Add, Button, Default gPCRE_GuiClose x100 y100 w80 h30, OK
	Gui 66:Font, s15, Courier
	Gui 66:Font, , Andale Mono
	Gui 66:Add, Text, x10 y40, %#PCRELastError_regExp%
	VarSetCapacity(pos, #PCRELastError_errorOffset, 32)
	pos := pos "^"
	Gui 66:Add, Text, x10 y65, %pos%
	Gui 66:Show, , PCRE Error
	Gui 66:+LastFound
	WinWaitClose	; Modal window
	Return

PCRE_GuiClose:
66GuiEscape:
66GuiClose:
	Gui 66:Destroy
Return
}
I used here an arbitrary GUI number, to avoid clashing with an existing one.
Is there a better practice to use GUIs in libraries to be included?
How do you create a new thread? Using SetTimer?
Posted Image vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

Roland
  • Members
  • 307 posts
  • Last active: Mar 09 2014 07:55 PM
  • Joined: 08 Jun 2006

I used here an arbitrary GUI number, to avoid clashing with an existing one.
Is there a better practice to use GUIs in libraries to be included?


There's no really good way to go about this I think. One possibility is to ommit the close button by using "-SysMenu" to avoid having to hard-code a GuiClose label. That way the Gui number can be an optional parameter. I did this in my Msgbox function, though I'm not sure if it has any advantages other than saving someone who is already using Gui66 (like you :)) the trouble of editing the function. Or maybe it is useful for a script that keeps track of Gui numbers dynamically.

Btw, in your example, you could use "Gui 66:Default" right at the top. That way, you don't have to type in "66" all the time. I think that's what Chris meant.
I believe you would have to reset it before returning though... otherwise the caller might be in for a nasty surprise. I guess this would work:

PCRE_ShowLastError() 
{ 
If A_Gui <>
	default_prev = %a_gui%
else
	default_prev = 1
	
;....
;....

WinWaitClose
Gui %default_prev%:Default
return
}

I think it is a very good system, just a little unintuative maybe. I mean, I've been using AHK for about half a year now and the first time I used "Gui, X: Default" was when I was writing my Hotkey() function one or two weeks ago (and there I had to use it because the listview functions all operate upon the default window :shock: ).

evl
  • Members
  • 1237 posts
  • Last active: Oct 20 2010 11:41 AM
  • Joined: 24 Aug 2005
I must confess that I don't use the Default command other than when I have to for listviews too. I find it can get confusing to try and follow a complex script when everything just says "Gui" and not "Gui, 1", "Gui, 2", etc (especially if you are trying to manipulate more than one on the screen).

Being able to "name" GUIs would be quite nice and being able to use variables for the names of gui labels would be quite powerful but perhaps not something I'd use often enough to make it as high of a priority.

jballi
  • Members
  • 1029 posts
  • Last active:
  • Joined: 01 Oct 2005
Thanks to everyone for your feedback. I had to read the responses more than once to pick up all of the information. I still probably missed something. But and however, I've learned a lot.

To summarize, the Disable "problem" was my understanding of how the thread's default window feature works. When I didn't specify a GUI window number, the system acted on the default GUI window.

The +Owner issue was confusing. I now understand the value of the unqualified use of the option although I probably won't use it much (I'll use the qualified option). Thank you Chris for updating the documentation.

The "thread's default window" feature has bumped me into new level of consciousness. OK, not a big bump but a bump nevertheless. Like evl, I'm not sure I feel comfortable (yet) coding for the default GUI window but time will tell where this will go.

Once again, thank you all for your feedback.

SKAN
  • Administrators
  • 9115 posts
  • Last active:
  • Joined: 26 Dec 2005
I find this discussion very useful to me.
Many thanks to jballi and everybody.

Regards, :)
kWo4Lk1.png

udhaya_k
  • Members
  • 8 posts
  • Last active: May 21 2015 08:38 AM
  • Joined: 29 May 2014

Old Thread. But still useful which we couldnt find this trick in help file. I would give 100 likes if facebook button enabled in this page.