@Suroh6 said:

I solved it myself, it appears due to my inheritance of the ui_mainwindow i was getting the diamond inheritance issue :)

Multiple inheritance from QObject derived classes is not supported, but you shouldn't have that in the first place. Aside from that there's no problem with inheriting from QObject (directly or indirectly) and another class. In fact it's done as a standard way of providing interfaces for plugin implementations.

@mar0029 As @mrjj already said this is just wrong:

MainWindow *test = new MainWindow(this) connect(test->setupScreen, SIGNAL(sendSetupLocation(QString)), this, SLOT(receivedSetupLocation(QString)));

You create a NEW instance of MainWindow and connect its signal with the slot. You must use MainWindow instance that already exists. If your dialog is not created directly by MainWindow, but instead by another dialog then you can just pass the pointer to your MainWindow instance to the first dialog constructor which then pass it to the second dialog constructor.

Printing the variable which is set in a slot just after connecting the signal to the slot will just print its current value (empty string in this case)., because the slot was not called yet. If you call the slot directly with a not empty string then this string should be printed.

@SGaist

Thank you. That seemed to be the last missing piece. It does what I want now.

@JohanSolo

Ah ok, so it is due to the organization of C++ not Qt, and like you said, the difference of a class instances and pointers.

It has been long time since I've had to use C++ and I never did anything too advance with it other than a text-based adventure game. I generally am more focused on hardware oriented programing such as with C and Verilog, and MATLAB is the only more software (excluding Arduino interaction) oriented language I have decent experience with.

Thank you for pointing out why there needs to be a difference. I wasn't familar with pointer usage in C++.

@diredko Qt will output signal/slot problems on the console. Run your application from the console and you should see something like:

QObject::connect: No such slot QObject::movePiece(int, int, int, int)

Or something similar if there is an issue.

Also you can add a qDebug() << "Got here" to your connect() but like @SGaist said, you are connecting in a bad place. qDebugs() will show up on the console as well.

If you are in windows you will have to add CONFIG += console to your project file. Linux and OSX should be fine without.

And finally add qDebug() messages to your move and movePiece to see if it's getting in there.

Or of course you could use the debugger for all this. ;)

@Exotic_Devel said:

Q_SLOTS

Usar a macro em vez da keyword é recomendada quando você usa outras bibliotecas que podem colidir com o Qt em relação aos signals/slots, que é o caso do Boost.

Ok sorry , it works now ! thanks you very much !

@JKSH Thanks for your help, May you help me more by writing a sample code for this ?

Thanks

@panch said:

Would you then restrict the signals/slots to only GUI-related information passing? As a proper way of developing Qt applications, I mean...

QNetworkAccessManager emits signals to tell the world that a download has completed. QSerialPort emits signals to tell the world that some data has been received. QMediaPlayer emits signals to tell the world that its playback status has changed.

These show that signals and slots are "proper" for developing all kinds of things, not just GUIs.

@dnasta I have found simple example with similar implementation.
But anyway, this is old school syntax of connect, with new syntax it doesn't work.

@JKSH
Ah, moc assumes first class only. So its simply not supported.
Thats good to know.

If you can't, just edit the thread title and prepend [solved]

Hi,

Short answer: no

The slot signature must either have the same number or less parameters than the signal and the type must be the same.

You could also simplify this a little:

void MainWindow::menuToggled() { auto widget = (container->currentWidget() == menuWidget) ? mdiContainer : menuWidget; container->setCurrentwidget(widget); }

You can first retrieve the getSelectedTabAsWidget() as a QWidget, check that it's not null, and if qobject_cast<QMdiArea*>() doesn't return NULL.

Snippet 1:

QWidget* selectedWidget = getSelectedTabAsWidget(); if ( selectedWidget == NULL ) { return; } QMdiArea* mdiArea = qobject_cast<QMdiArea*>(selectedWidget); if ( mdiArea == NULL ) { return; } // Here, we know that mdiArea is indeed a QMdiArea.

Snippet 2:

QWidget* selectedWidget = getSelectedTabAsWidget(); if ( selectedWidget == NULL ) { return; } if ( ! selectedWidget->inherits(QMdiArea::staticMetaObject.classname()) return; // Here, we know that mdiArea is indeed a QMdiArea. QMdiArea* mdiArea = qobject_cast<QMdiArea*>(selectedWidget);