enabling/disabling a QMainWindow?

[TheRonin]

I'm working with a QMainWindow and would like every widget within it to become disabled. Since we're talking about practically the entire GUI, i'm looking for a way to disable it all in one sweep instead of going through all the children one-by-one (there are a bunch of child widgets!).

Since QMainWindow is a subclass of QWidget, i was hoping that the setEnabled(bool) and setDisabled(bool) slots would work. Unfortunately, they doesn't seem to.

Is there a way of doing this simply or am i trying to squeeze blood from a stone?

thanks!

[wysota]

The methods you mentioned should work. Could you further explain what does "not work" mean?

[TheRonin]

Sure thing wysota!

My class is called Gui and inherits QMainWindow. The following code works in the sense that the close event is ignored and the signal is emited correctly. However, the main window does not become disabled.



void Gui::closeEvent(QCloseEvent *event)
{
event->ignore();
this->setEnabled(false);
emit someSignalThatDoesStuff();
}


after calling the setEnabled(false) or setDisabled(true) slots i can still manipulate the gui.

[wysota]

Is this a complete method code? Because if it is, how will you close your window?

Anyway, this code works correctly for me:

#include <QApplication>
#include <QWidget>
#include <QCloseEvent>
#include <QLayout>
#include <QPushButton>
#include <QMainWindow>

class Wgt : public QMainWindow {
public:
Wgt():QMainWindow(){}
protected:
void closeEvent(QCloseEvent *e){
if(width()<500){
e->ignore();
setDisabled(true);
}
return;
}
};

int main(int a, char **b){
QApplication app(a,b);
Wgt mw;
QWidget *w = new QWidget;
QHBoxLayout *l = new QHBoxLayout(w);
l->addWidget(new QPushButton());
l->addWidget(new QPushButton());
mw.setCentralWidget(w);
mw.show();
return app.exec();
}

[TheRonin]

wow..just...wow...it is so weird, the only discernible difference is that ive used Designer to create my gui. But other than that, its basically the same...and yet, using setDisabled(true) does nothing. The signal i emit leads to a slot that does some things before issuing a qApp->quit().

Can the problem have to do with the fact that i'm using the oh-so-sexy CDE-style (i'm running in unix)? I'm inclined to doubt it though since the interface isn't disabled at all. it would be conceivable that the interface would be visually enabled but functionally disabled..but this does not seem to be the case. I've had this problem before in other projects (running in windows) where i've wanted to disable entire windows and have, until now, just assumed that it wasn't possible and that i had to manually disable every child widget.

[wysota]

I don't think this is the case but you may just try with another widget style and see for yourself.

[fullmetalcoder]

The signal i emit leads to a slot that does some things before issuing a qApp->quit().
Have you tried commenting out this signal emission? BTW If you issue a "qApp->quit()" your app should actually get closed and not disabled or am I missing something?:confused:

[TheRonin]

hey guys, thanks for your help thus far...i hope there's a solution right around the corner! :) :crying:


I don't think this is the case but you may just try with another widget style and see for yourself.

I get the desired behavior if instead of disabling the QMainWindow i disable the root widget (a QWidget called centralwidget by the designer). I would of course like to not need to do that sort of work-around instead of working with the mainwindow directly. Had you been able to reproduce my problem i would have been tempted to call it a bug of sorts but since i seem to be the only one affected, maybe it's due to a problem with my Qt installation?? :confused:


Have you tried commenting out this signal emission? BTW If you issue a "qApp->quit()" your app should actually get closed and not disabled or am I missing something?:confused:

I just tried skipping the signal emission like you suggested but the mainwindow still doesn't get disabled (unless i disable the centralwidget). You're absolutely right about the quit() terminating the application but there is a significant amount of time between the emission of the signal and the actual call to quit() (i do a bunch of stuff in-between that takes time...like closing tcp connections and saving things to file.)

[wysota]

Could you prepare a minimal compilable example reproducing the problem?

[TheRonin]

