[wxPython] Does GetParent and GetChildren Work?
Gordon Williams
I am having problems with GetParent and GetChildren. I think they are
producing strange results.
I have a panel with 3 buttons and two scrollwindows. The panel (self) and
one of the scollwindows are (using print):
self <C wxPanel instance at _163b940_wxPanel_p>
self.digitalCanvas <C wxScrolledWindow instance at
_1638c90_wxScrolledWindow_p>
This looks OK.
Now when I use getchildren in the panel, I get:
getchildren
[<C wxWindow instance at _1638ef0_wxWindow_p>,
<C wxWindow instance at _163bef0_wxWindow_p>,
<C wxWindow instance at _1638030_wxWindow_p>,
<C wxWindow instance at _163ca40_wxWindow_p>,
<C wxWindow instance at _1638c90_wxWindow_p>]
These (3 buttons and 2 scrollwindows) are all identified as wxWindow. The
1638c90 numbers match although.
When I use getparent from the scrollwindow I get:
getparent <C wxWindow instance at _163b940_wxWindow_p>
Again this is identified as a wxWindow instead of a wxPanel but the 163b940
number matches the panel number above.
When I try self.GetParent().digitalCanvas from the scrolledwindow, I
expected this to be the same as self.digitalCanvas from the panel, but
instead I get:
AttributeError: digitalCanvas
Any ideas?
Regards,
Gordon Williams
_______________________________________________
wxPython-users maillist - wxPytho...@starship.python.net
http://starship.python.net/mailman/listinfo/wxpython-users
Robin Dunn
> producing strange results.
>
> I have a panel with 3 buttons and two scrollwindows. The panel (self) and
> one of the scollwindows are (using print):
> self <C wxPanel instance at _163b940_wxPanel_p>
> self.digitalCanvas <C wxScrolledWindow instance at
> _1638c90_wxScrolledWindow_p>
>
> This looks OK.
>
> Now when I use getchildren in the panel, I get:
> getchildren
> [<C wxWindow instance at _1638ef0_wxWindow_p>,
> <C wxWindow instance at _163bef0_wxWindow_p>,
> <C wxWindow instance at _1638030_wxWindow_p>,
> <C wxWindow instance at _163ca40_wxWindow_p>,
> <C wxWindow instance at _1638c90_wxWindow_p>]
>
> These (3 buttons and 2 scrollwindows) are all identified as wxWindow. The
> 1638c90 numbers match although.
>
This is a known problem (or if I was microsoft it is a known feature! ;-) it
has to do with a shortcoming of SWIG. When a function or method returns a
wxWindow* it has no way to tell if it is really a wxPanel created from
Python, (so there would be a Python object for it somewhere,) or a wxTextCtrl
created somewhere in the C++ code, (so there is not a python object.) SWIG
just takes the simple approach and just makes a new shadow object that
matches the type returned from the C++ method.
There is a workaround (ok, a blatent hack, I admit it,) that will help in
some situations, but not all. There is a function available called
wxPyTypeCast that will take a shadow object of one type and create a new
shadow object of another type, using the same underlying C++ pointer. For
example, say you call
tc = panel.FindWindowById(101)
to get a reference to a wxTextCtrl on a panel. You get a wxWindow back but
since you know it's a wxTextCtrl you can do this:
tc = wxPyTypeCast(panel.FindWindowById(101))
and now it is really a wxTextCtrl object, but still not the same python
object that was originally created, so if you set any extra attributes they
will be lost.
However there is no need to light yourself on fire and run screaming from the
building yelling, "That is SO stupid!" (I already know that! <wink>) because
a couple nights ago I had a major brainstorm (ouch!) about how to fix it so
the original python objects are always returned. At least for all the window
types and probably for OGL and some others too. Previously I had been
concerned about the amount of overhead added everytime when it is only really
needed in maybe 10% of the cases when the hack doesn't work, but I have a
couple pages of scribbles that promise to provide a solution that doesn't add
very much overhead at all. (Okay, it was very late at night, I don't
remember much about writing the notes. Maybe it was a band of elves that
sneaked into my hotel room to solve the world's problems for me...) <wink>
--
Robin Dunn
Software Craftsman
ro...@AllDunn.com
http://AllDunn.com/robin/
http://AllDunn.com/wxPython/ Check it out!
Gordon Williams
>From the scrolledwindow, Self.GetParent() produces
getparent <C wxWindow instance at _15ca250_wxWindow_p>
type is <type 'instance'>
the parent is actually a wxPanel, not a wxWindow.
What does this tell you? I guess it is a bug.
Regards,
Gordon Williams
----------
> From: Mike Fletcher <mfl...@tpresence.com>
> To: 'g_w...@cyberus.ca'
> Subject: RE: [wxPython] Does GetParent and GetChildren Work?
> Date: January 25, 2000 10:28 PM
>
> Sounds like it might be an unwrapped C object? Try doing type() on the
> results and see if you get InstanceType or a builtin type. There was a
> similar problem with some of the COM objects returning builtin types that
> looked identical to their Python cohorts (by design).
>
> About the only thing I can think of,
> Mike
>
> -----Original Message-----
> From: Gordon Williams [mailto:g_w...@cyberus.ca]
> Sent: Monday, January 24, 2000 10:37 AM
> To: wxpytho...@server.python.net
> Subject: [wxPython] Does GetParent and GetChildren Work?
>
>
> Hi All,
>
> I am having problems with GetParent and GetChildren. I think they are
> producing strange results.
>
> I have a panel with 3 buttons and two scrollwindows. The panel (self)
and
> one of the scollwindows are (using print):
> self <C wxPanel instance at _163b940_wxPanel_p>
> self.digitalCanvas <C wxScrolledWindow instance at
> _1638c90_wxScrolledWindow_p>
>
> This looks OK.
>
> Now when I use getchildren in the panel, I get:
> getchildren
> [<C wxWindow instance at _1638ef0_wxWindow_p>,
> <C wxWindow instance at _163bef0_wxWindow_p>,
> <C wxWindow instance at _1638030_wxWindow_p>,
> <C wxWindow instance at _163ca40_wxWindow_p>,
> <C wxWindow instance at _1638c90_wxWindow_p>]
>
> These (3 buttons and 2 scrollwindows) are all identified as wxWindow.
The
> 1638c90 numbers match although.
>