how to determine the "current" GUI? (not "active window")

[orbs]

"current" GUI is the GUI last created by GUICreate(), or switched to by GUISwitch().

my script uses several GUI's, and using GUISwitch() often (mostly for updating controls in a GUI pending user input in another). i have a function that needs to determine the "current" GUI among those i created or switched to. currently i'm storing the "current" GUI handle in a global var, and since i must be very strict about updating this on every GUICreate/Switch, this is cumbersome. i believe an easier and more reliable way exists.

i found >this 8-years-old thread asking the same question, left unanswered unless the "current" GUI is also the "active window", which is not my case:

thanks for any hints.

 

[Melba23]

orbs,

I asked much the same question a few years ago and got nowhere. I solved the problem I was having thanks to some clever code from trancexx which meant that I no longer needed to delete a GUI when using the UDF, but other then that I have never seen a solution other than maintaining a Global variable. >

M23

[orbs]

thanks Melba23, i'll stick to global var then.

[binhnx]

Oops, I had the same experiment when writing the SSCtrlHoverUDF (v1).

Was wonder a directly solution from AutoIt, but it may never happens. So I use a workaround instead. The ugly is, it use WinAPI call, which I and many others do not feel comfortable.

Func FindCurrentGUI()
  Local $idCtrlDummy = GUICtrlCreateLabel("Dummy", 0, 0, 0, 0)
  Local $hWndCurrent = _WinAPI_GetParent(GUICtrlGetHandle($idCtrlDummy)
  GUICtrlDelete($idCtrlDummy)
  Return $hWndCurrent
EndFunc

Edited October 23, 2014 by binhnx

[orbs]

@binhnx, very nice approach!

i relate to your emotions towards WinAPI, but this specific one is more easily understandable then the most. although it does take us into the realm of Win32 windows relationships (parent/owner/ancestor) which is everything but trivial, nevertheless it seems a decent solution. i will put it to the test. thanks!

[guinness]

  On 10/23/2014 at 3:57 AM, binhnx said:

 

The ugly is, it use WinAPI call, which I and many others do not feel comfortable.

Really? I am surprised to hear this as you will be shocked when you find out the inner workings of AutoIt.

Also I wouldn't say that is the "ugly" problem with that code, it's just hacky creating a dummy control and then deleting, which I and many others do not feel comfortable about.

[orbs]

guinness, you really should not take other people's notions toward the apple of your eye so seriously   . you are a programmer. some of us are not.

  On 10/23/2014 at 7:50 PM, guinness said:

Really? I am surprised to hear this ...

 

allow me to pinpoint (my viewpoint, anyway, which i think i share with binhnx):

the greatness of AutoIt - one of them, at least - is that it takes all the DllCall,ObjCreate, and such types of advanced programming mechanisms and wraps them in one-liners, easily understood, out-of-the-box usable functions. to the majority of AutoIt coders (which are not programmers, such as yourself), there are no structs and pointers or C-type syntax they need to know or care about; just numbers, strings, arrays. oh joy!

no doubt knowledge of WinAPI is a considerable benefit to the AutoIt coder; but, unlike other programming languages, it is not mandatory, so even mere mortals can produce decent code.

  On 10/23/2014 at 7:50 PM, guinness said:

... as you will be shocked when you find out the inner workings of AutoIt.

 

no doubt the inner workings of AutoIt makes extensive use of the mechanisms i mentioned above; but the AutoIt coder needs not be aware of this. that's why it's called "inner workings".

  On 10/23/2014 at 7:50 PM, guinness said:

it's just hacky creating a dummy control and then deleting

 

true, but i see no better solution lying around. care to pick up the gauntlet?

Edited October 23, 2014 by orbs

[guinness]

Not this again. I thought you would have learnt from the last time not to speak for others when you yourself have limited understanding of the language. I shall not waste my time again, as I feel I am just wasting my breath.

Edited October 23, 2014 by guinness

[orbs]

that's one thing we agree about  anyway your contribution to this discussion is appreciated

[binhnx]

Arr, guinness, why...so...serious?

When I using a language, I always want to strict with it as much as possible. So I'm not shocked when an C/C++ apps using many WinAPI call

And, you are developer. if you have access to AutoIt source code, why not add a not-hacky-solution for all of us

PS : Yep, agree. The most ugly part should be the create and delete Actually, I find every hacky workaround ugly A straighforward solution is what everyone want to archive

Edited October 23, 2014 by binhnx

[guinness]

Jon develops AutoIt, I just look after the help file, UDFs and build scripts.

[binhnx]

T__T

I may true that we may never have a solution for that problems So, just smile and take a breath

[LarsJ]

Another way to circumvent such a problem (in first post) is to override GUICreate and GUISwitch with two new functions GUICreateEx and GUISwitchEx with exactly the same parameters as the original functions.

GUICreateEx can be coded like this:

Func GUICreateEx( ... )
  Local $hWnd = GUICreate( ... )
  ; In case of an error you can set and return proper error codes
  $hCurrentWindow = $hWnd ; Global
  Return $hWnd
EndFunc

Same for GUISwitchEx. Then replace all "GUICreate(" and "GUISwitch(" with "GUICreateEx(" and "GUISwitchEx(".

If you don't want to use the global $hCurrentWindow, you can use a static variable in a function:

Func SetCurrentWindow( $hWnd, $fGet = False )
  Local Static $hCurrentWindow = 0
  If $fGet Then Return $hCurrentWindow
  $hCurrentWindow = $hWnd
EndFunc

Func GetCurrentWindow()
  Return SetCurrentWindow( 0, True )
EndFunc

Then replace $hCurrentWindow = $hWnd above with SetCurrentWindow( $hWnd ) and you have no global.

Now just remember to use the new functions. But that's easy to correct with a search/replace if you forget it.

These functions (especially if you avoid the global) can be placed in a small UDF as you can include in your project if you need it.

[orbs]

thanks LarsJ, that is practically how it is being handled now (except for the use of static var wrapped in a function).

but the problem is mainly with GUIDelete().

both GUICreate() & GUISwitch() result in a known GUI handle, which i can store in a global var. but the result of GUIDelete() lies in the hands of the AutoIt engine. my script needs to know which is the "current" GUI after GUIDelete(). doing that means storing not only the "current" GUI in a single var, but also the entire lineage of all GUI's, and hoping GUIDelete() is consistent in switching to the nearest ancestor.

this is where binhnx's code shows its worth. i have not yet thoroughly tested it, but i'm getting there... 

[ResNullius]

Along the lines of binhnx's solution, but doesn't require creating a dummy control.

Does require that at least one control be present on the Gui though...

Func _FindCurrentGUI()
    ;requires at least one control currently exists on the Gui before this function is called
    Local $hCurrGui = _WinAPI_GetParent(GUICtrlGetHandle(-1))
    Return $hCurrGui
EndFunc ;==>_FindCurrentGUI

[binhnx]

@ResNullius: 

It has problem with any non-Win32-control, i.e. dummy, graphic, listview item, treeview item

It also has problem with controls have no parent, like menu or context menu 

[ResNullius]

Of course, binhnx is right.

My bad for not testing/researching fully...