Process Editing Frame
Splitter
List Ctrl (DND source)
List Ctrl (DND target)
This rather large app (due yesterday ) is supposed to use the List ctrls
for drag-and-drop editing of a list of instantiated objects. This works
fine when just the Process Editing Frame is used. Unfortunately, when I
launch the Dialog with parent = NULL, I lose the entire event system (as if
the dialog's event loop is being suspended along with the app's). Note: As
I'm shutting down, when I kill the modal dialog, all the events get
processed for the frame. The modality of the dialog is fairly critical to
the application's functioning (I'd have to do a ridiculous amount of
re-writing to eliminate it). The non-modality of the Frame isn't quite as
critical, but without it the app becomes somewhat more cumbersome.
Why I'm using NULL:
If I use the buttons themselves as parents, there's weird interactions
where duplicate IDs in the child windows are de-registered in the
EVT_tables.
The buttons are arbitrarily nested inside the property windows, depending
on what the control looks like. This level of abstraction is really
necessary, as there's dozens of data types being managed here.
I can't get the "nearest managed window" because the managed windows are
indistinguishable from the intermediate windows using GetParent etceteras.
The best solution I can see is to find some way to get the nearest managed
window parent (dialog, or frame) and use that as the parent (which, I think,
should solve everything). Next best would be some way of "un-sticking" the
event loop for the frame. Not really exciting, but I suppose doable, would
be to switch to the micro-threading version of wxPython, which doesn't use
the wxPython modal mechanism (but has it's own quirks, and would require
rewriting my multi-threading code ).
If anyone has any suggestions, I'd love to hear them. Thanks,
Mike
Well, figured out something (eliminating modal stuff and using event
propagation to find the managed parents):
Any control wanting to edit an object's value does:
def EditItem( self, index ):
'''Handle "activation" of a particular node within the set'''
from worldbuilder.objects import vrmlattributes
item = vrmlattributes.VRMLAttributeObject( self.value[index] )
self.GetEventHandler().AddPendingEvent(
events.EditMeEvent(
( item, self.OnEditComplete),
)
)
def OnEditComplete( self, returnValue, object ):
"""Handle interpretation of a completed editing phase"""
object = object.node
if returnValue == wxID_OK:
if object in self.value:
self.ConfigureItem( self.value.index(object), object )
self.Refresh()
And all managed windows then catch those events, and call event.Do( self ),
which makes the event go through the process of actually building the
window, checking whether the editor is Modal or Non-modal, passing in the
callback (or calling DoModal and then calling the callback itself). I still
had to eliminate the Dialogs from the system , but oh well, it runs, and
I put in checks to eliminate the modal assumptions.
It's not pretty, but it does _seem_ to work...
Sorry to bother everyone,
Mike
The best solution I can see is to find some way to get the nearest managed
window parent (dialog, or frame) and use that as the parent (which, I think,
should solve everything). Next best would be some way of "un-sticking" the
event loop for the frame. Not really exciting, but I suppose doable, would
be to switch to the micro-threading version of wxPython, which doesn't use
the wxPython modal mechanism (but has it's own quirks, and would require
rewriting my multi-threading code ).
If anyone has any suggestions, I'd love to hear them. Thanks,
Mike
...
Well, figured out something (eliminating modal stuff and using event
propagation to find the managed parents):
Any control wanting to edit an object's value does:
def EditItem( self, index ):
'''Handle "activation" of a particular node within the set'''
from worldbuilder.objects import vrmlattributes
item = vrmlattributes.VRMLAttributeObject( self.value[index] )
self.GetEventHandler().AddPendingEvent(
events.EditMeEvent(
( item, self.OnEditComplete),
)
)
def OnEditComplete( self, returnValue, object ):
"""Handle interpretation of a completed editing phase"""
object = object.node
if returnValue == wxID_OK:
if object in self.value:
self.ConfigureItem( self.value.index(object), object )
self.Refresh()
And all managed windows then catch those events, and call event.Do( self ),
which makes the event go through the process of actually building the
window, checking whether the editor is Modal or Non-modal, passing in the
callback (or calling DoModal and then calling the callback itself). I still
had to eliminate the Dialogs from the system , but oh well, it runs, and
I put in checks to eliminate the modal assumptions.
It's not pretty, but it does _seem_ to work...
Sorry to bother everyone,
Mike
From: wxpython-users-admin@lists.wxwindows.org
[mailto:wxpython-users-admin@lists.wxwindows.org]On Behalf Of Mike C.
Fletcher
Sent: May 16, 2001 01:58
To: wxPython Users (E-mail)
Subject: [wxPython] Event "heat death" effect? Any suggestions?
...
The best solution I can see is to find some way to get the nearest managed
window parent (dialog, or frame) and use that as the parent (which, I think,
should solve everything). Next best would be some way of "un-sticking" the
event loop for the frame. Not really exciting, but I suppose doable, would
be to switch to the micro-threading version of wxPython, which doesn't use
the wxPython modal mechanism (but has it's own quirks, and would require
rewriting my multi-threading code ).
If anyone has any suggestions, I'd love to hear them. Thanks,
Why not:
root = self
while 1:
tmp = root.GetParent()
if not tmp:
break
root = tmp
That just gets the root frame (which I can get from the Application (and I
did use that in one experiment, instead of NULL)). The same "heat death"
effect occurs when the parent used is beyond a modal dialog. Apparently the
wxPython modal dialog (which starts a new event loop for the modal dialog,
separate than that for the application) just doesn't want to play nice with
the events if they get passed to windows not explicitly under it's loop.
Thanks,
Mike
[mailto:wxpython-users-admin@lists.wxwindows.org]On Behalf Of Niki
Spahiev
···
-----Original Message-----
From: wxpython-users-admin@lists.wxwindows.org
Sent: May 16, 2001 10:49
To: Mike C. Fletcher
Subject: Re[2]: [wxPython] Event "heat death" effect? Any suggestions?
...
If anyone has any suggestions, I'd love to hear them. Thanks,
Why not:
root = self
while 1:
tmp = root.GetParent()
if not tmp:
break
root = tmp
...
) is supposed to use the List ctrls
, but oh well, it runs, and