wx.Frame's parent limitations?

wxPython Users
1

Trying to play around with multi-level child windows/frames opening up based on other events, and primary issue could be to do with sort of porting code over to proper use of wxPython itself, but, just wondering if, when I make a call to another class instance, which is also sort of inheriting from the wx.Frame class, is there a limitation on what can be acting as/specified as the sort of requesting parent object?

Asking this since when, while testing, I instantiate one of my subclasses from the sort of top-level bit of UI, which I have stuck to implementing using a sort of instance of the LBC module’s instantiation of what seems to equate to the following - if run help() on an instance in python console:

help(dlg)
Help on Dialog in module lbc object:

class Dialog(wx._windows.Dialog)

Method resolution order:
Dialog
wx._windows.Dialog
wx._windows.TopLevelWindow
wx._core.Window
wx._core.EvtHandler
wx._core.Object

I would guess that while it’s a form of windows dialog, it is also matching somethig like wx.Window, and it seems Ok to then launch/be the parent for another class inheriting from wx.Frame, but, if I then, from that resulting piece of interface, try to launch yet another level of child window, there are all sorts of issue cropping up, including what seem to be mentions of invalid types for parent, etc., but, like said am not sure rest of my code port has gone perfectly as of yet, so just wondering if htere’s a limit to what can be used as sort of parent/launcher for something like this?

Could alternatively, hide the currently displayed child window/frame, and then also use original top-level object to then launch second child window or something, if necessary?

TIA (and, hope some of this makes some sense :))

Jacob Kruger
Blind Biker
Skype: BlindZA
‘…fate had broken his body, but not his spirit…’

2

Ok, and to make sure it wasn’t just my other ‘ported’ code, I started from scratch, and just slapped together three, small simple bits of code to handle a similar situation - start off with an LBC generated wx.Dialog window running as top-level window, which then launches another wx.Frame based class, which then, on it’s own also launches another wx.Frame based class instance, and all seemed to work fine, so will need to double check that am not missing out/messing up due to something else in my code, etc.

Stay well

Jacob Kruger
Blind Biker
Skype: BlindZA
‘…fate had broken his body, but not his spirit…’

···

----- Original Message -----

From:
Jacob Kruger

To: wxpython-users@googlegroups.com

Sent: Friday, January 03, 2014 03:54 PM

Subject: [wxPython-users] wx.Frame’s parent limitations?

Trying to play around with multi-level child windows/frames opening up based on other events, and primary issue could be to do with sort of porting code over to proper use of wxPython itself, but, just wondering if, when I make a call to another class instance, which is also sort of inheriting from the wx.Frame class, is there a limitation on what can be acting as/specified as the sort of requesting parent object?

Asking this since when, while testing, I instantiate one of my subclasses from the sort of top-level bit of UI, which I have stuck to implementing using a sort of instance of the LBC module’s instantiation of what seems to equate to the following - if run help() on an instance in python console:

help(dlg)
Help on Dialog in module lbc object:

class Dialog(wx._windows.Dialog)

Method resolution order:
Dialog
wx._windows.Dialog
wx._windows.TopLevelWindow
wx._core.Window
wx._core.EvtHandler
wx._core.Object

I would guess that while it’s a form of windows dialog, it is also matching somethig like wx.Window, and it seems Ok to then launch/be the parent for another class inheriting from wx.Frame, but, if I then, from that resulting piece of interface, try to launch yet another level of child window, there are all sorts of issue cropping up, including what seem to be mentions of invalid types for parent, etc., but, like said am not sure rest of my code port has gone perfectly as of yet, so just wondering if htere’s a limit to what can be used as sort of parent/launcher for something like this?

Could alternatively, hide the currently displayed child window/frame, and then also use original top-level object to then launch second child window or something, if necessary?

TIA (and, hope some of this makes some sense :))

Jacob Kruger
Blind Biker
Skype: BlindZA
‘…fate had broken his body, but not his spirit…’

–
You received this message because you are subscribed to the Google Groups “wxPython-users” group.
To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

3

Jacob Kruger wrote:

Trying to play around with multi-level child windows/frames opening up
based on other events, and primary issue could be to do with sort of
porting code over to proper use of wxPython itself, but, just wondering
if, when I make a call to another class instance, which is also sort of
inheriting from the wx.Frame class, is there a limitation on what can be
acting as/specified as the sort of requesting parent object?

There are 2 broad classifications of window classes in wx, top-level windows and everything else. Top-level windows are represented by the wx.Frame and wx.Dialog classes, and any classes derived directly or indirectly from them, and are "top level" because they typically have window decorrations provided by the platform, can be manipulated by the user via platform provided controls, and usually appear as if their parent is the platform's desktop or root window.

