I tried some different options, and found a solution: void MainWindow::saveSettings() { name = (QCoreApplication::applicationDirPath() +"/logs/"+ui->lineEdit->text() +".txt"); QFile file (name) ; if (newfile == true){ if (file.exists()){ qDebug ()<<"already exists"; NewLog(); timer->stop(); } else { qDebug()<< "Does not exist"; file.open(QIODevice::WriteOnly | QIODevice::Text | QIODevice::Append); QString c_time = QTime::currentTime().toString(); QString sText =QString::number(update) + ". "+ c_time + ": rpm = "+ rpm + ", load = "+ QString::number(load) + ", " + name1+ " = " + result1 + ", "+ name2+ " = " + result2 + ", " + name3+ " = " + result3 + ", "+ name4+ " = " + result4 + ", " + name5+ " = " + result5 + ", "+ name6+ " = " + result6 + ", " + name7+ " = " + result7 + ", "+ name8+ " = " + result8 + ", " + name9+ " = " + result9 + ", "+ name10+ " = " + result10; ui->label_log->setText(sText); update++; QTextStream out(&file); out << sText + "\n"; file.close(); newfile = false; }}else{ file.open(QIODevice::WriteOnly | QIODevice::Text | QIODevice::Append); QString c_time = QTime::currentTime().toString(); QString sText =QString::number(update) + ". "+ c_time + ": rpm = "+ rpm + ", load = "+ QString::number(load) + ", " + name1+ " = " + result1 + ", "+ name2+ " = " + result2 + ", " + name3+ " = " + result3 + ", "+ name4+ " = " + result4 + ", " + name5+ " = " + result5 + ", "+ name6+ " = " + result6 + ", " + name7+ " = " + result7 + ", "+ name8+ " = " + result8 + ", " + name9+ " = " + result9 + ", "+ name10+ " = " + result10; ui->label_log->setText(sText); update++; QTextStream out(&file); out << sText + "\n"; file.close(); }} Maybe it can be easier, but i am still learning. Thanks for your input. If you have comments on how to change my code, please tell me. (newlog was only to test something else now)

@ambershark said in How to add one parameter to the clicked SIGNAL?: @aha_1980 That sure does do what he needs, lol. I didn't know about QSignalMapper.. It's funny that even after 16+ years of Qt there's still classes I don't know about. :) I only knew it because I had the same requirement as @ChristianMontero some time ago :)

@Sowmiya-R Ok, that does not happen for me. Without break point it works correctly here. I have no idea what could be wrong with your Qt. Since you are using a clean project to test, i assume is something with your pc or Qt.

Yep, it works. Thanks :)

This is actually correct and behaves very strangely, sometimes it works and sometimes not. Problem is big if one is beginner like me. I don't know why the problem still persists after 3 years. Currently i am using Qt Creator 4.9.2 with Qt 5.12.4 with Mingw.

@kshegunov Yeah, 50% is not Qt enabled so would be an issue. Im just daydreaming :) Hmm, that is actually neat.

Depending on how complex things get, it might make sense to have a "data aggregation layer" between logic and UI. Basically, a UI element would only be connected to a single signal of the aggregation layer, and the aggregation layer would keep track of data changes, and would know when to emit that one signal. It doesn't reduce complexity, but it cleanly distributes it between two parts of your program.

@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.

@Warbit said: oops, its my silly fault. Thanks for help, and sorry for stupid questions. You're welcome :-) Please don't feel bad; I think it was a perfectly valid question. Happy coding!

@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.

Hello good afternoon, When I go to the forum to solve a problem it is because I could not find anything on the web, but in this case was too simple theme, perhaps only experiencing what he had resolved because it is too simple to implement signals and slots between the application and the dll To end the post: to implement the slot in the plug receiving a signal from the application, add the virtual interface slot public slots: virtual void disparador(QString texto) = 0; and I made in the implementation of the interface public slots: void disparador(QString texto); to connect to the application, I used getObject connect( this, SIGNAL(disparaTexto(QString)), plgItfz->getObject(), SLOT(disparador(QString)) ); Thank you greetings

@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);