two questions about this app

Attached are two files for a sample program that uses a notebook control. I have two issues:

1. When a tab is opened, it gives it the shaded color of a panel, whereas expanding the window will reveal the whiter color of a notebook. I've mentioned this before and I guess nothing can be done about it right now. It seems to be the effect of adding a new panel item to the notebook.

2. Adding a new tab causes that tab to be overlayed with the existing one, and this corrects itself only after switching tabs. As far as I can tell, everything is the child of what it should be, but I've been wrong before! :slight_smile:

dbgui.xrc (3.85 KB)

dbapp.py (613 Bytes)

John Salerno wrote:

2. Adding a new tab causes that tab to be overlayed with the existing one, and this corrects itself only after switching tabs. As far as I can tell, everything is the child of what it should be, but I've been wrong before! :slight_smile:

What I mean here is that all the widgets within the notebook tab (static text and text controls) appear on top of the previous widgets.

John Salerno wrote:

2. Adding a new tab causes that tab to be overlayed with the existing one, and this corrects itself only after switching tabs. As far as I can tell, everything is the child of what it should be, but I've been wrong before! :slight_smile:

Ok, a little testing has shed some light, I think. It seems that when this line is run:

self.page = self.res.LoadPanel(self.notebook, 'dataPage')

The Panel is loaded and appears in the frame before this line gets a chance to run:

self.notebook.AddPage(self.page, 'title')

The second line "fits" the panel into the notebook and makes it look nice, but what seems to be happening first is that the panel just appears "on top" of the notebook, not in it, and that's what causes this problem. But I don't know how to fix this, because a dynamically created widget like this panel would need to be loaded in this way, right? But it's this step that seems to cause the problem.

I think what I need is a way to load the panel into a variable, yet not have it *run* in the program. Then I can just add it to the notebook, just like you'd normally do in a program that doesn't use XRC:

page = DataPage(self.nb) #doesn't do any loading of the panel, just creates it
self.nb.AddPage(page, 'title')

John Salerno wrote:

Attached are two files for a sample program that uses a notebook control. I have two issues:

1. When a tab is opened, it gives it the shaded color of a panel, whereas expanding the window will reveal the whiter color of a notebook. I've mentioned this before and I guess nothing can be done about it right now. It seems to be the effect of adding a new panel item to the notebook.

This has been fixed in 2.7.

2. Adding a new tab causes that tab to be overlayed with the existing one, and this corrects itself only after switching tabs. As far as I can tell, everything is the child of what it should be, but I've been wrong before! :slight_smile:

An easy workaround for this is to pass True as the 3rd parameter to AddPage so the new page will be selected, or add a call to self.notebook.Refresh().

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

John Salerno wrote:

John Salerno wrote:

2. Adding a new tab causes that tab to be overlayed with the existing one, and this corrects itself only after switching tabs. As far as I can tell, everything is the child of what it should be, but I've been wrong before! :slight_smile:

Ok, a little testing has shed some light, I think. It seems that when this line is run:

self.page = self.res.LoadPanel(self.notebook, 'dataPage')

The Panel is loaded and appears in the frame before this line gets a chance to run:

self.notebook.AddPage(self.page, 'title')

The second line "fits" the panel into the notebook and makes it look nice, but what seems to be happening first is that the panel just appears "on top" of the notebook, not in it, and that's what causes this problem.

Yep. This is a side-effect of non-top-level widgets being created in the shown state.

But I don't know how to fix this, because a dynamically created widget like this panel would need to be loaded in this way, right? But it's this step that seems to cause the problem.

There are some tricks to allow a window to be created in a hidden state, but I don't know off the top of my head if they can work from Python, or from XRC for that matter...

I think what I need is a way to load the panel into a variable, yet not have it *run* in the program.

There is no difference between creating and running. If the widget is created then it exists and the UI knows about it and interacts with it.

Then I can just add it to the notebook, just like you'd normally do in a program that doesn't use XRC:

page = DataPage(self.nb) #doesn't do any loading of the panel, just creates it
self.nb.AddPage(page, 'title')

You can't add the page to the notebook until it is created...

I just had another thought. Try adding "<size>0,0</size>" to the panel's XRC definition. That should be nearly the same as creating it in a hidden state.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

Robin Dunn wrote:

