wxSplitterWindow.ReplaceWindow---SOLUTION

Hi all,
Sorry you had to put up with my raving, but I found the solution - FYI - for
anyone with similar problems in a SplitterWindow.

What I'm doing at the most basic level is Replacing the current window in a
SplitterWindow pane with a different one. I had a previous panel there with
a static bitmapped centered on the panel What appears to be happening
(nothing works until I size the frame larger..) is that the OLD window is
still getting the mouseover events, acting like a transparent shield over
the new HtmlWindow below. I can SEE the HtmlWindow, but not do anything.
Since it was a static bitmap, the "shield" size isn't changing, so when I
size the frame larger, my controls eventually "expose" themselves from
underneath it and then THEY work O.K. as long as they're exposed. When I
size the frame smaller, they get "hidden" again.
Make sense?

The wxWindows docs mention that the wxSplitterWindow.ReplaceWindow feature
doesn't destroy the old window and you may want to do that manually, but I
wasn't doing it correctly. Now that I'm properly destroying the OLD window,
everything in the NEW window is working perfectly.

···

----- Original Message -----
From: "Rick Zoerner" <rick@zoerner.com>
To: "WxPython-users" <wxPython-users@lists.wxwindows.org>
Sent: Sunday, January 04, 2004 8:28 PM
Subject: Re: wxSplitterWindow.ReplaceWindow question

Oh, this just gets better and better...

Now I've noticed that, in addition to all the symptoms I've outlined

below -

when the frame is maximized by the user, then everything starts to work.

The

links work (all except the first one in the html file) and the buttons

work.

But only when maximized, as soon as you click to restore, they stop

working

again. I can manually size the screen to the max width & height possible

by

dragging, but the controls won't work until I click on the maximize

control.

So, the ScrolledWindow scrollbar only works when the frame is sized larger
than the original disply, and the other buttons and html links only work
when the frame is maximized.

Has anybody seen something like this before?

----- Original Message -----
From: "Rick Zoerner" <rick@zoerner.com>
To: "WxPython-users" <wxPython-users@lists.wxwindows.org>
Sent: Sunday, January 04, 2004 8:48 AM
Subject: Re: wxSplitterWindow.ReplaceWindow question

I just noticed my problem with the window scrollbar not working until

after

I manually size the frame is more weird than just that. It only works

after

I size the frame LARGER. Then, after scrolling up and down for awhile, if

I

size the frame back to its original size or smaller - it stops working
again.

I wonder if it has to do with me specifically setting the original frame
size in Main(wxApp) using MainFrame.SetSize((630,450)). I had to do it

there

as well as in MainFrame itself (inside MainFrame its set to (631,451)
because when it was set in MainFrame only, my notebook pages (tabs)

wouldn't

display properly until I resized the frame, so I made that the last entry

in

Main(wxApp) to force the change.

Is that now forcing a minimum size nothing will work properly below?, If
so - how would I resolve the original problem of the notebook not

displaying

without causing this side-effect. I have SetAutoLayout(1) enabled
everywhere, and self.Layout() called as the last execution of my MainFrame
class - but obviously that's not enough.

  From: "Rick Zoerner" <rick@zoerner.com>
  Subject: wxSplitterWindow.ReplaceWindow question

  Hi all,

  After 10+ hours of frustration its time to swallow my pride and ask
somebody...

  I'm constructing what I imagine is a fairly simple interface in

2.4.2.4u,

with a MainFrame carrying a single SplitterWindow. The left side (pane_1)
will house some control elements in a notebook, while the right side
(pane_2) will display the "working" Panel.

  I've implemented a method (Swap) in MainFrame to call
SplitterWindow.ReplaceWindow whenever required (the method also allows me

to

SetMenuBar, SetToolBar, and Pop-and-PushEventHandler at the frame level at
the same time).

      def Swap(self, package='package', pmod='module', pclass='class',
menubar='menubar', toolbar='toolbar', events='events'):
          global PANEL
          if pclass != 'class':
              PANEL['class'] = pclass
              exec 'import ' + PANEL['package'] + "." + PANEL['module']
              self.newpanel = eval(PANEL['package'] + "." +

PANEL['module']

+ "." + PANEL['class'])
              window_1.ReplaceWindow(pane_2, self.newpanel(window_1, -1))

  I'm currently bringing in a very slightly modified version of

ieHtmlWindow

from the demo directory - it runs like a charm when run directly or
instantiated alone in a frame.

  So far this works perfectly in terms of every other aspect of what I

want

to do (i.e. menubar, toolbar and eventhandler stuff), and it initializes &
displays the new panel just fine. That's where I run into two problems.

  1) The image displays, the window's scrollbar displays, but nothing

works

until I manually resize the frame. I have tried Layout(), Refresh(),
Update() at all three levels (frame_1, frame_1.window_1, and
frame_1.window_1_pane_2) without success. I have also tried
frame_1.Resize((x, y,)) with no luck. I have only tried inserting commands
as the next line after the snippet I've shown here, though, so that might

be

the problem. But I was hoping this could happen inside the MainFrame.Swap
method....

  2) Same thing as above, with respect to focus of the window. The links
don't link, the buttons at the top don't work, nothing. Again, the file
being swapped in runs perfectly when run alone outside this application.
I've tried Raise(), SetFocus(), Enable(), and again, at all three levels -
frame, window, & pane.

  Any ideas greatly appreciated. Mine certainly don't work.

Rick Zoerner wrote:

> What appears to be happening

(nothing works until I size the frame larger..) is that the OLD window is
still getting the mouseover events, acting like a transparent shield over
the new HtmlWindow below. I can SEE the HtmlWindow, but not do anything.
Since it was a static bitmap, the "shield" size isn't changing, so when I
size the frame larger, my controls eventually "expose" themselves from
underneath it and then THEY work O.K. as long as they're exposed. When I
size the frame smaller, they get "hidden" again.
Make sense?

Yep, this is a known issue on windows and is one of the reasons that overlapping of sibling windows/controls is not supported.

The wxWindows docs mention that the wxSplitterWindow.ReplaceWindow feature
doesn't destroy the old window and you may want to do that manually, but I
wasn't doing it correctly. Now that I'm properly destroying the OLD window,
everything in the NEW window is working perfectly.

Which is exactly what I was going to suggest, but you figured it out first! :slight_smile:

···

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