From: <bra...@om...> - 2005-04-09 21:57:48
|
For my part, the main motivation for this has gone away. In another thread, "childWindow.Raise() works on Windows, not on Mac", Liam kindly explained the following: "See, what happens is that when a child window is created, the method that [called model.childWindow] finishes before the child window's on_initialise gets called." Assuming this is true, and so far it seems to be, it's safe for the calling parent to go ahead and assign additional attributes to the child window, as long as it's done in the same method that created the child window. Another technique I've been using to get around this problem is for the child window's on_initialize to interrogate the parent for additional data using self.getParent(). Looking over the tutorial on how to create a child window, there is a reference to using getParent(), but it still might be worthwhile to include this in an FAQ...something like this: ---------- Q: "I want to pass parameters to model.childWindow when I create a child window. How do I accomplish that?" A: Instead of passing parameters to model.childWindow, you can have the child window's on_initialize method request additional data from the parent using self.getParent().whatever.you.want. ---------- I'm not sure if the other approach is worth mentioning in an FAQ; it seems counterintuitive to expect that on_initialize is going to fire at some later time... Kevin Altis wrote on 03/30/2005 12:38:14 AM: > I'm still not sure on the best way to deal with the > desire to pass args to a child window, but I would > like to propose one possible solution as well as > clarify some of the issues surrounding child windows. > > As a test, I duplicated the minimal source and > resource and added the following test code. > > def on_initialize(self, event): > print "child initialize" > > def postInit(self, a, b): > print "postInit" > print a, b > > I modified the minimal sample by adding a button and > the following code to create the child window as well > as call an additional method once the other events > have fired by using wx.CallAfter. > > def on_btn_mouseClick(self, event): > print "mouseClick" > self.myChild = model.childWindow(self, > minchild.Minimal) > wx.CallAfter(self.myChild.postInit, "hello", > 2) > > This appears to work as expected, but may not be what > Liam and others are looking for. I'll let them reply > with their current solutions and what they want. > > model.childWindow is just a convenience function. > > PythonCard does not use __init__ in user code since > that can be a dangerous place for user code as you > might try and access or modify controls or methods > that have not finished initializing in > wxWidgets/wxPython. Thus the initialize event has been > the way of doing initialization and the "event" is > supposed to fire after all other wx initialization is > done and the underlying control or window has > "settled", so it is safe to do whatever manipulations > you need. Furthermore, initialize is an event in an > attempt to be more consistent, but that means it only > has one argument, "event", just like all the other > events. > > In the case of the childWindow function, the > initialize event that fires is disconnected from the > function call. Even if *args and **kwargs arguments > were used in the childWindow function I couldn't pass > them to initialize in a clean way. Making a separate > method call that you have control over when it happens > in relation to other events seems like the simplest > solution. Given that this might be a common need, > maybe we should have a PythonCard alias for > wx.CallAfter? > > Additional thoughts? I can dig into this issue more > next week. > > ka > > > > __________________________________ > Do you Yahoo!? > Read only the mail you want - Yahoo! Mail SpamGuard. > http://promotions.yahoo.com/new_mail > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Pythoncard-users mailing list > Pyt...@li... > https://lists.sourceforge.net/lists/listinfo/pythoncard-users |