Tracked down OS X MDI demo crash

... but I don't quite understand it, because the problem only affects wxPython code, though the fix is in the C++ code.

Basically, a recent addition to the Mac MDI code (src/mac/carbon/mdi.cpp) overrides wxMDIParentFrame::AddChild, and dynamically hides the parent window when a child is created. However, if wxFrame::AddChild is called after wxFrame::Show(FALSE) (as is done here), then AddChild seems not to add the window to the list of children. Switching the order solves of the calls fixes the problem, but what is bizarre is that it only affects the wxPython end of things - the MDI sample still runs just fine.

BTW, why is it that we need to show and then hide a main window? Is this due to the old MDI code? Because it's very awkward, and having code to hide it automatically when children are created (not app developer or user's choice) seems odd. Aren't there replacements for this we could write demos for, i.e. pydocview?

Oh, and it's technically Christmas here now, so Merry Christmas! :wink:

Thanks,

Kevin

Kevin Ollivier wrote:

... but I don't quite understand it, because the problem only affects wxPython code, though the fix is in the C++ code.

Basically, a recent addition to the Mac MDI code (src/mac/carbon/mdi.cpp) overrides wxMDIParentFrame::AddChild, and dynamically hides the parent window when a child is created. However, if wxFrame::AddChild is called after wxFrame::Show(FALSE) (as is done here), then AddChild seems not to add the window to the list of children. Switching the order solves of the calls fixes the problem, but what is bizarre is that it only affects the wxPython end of things - the MDI sample still runs just fine.

Wierd. Is it just the wxPython MDI demos or is it any MDI code in wxPython? If the former then it may have something to do with being run from the demo and already having a normal frame in the app...

BTW, why is it that we need to show and then hide a main window? Is this due to the old MDI code? Because it's very awkward, and having code to hide it automatically when children are created (not app developer or user's choice) seems odd.

I think it is done to allow the app to be started with no wx.MDIChildFrames active and yet still have something visible (perhaps with a toolbar, etc.) to let the user know that the app is running but there are no document windows active yet. On the other hand, the Mac way of doing this seems to be to just have the menu bar active and no other windows...

···

Aren't there replacements for this we could write demos for, i.e. pydocview?

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

Hi Robin,

Quoting Robin Dunn <robin@alldunn.com>:

Kevin Ollivier wrote:
> ... but I don't quite understand it, because the problem only affects
> wxPython code, though the fix is in the C++ code.
>
> Basically, a recent addition to the Mac MDI code
> (src/mac/carbon/mdi.cpp) overrides wxMDIParentFrame::AddChild, and
> dynamically hides the parent window when a child is created. However, if
> wxFrame::AddChild is called after wxFrame::Show(FALSE) (as is done
> here), then AddChild seems not to add the window to the list of
> children. Switching the order solves of the calls fixes the problem, but
> what is bizarre is that it only affects the wxPython end of things - the
> MDI sample still runs just fine.

Wierd. Is it just the wxPython MDI demos or is it any MDI code in
wxPython? If the former then it may have something to do with being run
from the demo and already having a normal frame in the app...

I just ran the MDI Demo independently of the main wxPython demo (should have
thought of that sooner!) and it runs fine. So yes, it's got something to do
with the main TLW already existing for the wxPy demo.

>
> BTW, why is it that we need to show and then hide a main window? Is this
> due to the old MDI code? Because it's very awkward, and having code to
> hide it automatically when children are created (not app developer or
> user's choice) seems odd.

I think it is done to allow the app to be started with no
wx.MDIChildFrames active and yet still have something visible (perhaps
with a toolbar, etc.) to let the user know that the app is running but
there are no document windows active yet. On the other hand, the Mac
way of doing this seems to be to just have the menu bar active and no
other windows...

That's right, it's the toolbar and status bar issue from the Windows-centric
API. ;-/ It still doesn't make sense though in terms of hiding it when a child
is created... I'll check if the parent frame checks for toolbar and status bar
before hiding or showing, but it doesn't appear to do so.

Since it appears to be only a Mac+wxPy demo issue, what I think would probably
be best in the short term is to spawn a new process for the MDI app demo. In
the long term (hopefully a few days or weeks!), I'd like to construct a new
demo with the ActiveGrid pydocview classes, then deprecate the MDI demo due to
its quirky behavior on Mac.

Thoughts?

Thanks,

Kevin

···

> Aren't there replacements for this we could
> write demos for, i.e. pydocview?

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

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

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

kevino@theolliviers.com wrote:

Since it appears to be only a Mac+wxPy demo issue, what I think would probably
be best in the short term is to spawn a new process for the MDI app demo. In
the long term (hopefully a few days or weeks!), I'd like to construct a new
demo with the ActiveGrid pydocview classes, then deprecate the MDI demo due to
its quirky behavior on Mac.

Thoughts?

Makes sense to me.

···

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