“this->setEnabled(false);” not always disabling window
I am working on a batch image format converter. I have some code:
- // disable the window
- this->setEnabled(false);
- {
- // iterate through the items in imageList
- for (int row = 0; row < this->ui->imageList->count(); row++)
- {
- // create a QListWidgetItem from the row
- // check to make sure the file exists
- {
- 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 the image was converter and the user selected deleteOriginalCheckBox, delete the original file
- }
- }
- }
- else
- {
- // iterate through the items in imageList
- for (int row = 0; row < this->ui->imageList->count(); row++)
- {
- // create a QListWidgetItem from the row
- // check to make sure the file exists
- {
- 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 the image was converter and the user selected deleteOriginalCheckBox, delete the original file
- }
- }
- }
- // 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.
12 replies
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.
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;
- };
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.
You must log in to post a reply. Not a member yet? Register here!