Signals/slots in Qt Creator QMainWindow-based project for mobile - HOW?
-
So I have recently created a project which is based on QMainWindow, targeting mobile devices. The mainwindow.cpp/h files both tell you not to edit them, and the "has a Ui" pattern is used. This suggests that the only correct way to modify this is through the .ui file. But now, I want to do is to be able to connect something to the signals from the QActions in the menu... and I'm utterly stumped.
It does not appear to be possible to connect a signal to another signal this way, so in Designer, I created a "actionFooTriggered" slot and a "fooRequested" signal. The only way I could figure out to connect a signal to the QAction was by editing the UI's XML directly, but after that it worked.
Since I cannot modify the mainwindow.cpp file, I created a "mainwindow_slots.cpp" file and put the slot definition there. Imagine my surprise, though, when the "emit fooRequested()" generated an error! The problem appears to be that the signal does not appear in either the moc_mainwindow.cpp file or in mainwindow.h! So between these things, I'm not sure how to get any access to the UI elements of the class it created!
TIA...
-
You are using the SDK 1.1 beta and trying to do something QWidget based? If so, just ignore the file headers and edit mainwindow.h. For instance replace "private" by "protected" before the ui declaration. The way the template is presented it can't work. By the way, if you are targeting Qt 4.6.3, you are better off using SDK 1.0 . Just my 2 cents, hope it helps.
-
Well, I'm using hand-built Qt/Mobility/Creator off of git trunk (it reports "Qt Creator 2.1.81 based on Qt 4.7.2"), but I imagine that it's much the same difference.
Do you know if these are known bugs, or should I file them? (One for the missing signal in the uic-generated file, and one for the inaccessible members...)
What I ended up doing was just converting it to the double-inheritance pattern (where the MainWindow class inherits from both QMainWindow and Ui::MainWindow), although I can think of some decoupling reasons that one might not always want to do that. Changing it to "protected" is probably a better solution in general.
-
Sounds like a bug to me.
