Hi Koen, Thanks for the detailed explanation. I suppose I could rewrite my code to do things this way. It wouldn't be so bad for a couple of the dialog boxes, but I also was relying quite heavily on WMessageBox::show() so replacing all of those calls with non-blocking dialogs is going to be pretty painful. I am tempted to just ditch Qt until this issue is fixed. I mainly was using it for QFileSystemWatcher, but it's beginning to not be worth all the trouble.
-- Dan On Feb 8, 2010, at 10:06 AM, Koen Deforche wrote: > Hey Daniel, > > 2010/2/8 Ginsburg, Daniel <daniel.ginsb...@childrens.harvard.edu>: >> Do you mean to make the dialog non-modal? Or is there some other way to >> execute a modal dialog other than using exec()? I would not be able to make >> the dialog non-modal, that would not work for my application. If there is >> some other way to execute a modal dialog, could you tell me how to do it? > > Yes, you can execute a modal dialog without using exec(). > >> From http://www.webtoolkit.eu/wt/doc/reference/html/classWt_1_1WDialog.html: > > WDialog can be used as any other widget. In this case, the WDialog is > simply instantiated as another widget. The dialog may be closed by > calling accept(), reject() or done() (or connecting a signal to one of > these methods). This will hide the dialog and emit the finished() > signal, which you then can listen for to process the dialog result and > delete the dialog. Unlike other widgets, a dialog does not need to be > added to a parent widget, but is hidden by default. You must use the > method show() or setHidden(true) to show the dialog. > > So, instead of exec(), use show(), and listen to the finished() signal > instead of inspecting the result of exec(). This does mean that you > cannot build your dialog on the stack, and for a complex dialog you > will want to specialize WDialog to keep track of form fields. See for > example FileEditDialog in TreeViewDragDrop.C (treeview-dragdrop > example). > > In the mean-time we have been brainstorming about solutions to the > original problem. One solution would be to not spawn a dedicated > thread for each session, but instead make it so that a session is > always handled by the same thread (by using a hash function on the > session ID which hashes it on a thread from a thread pool). However, > we currently do not see how this can be done in conjunction with our > current asio design for wthttpd. > > Regards, > koen > > ------------------------------------------------------------------------------ > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > _______________________________________________ > witty-interest mailing list > witty-interest@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/witty-interest Daniel Ginsburg / email: daniel.ginsb...@childrens.harvard.edu Principal Software Architect Fetal-Neonatal Neuroimaging and Development Science Center Children's Hospital Boston 300 Longwood Avenue Boston, MA 02115 Phone: 857-218-5140 ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ witty-interest mailing list witty-interest@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/witty-interest