Top-level windows do not need to have a parent, but they can have one if you want them to. (On some platforms dialogs must have a parent and if that is the case then wx will use the first one found in a top-level windows list that it maintains internally.) If a top level window does have a parent then there are a few new features that are activated, such as the child being destroyed automatically when the parent is destroyed, and on some platforms child frames may be partially glued to the parent and move when the parent is moved, etc.

Asking this since when, while testing, I instantiate one of my
subclasses from the sort of top-level bit of UI, which I have stuck to
implementing using a sort of instance of the LBC module's instantiation
of what seems to equate to the following - if run help() on an instance
in python console:
>>> help(dlg)
Help on Dialog in module lbc object:
class Dialog(wx._windows.Dialog)
> Method resolution order:
> Dialog
> wx._windows.Dialog
> wx._windows.TopLevelWindow
> wx._core.Window
> wx._core.EvtHandler
> wx._core.Object

This is showing the class hierarchy of the lbc.Dialog class, meaning that it inherits methods and attributes from the classes above it in the hierarchy. In GUI applications there is another hierarchy that is sometimes mentions, the containment hierarchy. For example, you may have a Button whose parent is a Panel, and its parent is a Frame. In other words, the Frame contains the Panel, which in turn contains the Button. This is important not only for things like visibility, positioning, ownership of the objects, but also for event processing. Command events will search up the containment hierarchy when looking for a matching event handler to call.

···

--
Robin Dunn
Software Craftsman

4

Thanks.

This all makes sense, and was pretty much what had sort of thought/expected, and the whole concept of containers, etc. make sense, in terms of OO, inheritance, etc.

Will also just admit/say that the cause of my issue was that - think at least partly since self is pretty much appearing as first parameter in all internal methods/functions of class - when I called super() to reroute __init__ call to class/type the class was based on, I had switched parameters around, so had typed in something like following line of code - was trying to retype code to get a 'feel' for it, etc., instead of just copy/paste:
super(self, className).__init__(*args, **kwargs)

And, obviously, those first two parameters should have been swapped around - super(className, self), and it then worked fine, so it was my own mistake - sometimes helps to take a bit of a break from learning to use new bits of technology, instead of just trying to work through all sorts of things, in one go...<smile>

Stay well

Jacob Kruger
Blind Biker
Skype: BlindZA
'...fate had broken his body, but not his spirit...'

···

----- Original Message ----- From: "Robin Dunn" <robin@alldunn.com>
To: <wxpython-users@googlegroups.com>
Sent: Saturday, January 04, 2014 10:34 PM
Subject: Re: [wxPython-users] wx.Frame's parent limitations?

Jacob Kruger wrote:

Trying to play around with multi-level child windows/frames opening up
based on other events, and primary issue could be to do with sort of
porting code over to proper use of wxPython itself, but, just wondering
if, when I make a call to another class instance, which is also sort of
inheriting from the wx.Frame class, is there a limitation on what can be
acting as/specified as the sort of requesting parent object?

There are 2 broad classifications of window classes in wx, top-level windows and everything else. Top-level windows are represented by the wx.Frame and wx.Dialog classes, and any classes derived directly or indirectly from them, and are "top level" because they typically have window decorrations provided by the platform, can be manipulated by the user via platform provided controls, and usually appear as if their parent is the platform's desktop or root window.

Top-level windows do not need to have a parent, but they can have one if you want them to. (On some platforms dialogs must have a parent and if that is the case then wx will use the first one found in a top-level windows list that it maintains internally.) If a top level window does have a parent then there are a few new features that are activated, such as the child being destroyed automatically when the parent is destroyed, and on some platforms child frames may be partially glued to the parent and move when the parent is moved, etc.

Asking this since when, while testing, I instantiate one of my
subclasses from the sort of top-level bit of UI, which I have stuck to
implementing using a sort of instance of the LBC module's instantiation
of what seems to equate to the following - if run help() on an instance
in python console:
>>> help(dlg)
Help on Dialog in module lbc object:
class Dialog(wx._windows.Dialog)
> Method resolution order:
> Dialog
> wx._windows.Dialog
> wx._windows.TopLevelWindow
> wx._core.Window
> wx._core.EvtHandler
> wx._core.Object

This is showing the class hierarchy of the lbc.Dialog class, meaning that it inherits methods and attributes from the classes above it in the hierarchy. In GUI applications there is another hierarchy that is sometimes mentions, the containment hierarchy. For example, you may have a Button whose parent is a Panel, and its parent is a Frame. In other words, the Frame contains the Panel, which in turn contains the Button. This is important not only for things like visibility, positioning, ownership of the objects, but also for event processing. Command events will search up the containment hierarchy when looking for a matching event handler to call.

--
Robin Dunn
Software Craftsman
http://wxPython.org

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.