Could you prepare a minimal compilable example reproducing the problem?

Sorry for the delayed response...here comes the 'minimal' example. When run on my system the main window does not become disabled unless i use the centralwidget-object :(


#include <iostream>
#include <QApplication>
#include <QMainWindow>
#include <QWidget>
#include <QPushButton>
#include <QString>
//#include <QRect>
//#include <QSize>
//
using namespace std;
//
class Gui : public QMainWindow
{
Q_OBJECT
public:
Gui( QWidget * parent = 0 );
private slots:
void disableMe();
private:
QWidget *centralwidget;
QPushButton *pushButton;
};

int main(int argc, char ** argv)
{
QApplication app( argc, argv );
Gui gui;
gui.show();
app.connect( &app, SIGNAL( lastWindowClosed() ), &app, SLOT( quit() ) );
return app.exec();
}

Gui::Gui( QWidget * parent ) : QMainWindow(parent)
{
this->setObjectName(QString::fromUtf8("MainWindow"));
this->setWindowTitle("main window test");
centralwidget = new QWidget(this);
centralwidget->setObjectName(QString::fromUtf8("centralwidget"));
pushButton = new QPushButton(centralwidget);
pushButton->setObjectName(QString::fromUtf8("pushButton"));
pushButton->setGeometry(QRect(110, 50, 101, 41));
pushButton->setText("disable?");
this->setCentralWidget(centralwidget);

QSize size(322, 149);
size = size.expandedTo(this->minimumSizeHint());
this->resize(size);

connect(pushButton, SIGNAL(clicked()),
this, SLOT(disableMe()));
}

void Gui::disableMe()
{
cout << "trying to disable the mainwindow...";
this->setDisabled(true);
cout << "success?" << endl;
}

[wysota]

Seems to work fine for me (Linux+4.2.3+Plastique). Works well on CDE and Cleanlooks as well.

[jpn]

And works for me on Qt4.2.3/Win with both, winxp and windows styles too.

[TheRonin]

Seems to work fine for me (Linux+4.2.3+Plastique). Works well on CDE and Cleanlooks as well.


And works for me on Qt4.2.3/Win with both, winxp and windows styles too.

You're kidding!? Haha, that is too weird. Things are pointing more and more towards there being a problem with my installation. I just can't see any other reason for the behavior. :eek: :confused: :crying:

[wysota]

Did the code I pasted at the beginning of the thread work for you?

[TheRonin]

Did the code I pasted at the beginning of the thread work for you?

no luck there either unfortunately :(

[wysota]

Oh, you could have said so earlier.. From what you said I understood it had worked.

[TheRonin]

Oh, you could have said so earlier.. From what you said I understood it had worked.

I'm sorry, i should have been more clear. What i meant was that the example works if i disable the centralwidget instead of trying to disable the mainwindow. This is a little easier in my example since i there have direct access to the centralwidget. In either case, i shouldn't have to though, hence the annoyance.

[wysota]

What is your exact work environment? Platform, Qt version (compiled/binary), toolchain...?

[TheRonin]

What is your exact work environment? Platform, Qt version (compiled/binary), toolchain...?

I am using windows xp pro, sp2.

I'm using Qt 4.2.2 compiled with the following configuration:

-debug-and-release
-platform win32-g++
-qt-zlib
-qt-gif
-qt-libpng
-qt-libmng
-qt-libjpeg

I am using mingw 5.0.2 as my compiler and i am writing my code in emacs and QDevelop.

Let me know if you need any more information :)

[wysota]

Does the same effect concern the binary version of 4.2.2 provided by Trolltech? Could you check?

[TheRonin]

Does the same effect concern the binary version of 4.2.2 provided by Trolltech? Could you check?

Good question and good thinking. I'll download the binary and try the example code this weekend (don't have the time now unfortunately). If it runs then its probably a problem with my compilation, if not then its something else with my system. But if other people who run the binary don't have the same problem then we've pretty much narrowed the source of it down to me. :o

have a swell easter! :D :cool: