Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. [SOLVED] Giving parents to things that don't have an obvious parent candidate.
QtWS25 Last Chance

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

Scheduled Pinned Locked Moved General and Desktop
8 Posts 5 Posters 1.7k Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • M Offline
    M Offline
    Moschops
    wrote on last edited by
    #1

    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.

    1 Reply Last reply
    0
    • sierdzioS Offline
      sierdzioS Offline
      sierdzio
      Moderators
      wrote on last edited by
      #2

      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()));
      @

      (Z(:^

      1 Reply Last reply
      0
      • A Offline
        A Offline
        Asperamanca
        wrote on last edited by
        #3

        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.

        1 Reply Last reply
        0
        • M Offline
          M Offline
          Moschops
          wrote on last edited by
          #4

          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).

          1 Reply Last reply
          0
          • C Offline
            C Offline
            cincirin
            wrote on last edited by
            #5

            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

            1 Reply Last reply
            0
            • M Offline
              M Offline
              Moschops
              wrote on last edited by
              #6

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

              1 Reply Last reply
              0
              • N Offline
                N Offline
                NicuPopescu
                wrote on last edited by
                #7

                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?

                1 Reply Last reply
                0
                • N Offline
                  N Offline
                  NicuPopescu
                  wrote on last edited by
                  #8

                  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!

                  1 Reply Last reply
                  0

                  • Login

                  • Login or register to search.
                  • First post
                    Last post
                  0
                  • Categories
                  • Recent
                  • Tags
                  • Popular
                  • Users
                  • Groups
                  • Search
                  • Get Qt Extensions
                  • Unsolved