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. "this->setEnabled(false);" not always disabling window

"this->setEnabled(false);" not always disabling window

Scheduled Pinned Locked Moved General and Desktop
13 Posts 6 Posters 11.6k 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.
  • S Offline
    S Offline
    szh1
    wrote on last edited by
    #1

    I am working on a batch image format converter. I have some code:

    @
    // disable the window
    this->setEnabled(false);
    if (outputDir != QString::null)
    {
    // iterate through the items in imageList
    for (int row = 0; row < this->ui->imageList->count(); row++)
    {
    // create a QListWidgetItem from the row
    QListWidgetItem *item = this->ui->imageList->item(row);

            // check to make sure the file exists
            if (!QFile&#40;item->text(&#41;&#41;.exists(&#41;)
            {
                QMessageBox::warning(this, "Error", "Cannot find file '" + item->text() + "'. Check to make sure the file exists.");
                continue;
            }
    
            // convert the image with the selected settings
            if (ImageConverter(NULL).Convert(item->text(), outputDir, QString(this->ui->outputFormatComboBox->currentText()), this->ui->qualitySpinBox->value(), this->ui->overwriteCheckBox->checkState() == Qt::Checked) && this->ui->deleteOriginalCheckBox->checkState() == Qt::Checked)
            {
                // if the image was converter and the user selected deleteOriginalCheckBox, delete the original file
                QFile::remove(item->text());
            }
        }
    }
    else
    {
        // iterate through the items in imageList
        for (int row = 0; row < this->ui->imageList->count(); row++)
        {
            // create a QListWidgetItem from the row
            QListWidgetItem *item = this->ui->imageList->item(row);
    
            // check to make sure the file exists
            if (!QFile&#40;item->text(&#41;&#41;.exists(&#41;)
            {
                QMessageBox::warning(this, "Error", "Cannot find file '" + item->text() + "'. Check to make sure the file exists.");
                continue;
            }
    
            // convert the image with the selected settings
            if (ImageConverter(NULL).Convert(item->text(), QString(this->ui->outputFormatComboBox->currentText()), this->ui->qualitySpinBox->value(), this->ui->overwriteCheckBox->checkState() == Qt::Checked) && this->ui->deleteOriginalCheckBox->checkState() == Qt::Checked)
            {
                // if the image was converter and the user selected deleteOriginalCheckBox, delete the original file
                QFile::remove(item->text());
            }
        }
    }
    // enable the window
    this->setEnabled(true);
    

    }
    @

    to disable the window while the images are being converted. Strangely, the window only appears to be disabled in instances when I display a "QMessageBox" error message.

    1 Reply Last reply
    0
    • L Offline
      L Offline
      luca
      wrote on last edited by
      #2

      try with:

      @
      QApplication::processEvents();
      @

      after the:

      @
      this->setEnabled(false);
      @

      1 Reply Last reply
      0
      • S Offline
        S Offline
        szh1
        wrote on last edited by
        #3

        Thank you! It works perfectly.

        1 Reply Last reply
        0
        • A Offline
          A Offline
          alexander
          wrote on last edited by
          #4

          The best way is usage another thread for converting (outside gui thread).

          1 Reply Last reply
          0
          • M Offline
            M Offline
            MTK358
            wrote on last edited by
            #5

            You don't have to write "this->" to access class members in C++.

            1 Reply Last reply
            0
            • S Offline
              S Offline
              szh1
              wrote on last edited by
              #6

              MTK358:
              I know, but in C# I learned that it is good practice to do so. I think it is because it makes it clearer if there are other functions with the same name. Is it different in C++?

              1 Reply Last reply
              0
              • M Offline
                M Offline
                MTK358
                wrote on last edited by
                #7

                [quote author="szh1" date="1286314042"]MTK358:
                I know, but in C# I learned that it is good practice to do so. I think it is because it makes it clearer if there are other functions with the same name. Is it different in C++?[/quote]

                Never heard of such a thing (except for languages like Ruby and Python, which require you to do so).

                1 Reply Last reply
                0
                • T Offline
                  T Offline
                  tobias.hunger
                  wrote on last edited by
                  #8

                  szh1: Yes, using this-> makes it clear you are referring to members, but a good IDE does the same thing using syntax highlighting. So why waste time on the extra typing?

                  MTK358: It is not required, but it makes clear that you want to access a member and not e.g. something global. It is perfect valid C++ and can even be necessary to do to disambiguate between things.

                  1 Reply Last reply
                  0
                  • V Offline
                    V Offline
                    VC15
                    wrote on last edited by
                    #9

                    As far as I know if there is a member function and a global function with the same signature and it is called from within a class the compiler always choose the member.

                    1 Reply Last reply
                    0
                    • T Offline
                      T Offline
                      tobias.hunger
                      wrote on last edited by
                      #10

                      VC15: Yes, of course the compiler uses the scoping rules to resolve names. There are places where this->something and something can be different though. Try this:

                      @
                      class A {
                      public:
                      A() : something(5) {}

                      void method()
                      {
                      int something = 7;
                      qDebug() << something << this->something;
                      }

                      private:
                      int something;
                      };
                      @

                      1 Reply Last reply
                      0
                      • V Offline
                        V Offline
                        VC15
                        wrote on last edited by
                        #11

                        I try to avoid such ambiguity. I realize that this is just an example. But in a real project to have a member and a local variable with the same name is not a good practice.

                        Of course, explicit pointing of scope increases readability. When you use this-> or type fully specified class name with the full chain of namespaces it belongs to you won't be surprised during runtime. But this also bloats your code and sometimes decreases readability. So as usual we have to find some compromise.

                        1 Reply Last reply
                        0
                        • T Offline
                          T Offline
                          tobias.hunger
                          wrote on last edited by
                          #12

                          VC15: I fully agree with all you said.

                          I do prefer the best practice to avoid variables shadowing others to the best practice of putting "this->" before all member accesses, but both are valid ways to avoid confusing the programmer (not the compiler;-).

                          1 Reply Last reply
                          0
                          • S Offline
                            S Offline
                            szh1
                            wrote on last edited by
                            #13

                            So I guess it is just preference.

                            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