Robin Dunn wrote:
Hi All,
...just a quick thanks for the replies to my previous post!
It seems that the wxMDIChildren of a wxMDIParentFrame are
handled a bit differently between Linux and Windows, for the
same code.
There is no such thing as MDI on Linux and so it is implemented as tabs
in a notebook. The notebook is the wxMDIClientWindow and the pages are
the wxMDIChildFrame.
I was aware of this from using *nix but had wondered how the wxPython/wxWindows
implementation was done such that the API would remain cross platform.
On Windows, where there is true MDI (although even Microsoft doesn't use
it anymore) the wxMDIClientWindow is the background behind the child
frames, but is technically a sibling of the child frames.
You can think of these differences as implementation details that most
of the time shouldn't matter.
I agree with the "most of the time" part. 
--------------------------------------------------------------------------------------------------
1. If the two-step frame construction process is used to create the MDIParentFrame
on the Windows platform, will the wxMDIClientWindow container then be used to store
the MDIChildren automatically?
No. On windows the MDIParentFrame is the parent of the MDIChildFrames.
On Linux the MDIParentFrame is the parent of the notebook and the
notebook is the parent window of the MDIChildren.
I'm not sure why all this matters though, why not just keep track of the
children yourself?
Why write code to keep track of something when it's already being done?
Unfortunately, the application was heavily developed on Windows initially by one
individual. Then a second individual, who mainly uses Linux, started helping out. But when
the app was run on Linux things stopped working. The problem was tracked down to the
child frame handling differences.
Being new to wxPython, much of the implementation is done by trial and error. Like keeping
track of the child frames for example. It's difficult to overlook the "GetChildren"
method in the documentation when initially trying to decide on the best approach to keep track
of the child frames - and the deal was sealed after doing a "print self.GetChildren()" with
a bunch of child frames open in the app. Why wouldn't an implementation want to use a
built-in method over a manual approach. Well, I know why now, but without the
information you provided here I would not have known. Accept of course for the fact
that our app was misbehaving when run on Linux.
2. If the answer to question 1 is yes, will this have any side-effects on the Linux
platform
in relation to the way the current wxMDIClientWindow functions. I.e., will a second
client window be created or is the two-step process ignored on Linux? Probably a
stupid question but I'll feel better knowing for certain...
3. Has anyone successfully implemented the two-step frame creation process
for an MDIParent frame?
It should work exactly the same as for any other window.
4. If the answer to question 1 is no, then is there something that someone knows about
that
might be causing the discrepancy in behavior noted between the two platforms?
See above.
5 And lastly, if the two-step process won't change the behavior on the Windows platform,
is
there a way to get the client window to be used on the Windows platform, or conversely,
not
used when run on the Linux platform?
No.
Thanks for the info,
Joe
Joseph D. Poirier
DSP Software
IMN, Nokia Inc.
6000 Connection Drive
Irving, TX 75039
···
joseph.poirier@nokia.com wrote: