Solved Give me recomendations for use Qthread
-
well, in that case : Praise the compiler for code optimization,:)
because this:
connect(thread_one,SIGNAL(started()),ui->pushButton,SLOT(ui->pushButton->clicked();));
makes my heart hurt.
ui->pushButton->clicked(); is many things but above all its not a slot bit a Signal itself.
If it works, I guess this chains the started Signal to what ever pushButton is connected to.
but why dont you connect it this way than?
connect(ui->pushButton, SIGNAL(clicked()), MyObject, SLOT(mySlot())); // and the started Signal directly to the target slot connect(thread_one,SIGNAL(started()),MyObject,SLOT(mySlot()));
-
@aurquiel You should really read about Qt signals/slots, what you are doing is completely wrong:
connect(thread_one,SIGNAL(started()),ui->pushButton,SLOT(ui->pushButton->clicked();));
should be
connect(thread_one,SIGNAL(started()),ui->pushButton,SLOT(clicked()));
Why do you connect QThread::started signal to QPushButton::clicked signal? What do you want to achieve?
-
connect(thread_one,SIGNAL(started()),ui->pushButton,SLOT(clicked()));
this doesn't work
QObject::connect: No such slot QPushButton::clicked() in ../PIZZA/mainwindow.cpp:28 QObject::connect: (receiver name: 'pushButton')
I thing i must declare a new class only for threads with a public class to backend
and create the public slots in the thread class, the public slot of thread class will contain the backend functions.To get something like this
connect(ui->pushButtonChannel3, SIGNAL(clicked()), thread_one, SLOT(setChannel3()));
-
@aurquiel You're aware that clicked() is a SIGNAL not SLOT?
-
@aurquiel Yes, see my previous message "However, that still won't work because "clicked()" is a signal not a slot."
What you need to do is extend your "backend" class (Q_OBJECT) with slots for the functions you want to perform
public slots: rescan(); setChannel1(); setChannel2(); setChannel3();
Then connect you UI events to those slots.
//MainWindow.cpp connect(ui->pushButtonChannel1, SIGNAL(clicked()), backend, SLOT(setChannel1())); connect(ui->pushButtonChannel2, SIGNAL(clicked()), backend, SLOT(setChannel2())); connect(ui->pushButtonChannel3, SIGNAL(clicked()), backend, SLOT(setChannel3()));
You will probably want to reconsider the exact method for doing this eventually e.g. have a "setChannel(int channelId();" slot on backend instead and then place some logic in the UI to handle that. That is to say that the clicked handlers are within MainWindow and MainWindow emits a signal specify a numeric channel or SSID. However, that's the next step.
-
yes but backend is not a thread, i am very confuse at this point how to create a thread for the signals of the buttons could be handle with this thread.
because in the connect() must have the signal clicked and the slot of the tread also have the signal of thread started
-
ok,
how aboutconnect(thread_one, SIGNAL(started()), this, SLOT(on_pushButton_2_clicked()));
from your example
should behave exactly the same, but without error messages.
-
@aurquiel Backend does not need to be thread. Instead it is owned by a thread (I think you create that thread in MainWindow).
That is, the QThread HASA MyQObject (not MyQObject ISA QThread)
Backend is still your implementation of the USB/TV Tuner control.
Now the backend will receive events and process them (slots) in the context of the thread that owns it, not in the context of the thread that emitted the signal.
To summarise:
- Your backend does all the actual interfacing with the USB device
- Create a thread and move the backend object to it
- Start that thread
- The UI emits signals (such as QPushButton::clicked) and there is a connection between that signal and the backend object slot
- Because the backend object is owned by a different thread (and therefore has an event loop) it's slot functions are executed in the context of the thread that owns it e.g. the moveToThread argument and not in the UI context. Events are free to travel in the other direction e.g. you can "emit" from your backend thread.
That is, it is your backend object that does the processing, it is that object that you implement your functionality on (as slots). The thread you created and moved the backend object to is the thread context used to execute the slots.
This is quite a decent way of implementing the threading model as your backend object doesn't need to worry about threading models. Just let Qt handle the cross thread deferred call via it's event model using sig/slots.
-
just realized, in your example function:
//Channel 123TV void MainWindow::on_pushButton_2_clicked() { //Initilize turnner and demulator usb_and_channels->initialize_tuner_demulator(); //Tune frequency usb_and_channels->tune_in(521000); }
you access usb_and_channels and manipulate it. But you moved it previously to a different Thread
//Moving channels object to thread_one usb_and_channels->moveToThread(thread_one);
Dont do that
Allways use Signal/Slots, or Mutex, for cross-thread access, or your programm will eventually crash. -
How to move the backend object to the thread for get the public slot function of backend
backend *usb_and_channels=new backend; QThread *thread_one = new QThread(); connect(ui->pushButton,SIGNAL(ui->pushButton->clicked()),thread_one,SLOT()); thread_one->start();
QThread *thread_one = new QThread(I MUST ADD IT HERE I THIS BUT HOW);
-
class backend : QObject { Q_OBJECT backend(QObject * parent = 0) : QObject(parent) { } public slots: void go(); private: // ..... }; //.... backend * usb_and_channels = new backend(); QThread * thread_one = new QThread(); usb_and_channels->moveToThread(thread_one); connect(ui->pushButton, SIGNAL(clicked()), usb_and_channels, SLOT(go())); thread_one->start();
"go" will be called in the context of "thread_one" not the context of the UI (main) thread.
-
@matthew.kuiash said in Give me recomendations for use Qthread:
class backend : QObject { Q_OBJECT backend(QObject * parent = 0) : QObject(parent) { } public slots: void go(); private: // ..... }; //.... backend * usb_and_channels = new backend(); QThread * thread_one = new QThread(); usb_and_channels->moveToThread(thread_one); connect(ui->pushButton, SIGNAL(clicked()), usb_and_channels, SLOT(go())); thread_one->start();
"go" will be called in the context of "thread_one" not the context of the UI (main) thread.
Yes sir, thank you thank you, i was never worked with thread my mind was a miss.
Really thanks
-
@aurquiel No problem at all. If this is a solution to you problem please mark the reply as the correct answer and mark the thread as solved. Thank you!