1. When a tab is opened, it gives it the shaded color of a panel, whereas expanding the window will reveal the whiter color of a notebook. I've mentioned this before and I guess nothing can be done about it right now. It seems to be the effect of adding a new panel item to the notebook.

This has been fixed in 2.7.

Excellent!

2. Adding a new tab causes that tab to be overlayed with the existing one, and this corrects itself only after switching tabs. As far as I can tell, everything is the child of what it should be, but I've been wrong before! :slight_smile:

An easy workaround for this is to pass True as the 3rd parameter to AddPage so the new page will be selected, or add a call to self.notebook.Refresh().

Ah ha! I was wondering if there was such a "refresh" trick, and it looks good now!

Robin Dunn wrote:

The second line "fits" the panel into the notebook and makes it look nice, but what seems to be happening first is that the panel just appears "on top" of the notebook, not in it, and that's what causes this problem.

Yep. This is a side-effect of non-top-level widgets being created in the shown state.

But isn't it considered a top-level widget in this case, since it's not a child of my main frame (or anything else)?

Robin Dunn wrote:

I just had another thought. Try adding "<size>0,0</size>" to the panel's XRC definition. That should be nearly the same as creating it in a hidden state.

Works! :slight_smile:

John Salerno wrote:

Robin Dunn wrote:

The second line "fits" the panel into the notebook and makes it look nice, but what seems to be happening first is that the panel just appears "on top" of the notebook, not in it, and that's what causes this problem.

Yep. This is a side-effect of non-top-level widgets being created in the shown state.

But isn't it considered a top-level widget in this case, since it's not a child of my main frame (or anything else)?

It's a top-level node in the XRC, but in the UI it is not a top-level window. Top-level windows are managed directly by the OS or platform environment, such as frames and dialogs.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

I'm using the 2-step approach, which creates the panel hidden and allows to
add it to the notebook sizer afterwards.
My little method that spits out the panel looks like

def getPanel(self,_parent):
        mrx=XmlResource('orgl.xrc')
        _panel=wx.PrePanel()
        mrx.LoadOnPanel(_panel,_parent,'ORGL')
        del mrx
        return _panel

  UC

···

On Tuesday 10 October 2006 13:33, Robin Dunn wrote:

> But I don't know how to fix this, because a dynamically created
> widget like this panel would need to be loaded in this way, right? But
> it's this step that seems to cause the problem.

There are some tricks to allow a window to be created in a hidden state,
but I don't know off the top of my head if they can work from Python, or
from XRC for that matter...

--
Open Source Solutions 4U, LLC 1618 Kelly St
Phone: +1 707 568 3056 Santa Rosa, CA 95401
Cell: +1 650 302 2405 United States
Fax: +1 707 568 6416

Robin Dunn wrote:

John Salerno wrote:

Robin Dunn wrote:

The second line "fits" the panel into the notebook and makes it look nice, but what seems to be happening first is that the panel just appears "on top" of the notebook, not in it, and that's what causes this problem.

Yep. This is a side-effect of non-top-level widgets being created in the shown state.

But isn't it considered a top-level widget in this case, since it's not a child of my main frame (or anything else)?

It's a top-level node in the XRC, but in the UI it is not a top-level window. Top-level windows are managed directly by the OS or platform environment, such as frames and dialogs.

::lightbulb comes on::

Robin Dunn wrote:

It's a top-level node in the XRC, but in the UI it is not a top-level window. Top-level windows are managed directly by the OS or platform environment, such as frames and dialogs.

Speaking of actual top-level frames, does XRC take care of setting this for you? I know the SetTopWindow method wasn't really necessary, but I used to call it anyway when creating a frame, but now I'm not sure if I can still do it, using XRC, or if I need to. But if I were to have two or more XRC top-level frames, then would I still need to call SetTopWindow when those frames are created?

John Salerno wrote:

Robin Dunn wrote:

It's a top-level node in the XRC, but in the UI it is not a top-level window. Top-level windows are managed directly by the OS or platform environment, such as frames and dialogs.

Speaking of actual top-level frames, does XRC take care of setting this for you? I know the SetTopWindow method wasn't really necessary, but I used to call it anyway when creating a frame, but now I'm not sure if I can still do it, using XRC, or if I need to. But if I were to have two or more XRC top-level frames, then would I still need to call SetTopWindow when those frames are created?

Scratch that question. It's just a matter of adding self.SetTopWindow(self.frame) right before the self.frame.Show() call!