Probable change or bug

wxPython Users
1

(Python 2.3.5, wxP 2.5.4.1 on XP)

I have discovered that version 2.5.4.1 does not properly display any widgets
on panels panel1B, panel2A and panel2B. The test program is attached.

It works fine as expected using version 2.4.2.4u. Please disregard this message if
already reported or fixed. Is Python 2.4 necessary to use version 2.5.4.1 ?

Thanks,
Ray Pasco

IS.PY (7.8 KB)

2

Hello Ray,

    the widgets on other panels are shown, but the are positioned far from
the view. Try, for example, to comment the 2 lines:

subSplitr1.sashlocked = True
subSplitr2.sashlocked = True

Then, using:

self.Panel1Alayout (self.panel1B)

Try to drag the first top sash to the left. You will see the widgets appear
to the right.
I don't know why this happens, anyway... Robin will probably give you the
answer...

Sorry if that does not help so much.

Andrea.

3

Ray Pasco wrote:

(Python 2.3.5, wxP 2.5.4.1 on XP)

I have discovered that version 2.5.4.1 does not properly display any widgets
on panels panel1B, panel2A and panel2B. The test program is attached.

It works fine as expected using version 2.4.2.4u. Please disregard this message if
already reported or fixed.

Remove the event.Skip() from ProportionalSplitter.OnReSize. It looks like something is the conflicting with the default OnSize handler. Perhaps a safer change is to leave the event.Skip, but delay the call to ResetSash:

     def OnReSize (self, event):
         'Window has been resized, so we need to adjust the sash based on self.proportion.'
         wx.CallAfter(self.ResetSash)
         event.Skip()

Is Python 2.4 necessary to use version 2.5.4.1 ?

No. Binaries also exist for Python 2.3, and I expect that they can be built with no problems for Python 2.2 as well.

···

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

4

Robin Dunn wrote:

Ray Pasco wrote:

(Python 2.3.5, wxP 2.5.4.1 on XP)

I have discovered that version 2.5.4.1 does not properly display any widgets
on panels panel1B, panel2A and panel2B. The test program is attached.

It works fine as expected using version 2.4.2.4u. Please disregard this message if
already reported or fixed.

Remove the event.Skip() from ProportionalSplitter.OnReSize. It looks like something is the conflicting with the default OnSize handler. Perhaps a safer change is to leave the event.Skip, but delay the call to ResetSash:

    def OnReSize (self, event):
        'Window has been resized, so we need to adjust the sash based on self.proportion.'
        wx.CallAfter(self.ResetSash)
        event.Skip()

Is Python 2.4 necessary to use version 2.5.4.1 ?

No. Binaries also exist for Python 2.3, and I expect that they can be built with no problems for Python 2.2 as well.

Thanks ! - That did the trick. That was strange, though. I have reinstalled 2.5 and life is good.

I have no idea why your fix works. I have looked and looked, but could not find descriptions
of what event.skip, event.veto and wx.CallAfter do.
Where can I find explanations of the methods available for event handlers ?

Thanks

5

Hi Ray,

Ray Pasco wrote:

Robin Dunn wrote:

Ray Pasco wrote:

(Python 2.3.5, wxP 2.5.4.1 on XP)

I have discovered that version 2.5.4.1 does not properly display any widgets
on panels panel1B, panel2A and panel2B. The test program is attached.

It works fine as expected using version 2.4.2.4u. Please disregard this message if
already reported or fixed.

Remove the event.Skip() from ProportionalSplitter.OnReSize. It looks like something is the conflicting with the default OnSize handler. Perhaps a safer change is to leave the event.Skip, but delay the call to ResetSash:

    def OnReSize (self, event):
        'Window has been resized, so we need to adjust the sash based on self.proportion.'
        wx.CallAfter(self.ResetSash)
        event.Skip()

Is Python 2.4 necessary to use version 2.5.4.1 ?

No. Binaries also exist for Python 2.3, and I expect that they can be built with no problems for Python 2.2 as well.

Thanks ! - That did the trick. That was strange, though. I have reinstalled 2.5 and life is good.

I have no idea why your fix works. I have looked and looked, but could not find descriptions
of what event.skip, event.veto and wx.CallAfter do.
Where can I find explanations of the methods available for event handlers ?

Check out the new wxPython API doc:

CallAfter(callable, *args, **kw)
Call the specified function after the current and pending event handlers have been completed. This is also good for making GUI method calls from non-GUI threads. Any extra positional or keyword args are passed on to the callable when it is called.
See Also: wx.FutureCall

Skip(self, skip=True)
Called by an event handler, it controls whether additional event handlers bound to this event will be called after the current event handler returns. Skip(false) (the default setting) will prevent additional event handlers from being called and control will be returned to the sender of the event immediately after the current handler has finished. Skip(True) will cause the event processing system to continue searching for a handler function for this event.
Parameters:
skip
           (type=bool)

See you
Werner

···

Thanks

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

6

Werner F. Bruhin wrote:

Hi Ray,

Ray Pasco wrote:

I have no idea why your fix works. I have looked and looked, but could not find descriptions
of what event.skip, event.veto and wx.CallAfter do.
Where can I find explanations of the methods available for event handlers ?

Check out the new wxPython API doc:

CallAfter(callable, *args, **kw)
Call the specified function after the current and pending event handlers have been completed. This is also good for making GUI method calls from non-GUI threads. Any extra positional or keyword args are passed on to the callable when it is called.
See Also: wx.FutureCall

Skip(self, skip=True)
Called by an event handler, it controls whether additional event handlers bound to this event will be called after the current event handler returns. Skip(false) (the default setting) will prevent additional event handlers from being called and control will be returned to the sender of the event immediately after the current handler has finished. Skip(True) will cause the event processing system to continue searching for a handler function for this event.

So to answer the original question, calling Skip prevents the splitter window's default EVT_SKIP handler from being called. There have been several changes to the splitter window since 2.4 and one of them apparently caused a conflict in your app if it was run after your OnSize handler.

···

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