Phil Thompson <[EMAIL PROTECTED]> wrote: >> The problem is that the idiomatic way of using modal dialogs in C++ is to >> create local variables, which gets destroyed when their scope finishes >> (when >> the function exits). Moreover, the dialogs have to be children of whatever >> widgets they are modal over (e.g. the main window). >> >> This has no direct translations in PyQt. If you do: >> >> def slotWhatever(self): >> dlg = MyModalDialog(self) >> if dlg.exec_loop() == QDialog.Accepted: >> return dlg.data() >> return None >> >> you are leaking "dlg" because its lifetime is bound to its parent. The >> current common workaround is something like: >> >> def slotWhatever(self): >> dlg = MyModalDialog(self) >> try: >> if dlg.exec_loop() == QDialog.Accepted: >> return dlg.data() >> return None >> finally: >> dlg.deleteLater() >> >> which is ugly and error-prone (you have to remember to do it). >> >> James proposed this solution: >> >> def slotWhatever(self): >> dlg = MyModalDialog(self) >> sip.transfer(dlg, 0) >> if dlg.exec_loop() == QDialog.Accepted: >> return dlg.data() >> return None >> >> and then proposed to hardcode the transfer() call within the %MethodCode >> for >> QDialog.exec_loop. I'll remember you that exec_loop is called only for >> modal >> dialogs, while for modeless dialogs show() is called. > > I'm uncomfortable with this for two reasons... > > 1. It's inconsistent behaviour. As there are things you need to be aware > of when using PyQt (particularly with regard to ownership) I think it's > important to have consistency in those things. > > 2. It creates the strong possibility of a seg fault for those (existing) > applications that don't follow the common idiom.
Yeah, I understand. Better ideas? > What's wrong with just passing WDestructiveClose in the dialog's ctor call > to QDialog.__init__()? If you do so, you are not able to access the dialog properties after the dialog is closed by the user, which is a very common scenario (see my example above). > I've no problem with adding this issue to the > documention. Yes, this should really be documented, no matter what the outcome of this discussion is. -- Giovanni Bajo _______________________________________________ PyKDE mailing list PyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde