Jump to content

Proper switch logic with child windows?


Jdavis
 Share

Recommended Posts

I've come across another issue that I'm sure stems from my not quite understanding how the events are playing out, and hopefully someone can point out my error.

#include <GUIConstantsEx.au3>

Opt( "MustDeclareVars", 1 )

Global  $parentWindowWidth = 600, $parentWindowheight = 600, $parentWindow, _
        $childWindow, $fileInput, $browseForFileButton, $createChildWindowButton

_createParentWindow()

While 1
    Local $guiMsg
    
    $guiMsg = GUIGetMsg( 1 )
   
    Select
        Case $guiMsg[0] = $browseForFileButton
            If $guiMsg[1] = $childWindow Then
                GUICtrlSetData( $fileInput, _browseForFile( "Browse for file:" ) )
            EndIf
            
        Case $guiMsg[0] = $createChildWindowButton
            _createChildWindow()
            
        Case $guiMsg[0] = $GUI_EVENT_CLOSE
            If $guiMsg[1] = $childWindow Then
                GUISwitch( $childWindow )
                GUIDelete()
            ElseIf $guiMsg[1] = $parentWindow Then
                GUIDelete( $parentWindow )
                GUIDelete()
                Exit
            EndIf       
    EndSelect
WEnd

Func _createChildWindow( )
    Local $parentWindowPosition, $childWindowWidth = 300, $childWindowheight = 300
    Local $childWindowLeft, $childWindowTop
    
    $parentWindowPosition = WinGetPos( $parentWindow, '' )
    
    $childWindowLeft = $parentWindowPosition[0] + ( $parentWindowWidth / 2 ) - ( $childWindowWidth / 2 )
    $childWindowTop = $parentWindowPosition[1] + ( $parentWindowHeight / 2 ) - ( $childWindowHeight / 2 )
    
    $childWindow = GUICreate( "Child Window", $parentWindowWidth / 2, $parentWindowHeight / 2, $childWindowLeft, $childWindowTop, -1, -1, $parentWindow )
    
    $fileInput = GuiCtrlCreateInput( "", -1, -1, 100, 20 )
    $browseForFileButton = GUICtrlCreateButton( "Browse", 150, -1, -1, -1 )
    
    GUISetState( @SW_SHOW )
    GUISwitch( $parentWindow )
EndFunc

Func _createParentWindow( )
    $parentWindow = GUICreate( "Parent Window", $parentWindowWidth, $parentWindowHeight )
    $createChildWindowButton  = GUICtrlCreateButton( "Create Child Window", 250, 170, -1, 20 )
    
    GUISetState( @SW_SHOW )
EndFunc

Func _browseForFile( Const $titleBar )
    return FileOpenDialog( $titleBar, @ScriptDir & "\", "Text documents (*.txt)", 1 + 2 )
EndFunc

When the above script is run, the file browser is opening immediately; however, the script run fines if you close the file browser when it first pops-up. I presume the suspect code is the following:

Case $guiMsg[0] = $browseForFileButton
    If $guiMsg[1] = $childWindow Then
        GUICtrlSetData( $fileInput, _browseForFile( "Browse for file:" ) )
    EndIf

I thought this was logically correct, but I was obviously wrong. The intended behavior is such that you click the button the parent window, which creates a child window, and from the child window you can then browse for a file. Unfortunately, the file browser is popping-up immediately upon execution.

Any thoughts?

Edited by Jdavis
Link to comment
Share on other sites

The problem is that you're using variables before they're defined.

This was something that I was looking into last night, I think. Before I begin to ramble, I'm of the mind that you're referring to this bit:

If $guiMsg[1] = $childWindow

If that's not it, then I'm probably about to appear very stupid!

I wasn't sure of the best method for creating windows. I began to wonder if I should I create all potential windows, hide them, and just toggle them into view. My method for accomplishing that resulted in me always having to recreate the window upon deletion, which seemed a bit counter-intuitive. Of course, my ignorance and familiarity in the matter greatly tempers such choices.

I was doing things like

_createWindow1()
_createWindow2()
_createWindow3()

...

If closing a window Then
     delete a window
     recreate that window again and hide it
EndIf

I reverted back to my error-laden code after making the decision that wasn't very efficient, but I've been wrong many times before.

With that, I came back to the above code and your reply. If the aforemtioned code in this reply is the code in question, then I've managed to correct the problem by first initializing the child window in a hidden state, and when I want to actually use the window I toggle it into view. Like I had said, my knowledge of how all these events and other things are really working sometimes leaves me a bit miffed, but I think I'm starting to develop a stronger conceptual grasp on them.

Unfortunately, even if the above is correct, I still wouldn't understand why the $childWindow variable being in the If-conditional would be the cause of it all.

I appreciate any tips, concepts or pertinent threads that would help to educate me further, though.

Link to comment
Share on other sites

The easiest way I can explain it is:

- At the $childWindow and $browseForFileButton are both undefined until you create a child window, so throughout your main loop, their value is "". (blank)

- Whenever nothing is happening (most of the time), GUIGetMsg returns 0.

- Add these conditions up, and in a numerical comparison, "" is equal to 0.

These lines in your code will be true most of the time, though this isn't what you intended:

Case $guiMsg[0] = $browseForFileButton
              If $guiMsg[1] = $childWindow ThenoÝ÷ ØÂäjº.ܨ¹Ê.×!yÉ¢¼Þ®Þ~Þr)àj|­)àz[jëh×6        Case $guiMsg[0] = 0
            ; Do nothing
        Case $guiMsg[0] = $browseForFileButton
            If $guiMsg[1] = $childWindow Then
                GUICtrlSetData( $fileInput, _browseForFile( "Browse for file:" ) )
            EndIf

The code I gave you in your other topic was also only a workaround. It allowed you to close orphaned child windows, but you would still lose the browse button functionality if you were to apply it to this example.

To fix this for good, I suggest building an array to store the child window handles and child control handles.

[font="Tahoma"]"Tougher than the toughies and smarter than the smarties"[/font]

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...