Qt
  1. Qt
  2. QTBUG-47042

QprogressDialog appears at creation with Qt5.5rc (other than in Qt5.4)

    Details

      Description

      In my application I create a QProgressDialog in the main window constructor for later usage.
      Then I initialize it:
      m_progressDlg->setMinimum(0);
      m_progressDlg->setMinimumDuration(2000);

      With Qt up to 5.4 the progress dialog dows not appear on startup.
      With Qt5.5rc it appears after 2 seconds. As a workaround I added the line
      m_progressDlg->reset();
      in the mai window constructor in order to get the same behavior as in former versions.

      May be related to QTBUG-46853

      1. QProgressDlg.rar
        1 kB
        Harald Prasser

        Issue Links

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

          Hide
          Shawn Rutledge added a comment -

          Please provide an example to reproduce the problem.

          Show
          Shawn Rutledge added a comment - Please provide an example to reproduce the problem.
          Hide
          Harald Prasser added a comment -

          Please compile the attached project "QProgressDlg.pro" with Qt 5.4 and 5.5rc on Windows 7 and you will get the two different described behaviors.

          Show
          Harald Prasser added a comment - Please compile the attached project "QProgressDlg.pro" with Qt 5.4 and 5.5rc on Windows 7 and you will get the two different described behaviors.
          Hide
          Harald Prasser added a comment -

          Still the same with the Qt 5.5.0 release.

          Show
          Harald Prasser added a comment - Still the same with the Qt 5.5.0 release.
          Hide
          Dayton Filipowich added a comment -

          I'm experiencing the same problem moving an application from Qt 5.4.1 to 5.5 on Windows 7 using MSVC 2013 x64. The reset workaround does appear working, though hide alone does not.

          Show
          Dayton Filipowich added a comment - I'm experiencing the same problem moving an application from Qt 5.4.1 to 5.5 on Windows 7 using MSVC 2013 x64. The reset workaround does appear working, though hide alone does not.
          Hide
          Lasconic added a comment - - edited

          Same problem on Windows 8.1 and Mac OSX 10.10 with Qt 5.5 release and current Qt 5.5.1 git.
          As stated it's probably a side effect of https://codereview.qt-project.org/72637

          More about it here https://musescore.org/en/node/71001

          Show
          Lasconic added a comment - - edited Same problem on Windows 8.1 and Mac OSX 10.10 with Qt 5.5 release and current Qt 5.5.1 git. As stated it's probably a side effect of https://codereview.qt-project.org/72637 More about it here https://musescore.org/en/node/71001
          Hide
          Chris Gilbert added a comment -

          Same as Dayton here - just upgraded from QT 5.4.1 to 5.5 on Win7 x64/MSVC 2013.

          dialog->hide() calls do not seem to have any effect, but calling dialog->reset() before hide() seems to restore the previous (QT 5.4.1) behavior.

          Show
          Chris Gilbert added a comment - Same as Dayton here - just upgraded from QT 5.4.1 to 5.5 on Win7 x64/MSVC 2013. dialog->hide() calls do not seem to have any effect, but calling dialog->reset() before hide() seems to restore the previous (QT 5.4.1) behavior.
          Hide
          Jonathan Liu added a comment -

          This issue also occurs with Qt 5.5.1, Windows 7 64-bit, MSVC 2013.

          Show
          Jonathan Liu added a comment - This issue also occurs with Qt 5.5.1, Windows 7 64-bit, MSVC 2013.
          Hide
          Robert Iakobashvili added a comment -

          This regression is even worse than described.

          hide() is working for a shown progress dialog with a delay.

          Please, increase priority of this clear regression.

          Show
          Robert Iakobashvili added a comment - This regression is even worse than described. hide() is working for a shown progress dialog with a delay. Please, increase priority of this clear regression.
          Hide
          Robert Iakobashvili added a comment -

          It's still reproducible in 5.5.1 on Windows and Android at least.

          Show
          Robert Iakobashvili added a comment - It's still reproducible in 5.5.1 on Windows and Android at least.
          Hide
          Florent Fortin added a comment -

          Confirm bug and proposed workaround on Windows 10 Qt 5.5.1

          Show
          Florent Fortin added a comment - Confirm bug and proposed workaround on Windows 10 Qt 5.5.1
          Hide
          Alex added a comment - - edited

          The bug is still present in Qt 5.6 Beta. And it's not even set to "Open" in 6 months?
          Looks like if you're not a paying Qt customer, the bugs you find will never be fixed. Time to start looking for alternatives to Qt.

          Show
          Alex added a comment - - edited The bug is still present in Qt 5.6 Beta. And it's not even set to "Open" in 6 months? Looks like if you're not a paying Qt customer, the bugs you find will never be fixed. Time to start looking for alternatives to Qt.
          Hide
          Marc Mutz added a comment -

          This is an intended change. It was communicated in the Qt 5.5 changelog (dist/changes-5.5.0):

           - QProgressDialog:
             * [QTBUG-17427][QTBUG-25316] The timer for estimating the duration of
               the progress dialog is now started in the constructor and in
               setValue(minimum()), as well as when calling setValue(0), as
               previously documented.
          
          Show
          Marc Mutz added a comment - This is an intended change. It was communicated in the Qt 5.5 changelog (dist/changes-5.5.0): - QProgressDialog: * [QTBUG-17427][QTBUG-25316] The timer for estimating the duration of the progress dialog is now started in the constructor and in setValue(minimum()), as well as when calling setValue(0), as previously documented.
          Hide
          Alex added a comment - - edited

          Who cares about timer. Why does it spontaneously decide to display itself, although neither `exec` nor `show` had ever been called?!

          Show
          Alex added a comment - - edited Who cares about timer. Why does it spontaneously decide to display itself, although neither `exec` nor `show` had ever been called?!
          Hide
          Marc Mutz added a comment -

          QProgressDialog is designed to show itself automatically, based on an internal estimate for the duration of the operation and the minimumDuration property. You never call show() or exec() on it manually. You're also not supposed to keep it around when it's not used. In 5.4, the only way to start the internal duration estimation was to call setValue(0). But we noticed that many people didn't call setValue(0), but just handed external progress information on to the progress dialog, and whether or not that progress information started at 0 or, say, 1, would determine whether the dialog would show itself at all, or not. This was thought to be a bit fragile, so we changed it so that the start time of the duration estimate was the dialog construction time unless setValue(0) (or, more correctly, setValue(minimum()) was called, leading to the dialog showing itself minimumDuration after its construction, even if it was constructed not for immediate use (which the dialog cannot distinguish from a really long-running operation).

          Show
          Marc Mutz added a comment - QProgressDialog is designed to show itself automatically, based on an internal estimate for the duration of the operation and the minimumDuration property. You never call show() or exec() on it manually. You're also not supposed to keep it around when it's not used. In 5.4, the only way to start the internal duration estimation was to call setValue(0). But we noticed that many people didn't call setValue(0), but just handed external progress information on to the progress dialog, and whether or not that progress information started at 0 or, say, 1, would determine whether the dialog would show itself at all, or not. This was thought to be a bit fragile, so we changed it so that the start time of the duration estimate was the dialog construction time unless setValue(0) (or, more correctly, setValue(minimum()) was called, leading to the dialog showing itself minimumDuration after its construction, even if it was constructed not for immediate use (which the dialog cannot distinguish from a really long-running operation).
          Hide
          Alex added a comment -

          Thanks, now I understand the idea! So basically, if one does not need such complicated functionality, one is better off designing their own primitive dialog with a progress bar instead of using QProgressDialog.

          Show
          Alex added a comment - Thanks, now I understand the idea! So basically, if one does not need such complicated functionality, one is better off designing their own primitive dialog with a progress bar instead of using QProgressDialog.

            People

            • Assignee:
              Marc Mutz
              Reporter:
              Harald Prasser
            • Votes:
              8 Vote for this issue
              Watchers:
              14 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Gerrit Reviews

                There are no open Gerrit changes