[wxPython-dev] wxPython preview build

[Kevin Ollivier]

Hi Robin,

First off, thanks for doing all the work to track this down! By the  
time I started looking, you were already done. ;-)

On May 3, 2007, at 10:26 AM, Robin Dunn wrote:

> Andrea Gavana wrote:
>> Hi Robin,
>>    maybe you already explained it somewhere, but in running the
>> SizedControls demo I still get those warnings:
>> Debug: ..\..\include\wx/msw/private.h(338): 'GetWindowRect' failed
>> with error 0x00000578 (invalid window handle.).
>
> This is happening because the child widgets are being added to the  
> sizer from within the panel's overridden AddChild method, and the  
> sizer Add results in a call to the GetWindowRect API, but the  
> widget's window handle hasn't yet been set in the wx C++ class.
>
> Kevin, can you think of a way to defer the sizer parts of AddChild  
> until after the child widget is fully constructed?  I'm hesitant to  
> suggest using wx.CallAfter because that might be too late for some  
> situations...  The other alternative is to change wx to not call  
> parent->AddChild until after it has created the native widget, but  
> there are a lot of places that would have to be changed, and would  
> likely introduce more problems.

Actually, it may not be so bad. AddChild is called 10 times in MSW  
sources, and none in generic. It doesn't seem to get called in the  
headers anywhere. Furthermore, even in the MSW port the order is not  
consistent - some controls initialize the native control before  
calling AddChild, others don't. I'm beginning to think the only  
reason the code is this way in window.cpp is for historical reasons;  
i.e. the first version was like this and no one came across a reason  
to change it. (And yes, I checked - the first version is like this. :-)

Also, the reason we don't get any asserts, etc. like this on other  
ports is that they tend to call AddChild after the native control is  
created, so we're not only inconsistent across controls, but across  
ports, as well. The fact that this never introduced an issue with the  
generic controls suggests to me that AddChild works fine whether or  
not the native control is initialized. As for the other way around,  
there's a call to MSWGetParent() in MSWCreate() that would need  
changed since it references m_parent, but otherwise, I don't think  
there's anywhere else in native control initialization that expects  
the wxWin hierarchy to be in place, and even if I'm wrong, I doubt  
this is an area where the bugs will be subtle ones. ;-)

In any case, IMHO, we're better off initializing the native control  
as soon as possible, as most control methods rely on this being the  
case and I don't see any reason this can't work (though we should  
ask, of course).

> We can also just suppress the log message during the sizer.Add(),  
> but that is just a band-aide solution that covers the real issue.

I suggest we apply the band-aid solution to 2.8, and look into fixing  
the issue for 3.0. If we're going to fix things, now is about the  
best time to do so, as I don't think 3.0 will be out any time soon  
and hopefully we'll have our GUI testing framework in place by fall  
which I think will help ease our nerves a bit when it comes to  
refactoring.

Thanks,

Kevin

> -- 
> Robin Dunn
> Software Craftsman
> http://wxPython.org  Java give you jitters?  Relax with wxPython!
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wxPython-dev-unsubscribe at lists.wxwidgets.org
> For additional commands, e-mail: wxPython-dev-help at lists.wxwidgets.org
>