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. Reparenting of QDialog leads to wrong Z-ordering? - simple example
QtWS25 Last Chance

Reparenting of QDialog leads to wrong Z-ordering? - simple example

Scheduled Pinned Locked Moved Unsolved General and Desktop
7 Posts 4 Posters 869 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.
  • SpellcrossS Offline
    SpellcrossS Offline
    Spellcross
    wrote on last edited by Spellcross
    #1

    Hi.
    This simple application results in dialog 'Foo' being drawn under its parent, the window is modal, active and eats user input, yet it is drawn under 'Bar'. Am i doing something wrong?
    Note that this only happens these two dialogs are first opened in child-parent relationship and then the relationship is reversed;
    Also this does not occur without the presence of the main parent dialog.

    Edit: I only tried this on Windows 10 with Qt 5.9.3

    #include <QApplication>
    #include <QDialog>
    int main(int argc, char *argv[])
    {
        QApplication a(argc, argv);
    
        QDialog mainDialog; mainDialog.setWindowTitle("mainDialog"); mainDialog.resize(500, 500);
        QDialog bar(&mainDialog); bar.setWindowTitle("bar"); bar.resize(400, 300);
        QDialog foo(&mainDialog); foo.setWindowTitle("foo"); foo.resize(300, 400);
    
        mainDialog.open();
    
        // parent one dialog to another and open them
        foo.open();
        bar.setParent(&foo, bar.windowFlags());
        bar.open();
    
        // close dialogs
        bar.reject();
        foo.reject();
    
        // re-order parent-child and open again
        bar.setParent(&mainDialog, bar.windowFlags());
        bar.open();
    
        foo.setParent(&bar, foo.windowFlags());
        foo.open();
    
        return a.exec();
    }
    
    JonBJ 1 Reply Last reply
    1
    • SpellcrossS Spellcross

      Hi.
      This simple application results in dialog 'Foo' being drawn under its parent, the window is modal, active and eats user input, yet it is drawn under 'Bar'. Am i doing something wrong?
      Note that this only happens these two dialogs are first opened in child-parent relationship and then the relationship is reversed;
      Also this does not occur without the presence of the main parent dialog.

      Edit: I only tried this on Windows 10 with Qt 5.9.3

      #include <QApplication>
      #include <QDialog>
      int main(int argc, char *argv[])
      {
          QApplication a(argc, argv);
      
          QDialog mainDialog; mainDialog.setWindowTitle("mainDialog"); mainDialog.resize(500, 500);
          QDialog bar(&mainDialog); bar.setWindowTitle("bar"); bar.resize(400, 300);
          QDialog foo(&mainDialog); foo.setWindowTitle("foo"); foo.resize(300, 400);
      
          mainDialog.open();
      
          // parent one dialog to another and open them
          foo.open();
          bar.setParent(&foo, bar.windowFlags());
          bar.open();
      
          // close dialogs
          bar.reject();
          foo.reject();
      
          // re-order parent-child and open again
          bar.setParent(&mainDialog, bar.windowFlags());
          bar.open();
      
          foo.setParent(&bar, foo.windowFlags());
          foo.open();
      
          return a.exec();
      }
      
      JonBJ Offline
      JonBJ Offline
      JonB
      wrote on last edited by JonB
      #2

      @Spellcross
      You may wish to state which platform(s) you have observed this behaviour on. Recently I had nasties with modeless dialogs, parenting & up-fronting: behaviour was different under Windows (to which I did not have access) vs Linux/GNOME. And GNOME has its own settings which affect this too.

      1 Reply Last reply
      2
      • SpellcrossS Offline
        SpellcrossS Offline
        Spellcross
        wrote on last edited by
        #3

        My colleague just found out that replacing line

         bar.setParent(&mainDialog, bar.windowFlags());
        

        with

        auto flags = bar.windowFlags();
        bar.setParent(&mainDialog);
        bar.setWindowFlags(flags);
        

        solves the issue.
        Seems like a bug in Qt

        mrjjM JonBJ 2 Replies Last reply
        1
        • SpellcrossS Spellcross

          My colleague just found out that replacing line

           bar.setParent(&mainDialog, bar.windowFlags());
          

          with

          auto flags = bar.windowFlags();
          bar.setParent(&mainDialog);
          bar.setWindowFlags(flags);
          

          solves the issue.
          Seems like a bug in Qt

          mrjjM Offline
          mrjjM Offline
          mrjj
          Lifetime Qt Champion
          wrote on last edited by
          #4

          @Spellcross
          On Windows or linux or ?

          1 Reply Last reply
          0
          • SpellcrossS Offline
            SpellcrossS Offline
            Spellcross
            wrote on last edited by
            #5

            Windows 10, I edited that into my original question

            1 Reply Last reply
            1
            • SpellcrossS Spellcross

              My colleague just found out that replacing line

               bar.setParent(&mainDialog, bar.windowFlags());
              

              with

              auto flags = bar.windowFlags();
              bar.setParent(&mainDialog);
              bar.setWindowFlags(flags);
              

              solves the issue.
              Seems like a bug in Qt

              JonBJ Offline
              JonBJ Offline
              JonB
              wrote on last edited by JonB
              #6

              @Spellcross
              Could you explain what the overload https://doc.qt.io/qt-5/qwidget.html#setParent-1 (QWidget::setParent(QWidget *parent, Qt::WindowFlags f)) is supposed to do anyway? The docs only say

              This function also takes widget flags, f as an argument.

              which is blindingly obvious, but doesn't tell me what it does with them? Bearing in mind it's a call which involves both the child & parent widgets, I don't even know which of the two it applies them to? You obviously consider it the same as going bar.setWindowFlags(), I wish the docs said so!

              D 1 Reply Last reply
              0
              • JonBJ JonB

                @Spellcross
                Could you explain what the overload https://doc.qt.io/qt-5/qwidget.html#setParent-1 (QWidget::setParent(QWidget *parent, Qt::WindowFlags f)) is supposed to do anyway? The docs only say

                This function also takes widget flags, f as an argument.

                which is blindingly obvious, but doesn't tell me what it does with them? Bearing in mind it's a call which involves both the child & parent widgets, I don't even know which of the two it applies them to? You obviously consider it the same as going bar.setWindowFlags(), I wish the docs said so!

                D Offline
                D Offline
                Dan Princ
                wrote on last edited by Dan Princ
                #7

                @JonB
                It would be very unexpected if it applied the flags to the parent. Anyway, the flags are applied to the child, which you can test by applying some specific flags that change the behavior... Btw the origin of the code in question comes from this comment.

                edit: filed a bug report: https://bugreports.qt.io/browse/QTBUG-77134

                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