Hi Robin,
First off, thanks for doing all the work to track this down! By the time I started looking, you were already done. 
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
···
On May 3, 2007, at 10:26 AM, Robin Dunn wrote:
--
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