I have problem with wx.EVT_SIZE event propagation.
My environment is Python 2.7.2 x86 and wxPython 2.8.12.1.
I have form with wx.SplitterWindow and wx.TreeCtrl in first, and wx.Notebook in second panel.
The notebook control contains panel and another notebook control with another panel.
My problem is that when I'm changing size of form, the last control that receives EVT_SIZE
is pgfPartnerData and event propagation stops here. None of child notebook pages and its children
receive this event any more.
But when I size my form with splitter, EVT_SIZE events are propagated correctly and all "pgfPartnerData" container children are sized as they should.
I don't use EVT_SIZE handlers in my application except logging purposes.
All native wx classes are mixed with custom classes.
I tested my code against developer, 2.9.2.4 version and there is no such problem with it,
but switching to unstable branch is the last thing I consider.
Did anybody encounter such problems?
Any advices please?
EVT_SIZE events are not command events, so they do not propagate. They may appear to propagate as the size event handler for a window may cause one or more of its children to be resized, and that will then cause those children to get their own size event to report their own change in size. If the parent's sizer (or whatever) does not cause the child to change size then the child will not get a size event, perhaps that is what you are seeing? If you can duplicate the problem in a small runnable sample, and you do not discover the solution to the problem in the process, then send it here and somebody will take a closer look at it. MakingSampleApps - wxPyWiki
BTW, the word "unstable" for the 2.[odd number].x release series does not mean that it is worse than the most recent stable branch in any way, in fact the opposite is often true. Unstable only means that the API is allowed to change in backwards incompatible ways. ReleaseSeries - wxPyWiki
···
On 9/27/11 2:39 AM, Jacek Kałucki wrote:
Hi.
I have problem with wx.EVT_SIZE event propagation.
My environment is Python 2.7.2 x86 and wxPython 2.8.12.1.
I have form with wx.SplitterWindow and wx.TreeCtrl in first, and
wx.Notebook in second panel.
The notebook control contains panel and another notebook control with
another panel.
My problem is that when I'm changing size of form, the last control that
receives EVT_SIZE
is pgfPartnerData and event propagation stops here. None of child
notebook pages and its children
receive this event any more.
But when I size my form with splitter, EVT_SIZE events are propagated
correctly and all "pgfPartnerData" container children are sized as they
should.
I don't use EVT_SIZE handlers in my application except logging purposes.
All native wx classes are mixed with custom classes.
I tested my code against developer, 2.9.2.4 version and there is no such
problem with it,
but switching to unstable branch is the last thing I consider.
Did anybody encounter such problems?
Any advices please?
EVT_SIZE events are not command events, so they do not propagate. They may appear to propagate as
the size event handler for a window may cause one or more of its children to be resized, and that
So, let's name it forwarding.
will then cause those children to get their own size event to report their own change in size. If
the parent's sizer (or whatever) does not cause the child to change size then the child will not get
a size event, perhaps that is what you are seeing? If you can duplicate the problem in a small
Is there a way to determine if child EVT_SIZE will be fired or not?
I compare control size from previous events and size is always changed, but children
doesn't receive EVT_SIZE event.
It looks like it depends on depth of container structure.
If I remove one container from the chain, e.g. parent wx.Panel and put controls directly
on the wx.ScrolledWindow, child controls events are fired.
I will try to create simple application to demonstrate the problem.
BTW, the word "unstable" for the 2.[odd number].x release series does not mean that it is worse than
the most recent stable branch in any way, in fact the opposite is often true. Unstable only means
that the API is allowed to change in backwards incompatible ways.
It's sounds like one of the criterion of stability for me.
I have never had anything break when I programmed in the "unstable" release and I don't expect
anything to break this time either.
Really? You were lucky. I give you only two samples but there are more:
- wx.GetMouseState().leftDown changed to wx.GetMouseState().leftIsDown
- wx.lib.platebtn.PlateButton class parameter "id_" changed to "id".
These are differences between current stable 2.8.11.1 and 2.9.2.4 development version.
