There are some window styles that I want to be able to change on
live objects, such as wx.ALIGN_RIGHT on a wx.TextCtrl. However,
as advertised in the docs this appears to be one of those flags
that can't be set after the object has been created.
What would be the basic ingredients of a recipe to make this
work? Do I make an exact copy of the object followed by a
two-stage create where I set the pre object's properties to
match my old object's properties? Has someone already done
something like this and have war stories?
There are some window styles that I want to be able to change on live objects, such as wx.ALIGN_RIGHT on a wx.TextCtrl. However, as advertised in the docs this appears to be one of those flags that can't be set after the object has been created.
What would be the basic ingredients of a recipe to make this work? Do I make an exact copy of the object followed by a two-stage create where I set the pre object's properties to match my old object's properties? Has someone already done something like this and have war stories?
I think you'll be blazing new trails here. One thing to watch out for that comes immediatly to mind is that the tab order will change. Your new control will end up at the end of the order.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
Paul McNett wrote:
> There are some window styles that I want to be able to
> change on live objects, such as wx.ALIGN_RIGHT on a
> wx.TextCtrl. However, as advertised in the docs this
> appears to be one of those flags that can't be set after
> the object has been created.
>
> What would be the basic ingredients of a recipe to make
> this work? Do I make an exact copy of the object followed
> by a two-stage create where I set the pre object's
> properties to match my old object's properties? Has someone
> already done something like this and have war stories?
I think you'll be blazing new trails here. One thing to
watch out for that comes immediatly to mind is that the tab
order will change. Your new control will end up at the end
of the order.
Will self.GetParent().GetChildren() return the list of children
in instantiated order or is the order undefined? If undefined
is there a documented way to get the instantiated order? If I
can get that I can just do a cycle through the children in
correct order and call Lower() on them sequentially.
There are some window styles that I want to be able to
change on live objects, such as wx.ALIGN_RIGHT on a
wx.TextCtrl. However, as advertised in the docs this
appears to be one of those flags that can't be set after
the object has been created.
What would be the basic ingredients of a recipe to make
this work? Do I make an exact copy of the object followed
by a two-stage create where I set the pre object's
properties to match my old object's properties? Has someone
already done something like this and have war stories?
I think you'll be blazing new trails here. One thing to
watch out for that comes immediatly to mind is that the tab
order will change. Your new control will end up at the end
of the order.
Will self.GetParent().GetChildren() return the list of children in instantiated order or is the order undefined?
I think it is in order.
If undefined is there a documented way to get the instantiated order? If I can get that I can just do a cycle through the children in correct order and call Lower() on them sequentially.
That may mostly work, but at least part of the tab navigation is handled in wxWidgets itself and it probably uses the order in the window list. Give it a try though.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
The PythonCard resourceEditor has to do this, but it is PythonCard-specific and pretty messy so it would be nice to have a cleaner solution. You can use Raise() to fix the visual order of controls on Windows (maybe GTK too, but not on Mac OS X), but I don't know how to fix the tab-order yet. You used to be able to exploit a Hide/Show bug to change the visual and tab order, but that "feature" was fixed in 2.4.x.
ka
···
On Apr 20, 2004, at 4:36 PM, Paul McNett wrote:
There are some window styles that I want to be able to change on
live objects, such as wx.ALIGN_RIGHT on a wx.TextCtrl. However,
as advertised in the docs this appears to be one of those flags
that can't be set after the object has been created.
What would be the basic ingredients of a recipe to make this
work? Do I make an exact copy of the object followed by a
two-stage create where I set the pre object's properties to
match my old object's properties? Has someone already done
something like this and have war stories?
The PythonCard resourceEditor has to do this, but it is
PythonCard-specific and pretty messy so it would be nice to
have a cleaner solution. You can use Raise() to fix the
visual order of controls on Windows (maybe GTK too, but not
on Mac OS X), but I don't know how to fix the tab-order yet.
You used to be able to exploit a Hide/Show bug to change the
visual and tab order, but that "feature" was fixed in 2.4.x.
It sounds like we need a feature request for a
wxWindow.Get/SetTabOrder() which can be completely separate
from instantiation order and Raise()/Lower().
The PythonCard resourceEditor has to do this, but it is
PythonCard-specific and pretty messy so it would be nice to
have a cleaner solution. You can use Raise() to fix the
visual order of controls on Windows (maybe GTK too, but not
on Mac OS X), but I don't know how to fix the tab-order yet.
You used to be able to exploit a Hide/Show bug to change the
visual and tab order, but that "feature" was fixed in 2.4.x.
It sounds like we need a feature request for a wxWindow.Get/SetTabOrder() which can be completely separate from instantiation order and Raise()/Lower().
It's been requested before, and the core team basically agrees that it shoudl be done. What is needed is to figure out how to do it (for all platforms if it can't be done generically) and for somebody to spend the time on it.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
> It sounds like we need a feature request for a
> wxWindow.Get/SetTabOrder() which can be completely separate
> from instantiation order and Raise()/Lower().
It's been requested before, and the core team basically
agrees that it shoudl be done. What is needed is to figure
out how to do it (for all platforms if it can't be done
generically) and for somebody to spend the time on it.
Maybe we should see if Chandler can throw some $$$ at it <g>.
> What would be the basic ingredients of a recipe to make
> this work? Do I make an exact copy of the object followed
> by a two-stage create where I set the pre object's
> properties to match my old object's properties? Has someone
> already done something like this and have war stories?
The PythonCard resourceEditor has to do this, but it is
PythonCard-specific and pretty messy so it would be nice to
have a cleaner solution.
Well, check out what I whipped up here. I'm not sure how clean
this is, but it works for me. Note that this is a method in a base
mixin class that all my wx-based controls inherit. I have a set of
properties defined that correspond to wx getters and setters, and
I've also defined a getPropertyList() function that returns a list of
all such properties. Since these are specific to my framework, you
won't be able to run this code, but you'll be able to follow along:
def reCreate(self, child=None):
''' Recreate self.
'''
if child:
propDict = {}
propList = child.getPropertyList()
for prop in propList:
propDict[prop] = eval('child.%s' % prop)
style = child.GetWindowStyle()
classRef = child.__class__
name = child.Name
child.Destroy()
self.addObject(classRef, name, style=style)
for prop in propList:
try:
exec('self.%s.%s = %s' % (name, prop, propDict[prop]))
except:
pass
else:
self.Parent.reCreate(self)
It appears that the original C++ object never goes away, because after
I reinstantiate it, it reports the same address when I print it. But the new
object does take on any new window styles I gave the old one, which
was my goal.
Obviously, without the tab order problem fixed this won't be generally
useful though. I just thought it was interesting that it actually worked -
I expected all kinds of segfaults and whatnot <g>.