does Close() automatically Raise() parent frame?

[Bogdan Valentin Neacsa]

Hello,

I've attached a demo with my problem. Basically I want a root frame on which I add some dialog. When I press a button on this dialog I want the dialog to be destroyed and another dialog to be created and raised on top of the window.

Bu what happens is the main window is raised on top of my newly created dialog. As far as I can tell the Close() call somehow does this, because if I comment that out I get what I want. But now my 1st dialog is not destroyed anymore.

How can I achieve my desired use case?

All the best,

Bogdan

[Yoriz]

call the method self.frame.Show() before calling tipdlg.ShowModal()

[Bogdan Valentin Neacsa]

Thanks for input. That solved the problem for two dialogs. But now I'm trying the same only a little more complex. Meaning I have frame, open a dialog, and now on button I want to open some other Frame instead of a dialog with the same effect as before. 

This time second frame is being pushed behind root frame on close and solution from before no longer works.  

[Tim Roberts]

Bogdan Valentin Neacsa wrote:
> Thanks for input. That solved the problem for two dialogs. But now I'm
> trying the same only a little more complex. Meaning I have frame, open
> a dialog, and now on button I want to open some other Frame instead of
> a dialog with the same effect as before.
> This time second frame is being pushed behind root frame on close and
> solution from before no longer works.

You might step back a bit and thing about whether this is really a
usable design to begin with. People don't necessarily expect a dialog
button to close a dialog and open another. Would your design be better
suited to a wizard-like design, where the window reconfigures itself as
you move from step to step?

--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.

[Bogdan Valentin Neacsa]

Sadly this is not a start from scratch but rather a small bug in an already existing bigger solution so changing the entire design would be hard to do. Is there no way to make the actual design work ?

[Tim Roberts]

Bogdan Valentin Neacsa wrote:
> Sadly this is not a start from scratch but rather a small bug in an
> already existing bigger solution so changing the entire design would
> be hard to do. Is there no way to make the actual design work ?

Probably, but it's just going to take some experimentation. When you
display a dialog modally, it starts its own message loop that sucks up
messages for the dialog. When you close the dialog, there's an awkward
race condition where it tries to bring back the window that was frozen.
If messages get lost or out of order, you get strange shuffling.

You're going to have to experiment with delays (and maybe CallAfter) to
see if you can get the windows raised in the right order.