I said 'Maybe you've a typo...' The problem with auto-connect is that you can not be sure if it is really connected (e.g. when there is a typo somewhere in the functions signature or the ui element name) and it easily breaks (e.g. when renaming an ui element).

@Kinesis You should delete them when they are not needed anymore

I got the answer. QDir directory = QFileDialog::getExistingDirectory(this, tr("Open Directory"),"/home", QFileDialog::ShowDirsOnly| QFileDialog::DontResolveSymlinks); auto listWidget_images = new QListWidget();//set listwidget to display images listWidget_images->setMinimumSize(1200,400); listWidget_images->setViewMode(QListWidget::IconMode); listWidget_images->setIconSize(QSize(320,240)); listWidget_images->setResizeMode(QListWidget::Adjust); for(const QFileInfo & finfo: directory.entryInfoList()){ ui->listWidget_dirs->addItem(finfo.absoluteFilePath()); } connect(ui->listWidget_dirs, & QListWidget::itemClicked,[listWidget_images,this](QListWidgetItem *item) { listWidget_images->show(); listWidget_images->clear(); QDir directory(item->text()); directory.setNameFilters({"*.png", "*.jpg"}); for(const QFileInfo & finfo: directory.entryInfoList()){ QListWidgetItem *item = new QListWidgetItem(QIcon(finfo.absoluteFilePath()), finfo.fileName()); listWidget_images->addItem(item); } });

@Arthur-Araruna said in Replicate the contents of the current selected item in QTableView: both column and row indices All you need to do is replace currentRowChanged with currentIndexChanged

@robro You misunderstood what @VRonin wrote: you should NOT have such loops. Just use signals/slots in your app - there are no differences to UI apps.

@TMJJ I hope you are not going to interpret the output of candump in your application to receive CAN frames! SocketCAN provides a userspace API which can be perfectly used from C/C++ programs. As SocketCAN is open source, there are lots of examples how to do this, like the SocketCAN plugin of QtSerialBus or the source code of candump. Regards

@podkiva said in Blocking Queue Between QThreads: P.S. It seems you forgot to call finishProcessing() at the end of process(const Command & cmd) {...}. No, it's not an oversight. I left it for you to call whenever appropriate, as you might be doing some asynchronous operation in process(const Command & cmd), like reading a QProcess output, or reading a socket or w/e. In that case you'd connect the signal signifying the end of that async operation to the mentioned slot to push the next command to be handled.

In this case, the color of the model item is being changed somewhere in the backend You don't require to do this. This is where Model View framework comes into picture. color change should automatically taken care by the model itself. I'm assuming that you have written custom model. Are you sending the dataChanged(..) signal whenever data is changed at model ?

@VRonin : yes, but the system is rather complex and i want to use the statemachine framwork to implement it). By the way this same signal might require other actions in some of the other states Thanks a lot for your time

@Kushan Simple C++: class Dialog2 : public QDialog { Q_OBJECT private slots: void receiveValue2 (QString val) public: QString Value explicit Dialog2(QWidget *parent = 0); ~Dialog2(); void setValue(const QString &val) { Value=val; } private: Ui::Dialog2 *ui; }; ... void MainWindow::on_pushButton_clicked() { value=ui->line_Edit->text(); Dialog dialog1; dialog1.setValue(value); }

@SGaist Thanx mate :) Qt rox :D

@Sumit Glad u got the result, Happy Coding, Thanks,

Hi If you changed to Dialog::Dialog(QStringList listToLoad, QWidget *parent = 0) ; Make sure to change it both in .h file and .cpp file so they match.

Hi it will only be a problem if you make too long lasting loop. Then it will stop redrawing.

@After For the reason why Qt::BlockingQueuedConnection does not work for you and gives you the error message, from the manual page @SGaist references: Same as Qt::QueuedConnection, except that the signalling thread blocks until the slot returns. This connection must not be used if the receiver lives in the signalling thread, or else the application will deadlock. It's for use across different threads for emitter/receiver, only.

And then you should maybe consider creating a widget to handle your threads requests for input one after the other or grouped. Whatever makes sense for your application.

@abforce said in Looking for the best multithreading patterns for database access: For this purpose can I employ a callback pattern? You can simply use signals/slots across threads

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

@Lasith Hi old type c array can also work. Its just a matter of what is registered already. You can register your own types. http://doc.qt.io/qt-5/qmetatype.html#Q_DECLARE_METATYPE

