[SOLVED] Giving parents to things that don't have an obvious parent candidate.



  • I have some code that requires input from the user; in this particular case, a directory. The obvious way to do this is to use @QFileDialog::getExistingDirectory@, and this works well. However, the object calling this static function is not a QWidget, so it cannot be set as the parent, so at the moment I just let the parent pointer be NULL.

    It's not a major issue, but it does mean that if the program is closed while the dialog is open, a segFault happens (which is expected, I think, fro the documentation). It's not great, though. How do people deal with this? Is there a commonly used QT convention for handling this sort of thing? I could imagine going through some mechanism to get a pointer to a QWidget somewhere and use that as the parent (ideally a QWidget of relevance), or I could create a QWidget right there and use that, but these are both inelegant kludges.


  • Moderators

    Some people make their main windows into Singletons. Then it's rather easy, although it comes with a price. Or you can pass a QWidget pointer to your non-QObject class. Or, perhaps the cleanest in this situation, just connect to qApp's aboutToQuit() signal:
    @
    QCoreApplication *app = QCoreApplication::instance();
    QDialog *blah = ...
    QObject::connect(app, SIGNAL(aboutToQuit()), blah, SLOT(deleteLater()));
    @



  • I can think of few cases where a file dialog would pop open without prior, explicit input from the user (e.g. a "Select folder..." button).

    It would therefore be logical to use the widget from which is user input originated.



  • bq. It would therefore be logical to use the widget from which is user input originated.

    It would, and normally that's what I'd do. In this case, the user reaches this point through an action (in a menu), rather than pushing a button, so the relevant QWidget is the QMainWindow. I'd have to pass a pointer to the QMainWindow around somewhere and have it "meet up" with the code triggered by the action somewhere else, which just seems awfully clumsy (or, as sierdzio suggests, make it reachable from everywhere).



  • See "QApplication::activeWindow()":http://qt-project.org/doc/qt-5.0/qtwidgets/qapplication.html#activeWindow

    bq. Returns the application top-level window that has the keyboard input focus



  • Aha. That looks just the ticket, thank you very much.



  • a Q: if QFileDialog::getExistingDirectory(NULL,...) creates a modal file dialog how can you close the program before it does close and return to the event loop?



  • bq. It’s not a major issue, but it does mean that if the program is closed while the dialog is open, a segFault happens (which is expected, I think, fro the documentation)

    where in the doc?

    bq. Any QWidget that has no parent will become a window, and will on most platforms be listed in the desktop's task bar.

    for these ones if you quit the app's process they will be destroyed too!


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.