I thought that, when self.Thaw() is executed, my PC screen would
instantly fill with the initial display.
What I see instead is some of the panel-building and layout happening
before my eyes. A seeming "premature thaw" or "premature
curtain-raising" of sorts. Time from startup to completed display is
only about a second, but the look, to me, is unprofessional.
Any idea what might be causing this behavior? Any idea how I might
zero in on this visual annoyance?
I have never seen something like that. Freezing the main frame should
not show anything happening on it until you Thaw() it. Does anything
change if you use something like:
Yes, self is my main frame, and no, wx.CallAfter(self.Thaw) doesn't change anything.
As I said, the problem is occurring during the building and layout of the initial display. I.e., the freeze and the thaw are part of my main frame's ___init___ code.
This morning I tried binding calls to the same building-and-layout calls to a keypress, and when invoked that way, the visual problem disappears. So the fact that the thaw, even as self.CallAfter(self.Thaw), is part of my main frame's __init__ code seems to be the difference.
With that additional insight, I still don't know what I can do to eliminate the problem at start-up.
···
At 04:53 AM 10/4/2007, Andrea Gavana wrote:
Hi Bob,
On 10/4/07, Bob Klahn wrote:
> In the main frame of one of my applications, I have this sequence:
>
> self.Freeze()
> building-and-layout-of-the-initial-display
> self.Thaw()
I assume "self" is your main frame.
> I thought that, when self.Thaw() is executed, my PC screen would
> instantly fill with the initial display.
>
> What I see instead is some of the panel-building and layout happening
> before my eyes. A seeming "premature thaw" or "premature
> curtain-raising" of sorts. Time from startup to completed display is
> only about a second, but the look, to me, is unprofessional.
>
> Any idea what might be causing this behavior? Any idea how I might
> zero in on this visual annoyance?
I have never seen something like that. Freezing the main frame should
not show anything happening on it until you Thaw() it. Does anything
change if you use something like:
As I said, the problem is occurring during the building and layout of the initial display. I.e., the freeze and the thaw are part of my main frame's ___init___ code.
That may be your problem -- during __init__, your frame may not be at it's final size, so all the layout needs to be re-done after the Frame gets Show()'d. When is Frame.Show() called in this process?
You might be able to do something by catching the EVT_SIZE, and doing your layout there, with Freeze in place.
-Chris
···
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
I call self.Freeze() at the beginning of the frame's __init__, and I've even commented out the thaw, so there's no thaw at all, and still have the problem. I'm mystified.
Bob
···
At 07:50 PM 10/4/2007, Christopher Barker wrote:
Bob Klahn wrote:
As I said, the problem is occurring during the building and layout of the initial display. I.e., the freeze and the thaw are part of my main frame's ___init___ code.
That may be your problem -- during __init__, your frame may not be at it's final size, so all the layout needs to be re-done after the Frame gets Show()'d. When is Frame.Show() called in this process?
You might be able to do something by catching the EVT_SIZE, and doing your layout there, with Freeze in place.
Yes, self is my main frame, and no, wx.CallAfter(self.Thaw) doesn't change anything.
As I said, the problem is occurring during the building and layout of the initial display. I.e., the freeze and the thaw are part of my main frame's ___init___ code.
This morning I tried binding calls to the same building-and-layout calls to a keypress, and when invoked that way, the visual problem disappears. So the fact that the thaw, even as self.CallAfter(self.Thaw), is part of my main frame's __init__ code seems to be the difference.
With that additional insight, I still don't know what I can do to eliminate the problem at start-up.
Freezing a window essentially prevents it and it's children from receiving paint events, so as others have mentioned since your frame has not yet been shown freezing will have no effect, because it is not getting paint events anyway.
Take a look at the size events. That is where the layout is done by default, and there is usually an initial size event when a frame is shown the first time.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!