Hi Yes calling the function directly is actually a better solution in this case. Its worth mentioning that the so called slots are 100% normal c++ member functions and can be called without any Qt involvement/use of. void MainWindow::on_pushButton_clicked() { int value=ui->lineEdit->text().toInt(); // get value Dialog dialog1; dialog1.sendIntData(value); dialog1.exec(); }

@mostefa said in connecting to database when a form loads using signals and slots: I think that this post is duplicate Strictly speaking it isn't, although it's quite similar.

Thanks @raven-worx and @Chris-Kawa for the quick answers. @raven-worx said in Qt5 & invokeMethod: the 2 methods behave the same. I know that they seem to behave in the same way. But creating an timer object, running & processing the timer/timeout and deleteing the object afterwards, feels like it should be more work than queing a function call via Q_Object-Macro-Magic. However the compiler may break it down to the same thing, after all. @raven-worx said in Qt5 & invokeMethod: You can check the return value of invokeMethod() and add an assertion. That is actually a good idea, that way one would always get an immediate notification when the call becomes invalid due to changes made. Still inconvenient, but much less so. @Chris-Kawa said in Qt5 & invokeMethod: In Qt 5.10 (currently in alpha) there's gonna be an overload taking pointer to function, so you'll be able to do: YES, thanks for the info, I was not aware of that change. Now I'm hyped for Qt 5.10 more so than previously! With that said, I would consider my question answered. Thanks everyone.

@SGaist I need the slot send_console_log to be called when the signal written in ConsoleStream is emitted. When running the program with a normal while/for loop in the interpreter, the slot will be called becuase at that moment its non blocking. But the moment I add time.sleep into a loop, slots will only be called at the end when all the blocking is over. Thank you for looking into this.

I may be wrong but you can use signal and slot (on changing textbox's text example): //mainwindow.cpp constructor: MainWindow::MainWindow(QWidget *parent) : QMainWindow(parent), ui(new Ui::MainWindow) { // connection for accessing to UI from another UI ProfileSearch* profilesearch = new ProfileSearch; connect( profilesearch, SIGNAL(updateUI1Signal(const QString)), this, SLOT(updateUI2TextSlot(const QString) ) ); // launch profilesearch form: profilesearch.exec(); } //mainwindow.h { public slots: void updateUI2TextSlot( const QString text ) {ui->MWtextEdit->setText(text);} // set new text in mainwindow form } //profilesearch.h signals: void updateUI1Signal(const QString text); // row click event handler void ProfileSearch::on_row_column_whatewer_clicked() { emit updateUI1Signal("Hello from ProfileSearch form to MainWindow form"); }

@BjornW said in Signal and slot to synchronize variable between qthread: I would separate the objects into two types. One type that is the "master" object and other objects which interact with it. That's the correct thinking, I consider this whole question to be a design issue. The problem I see is that a dependency is introduced between two QObjects that are in different threads, that is very unnatural to begin with - the two objects shouldn't depend on one another implicitly; it's no mistake that a QObject instance can't have a parent that's living in another thread. In my mind either the dependency should be declared explicitly (e.g. manually synchronizing the objects across the threads in some fashion) or it shouldn't exist at all.

@SGaist thank you SGaist for your kind replay honestly all the tense & anxiety & obsecurity is gone thanks to matthew & you i know now what to focus on & what's the matter with Qt Qt is uses RAW C++ codes & don't hide any mechanism from the user hence they required you to communicate with it in RAW format codes it's really helpful to talk with experts ^_^

Oh well, I see http://doc.qt.io/qt-5/qspinbox.html Signals void valueChanged(int i) void valueChanged(const QString &text) <--rtfm! Its now clear to me :)

@QtExchange said in Segmentation fault or overflow when streaming from a QSerialPort: The trick is one QByteArray receives the data (on signal slot basis) QByteArray can receive nothing, it's an array of bytes - a container, nothing more, nothing less. where the other container (which is just a copy of the receiver-QByteArray) is parsing the received Data, as the symbols come in a random order. ??! How can you parse something that doesn't have any order? And where is this other container? I could think of having an extra signal-slot that exchanges the data between both containers whenever it is demanded, but it sounds like I have to double check if I'm actually dealing with the most current data. I don't follow. Why would be this even needed ...? There's an extra mutex for the device access, and another one for the shared message container. Qt imposes thread affinity on QObject instances, you don't need a mutex for device access, and you shouldn't share the message container. and because I'm dealing with QElapsedTimer, that needs the thread. In what universe QElapsedTimer needs a thread ...?! It's like saying that an integer needs a thread ... I don't get it.

thanks for the enlightening!

Hi, A custom widget is a widget you build yourself by e.g. aggregating other widgets or doing custom painting. Can you share your current code ? That will make things easier to help.

'description' is not captured said that in your lambda, 'description' has not been captured... then add it on the list of captured elements: [this, captured] I red inside the answers that you may declare same name for function and variable... don't do that, it will generate problems for sure. QString 'description' declared here it is a clue for said that the answer of call this.getDescription() should be a QString (QString getDescription() const;) so 'description' has to be a QString (i think in private area of this). because you are not pass it, it is an undeclared new object inside your lambda function. so give a varaible name unik and pass the variable inside your lambda by the array list [....] should fix your problem.

if u want to establish a connectin between the objects2 and objects3, as u said earlier u want to close te tab of class 2 class2::class2{ // create the object of class 3 here in constructor. Class3 obj3* = new Class3; connect(obj3,SIGNAL(signal()),this,SLOT(close()),Qt::UniqueConnection); } class3::class3 { } class3::function() { emit signal(); } so the object will be created in constructor of Class2. as the signal is emmitted , and when it is triggered the class2 will be closed. as per the post which u want to close the tab when signal is emmitted.

@mrjj Thank you! Sooo i kind of did what you said and used the currentIndexChanged signal. I made a Qbytearray where i store the currentindex and replace the index when an index changed. Then i can use this array to get the currentIndex from the row where the button was pressed. I know that there is probably a better solution but it works^^ I will mark this post as answered i guess.

Hi, What about doing the subscription related stuff in your proxy ? Basically two methods: FeedProxy::subscribe(YouCoolClass *) FeedProxy::unsubscribe(YouCoolClass *) No need for any special detection and you know exactly where things are happening.

@M4RZB4Ni You may want to see this example http://doc.qt.io/qt-5/qtwidgets-dialogs-configdialog-example.html

@mrjj Thank you a lot, it works!!!

@mrjj Hi! I managed to make everything just as I wanted, everything is going fine. The code example you sent me really did the trick. Thanks a lot.

@QtExchange Forgot to link those two, which are very important to understand before working with threads: QObjects' thread affinity: http://doc.qt.io/qt-5/qobject.html#thread-affinity Queued connections accros threads: http://doc.qt.io/qt-5/threads-qobject.html#signals-and-slots-across-threads