I have a problem performing multiple check operations. Basically what i do is I will click on mark several action to call markSeveral() and then from there i call clicked() signal of list to call setcheckBoxes() and then set the checkboxes. now the provlem is dis happens perfectly qt first time, but when i do it for second time the setcheckboxes() slot is called twice hence d checkboxes are not set. Again for third attempt the setcheckboxes() slot is called thrice but d checkboxes do get set.
Why is the slot called so many times when i make a call to it only once?
please tell me what I am doin wrong
Thanks in advance. here is the piece of my code:
void Browser::markSeveral()
{
itemClicked=true;
multiSelect=true;
MarkClicked=true;
MarkMenuClicked=true;
connect(list,SIGNAL(clicked(QModelIndex)),this,SLOT(setCheckBoxes(QModelIndex)));
}
void Browser::setCheckBoxes(QModelIndex index)
{
if(MarkClicked ==true && model->data(index,Qt::CheckStateRole) == Qt::Unchecked)
{
model->setData(index,Qt::Checked,Qt::CheckStateRole);
indexList.append(index);
}
else
{
if(MarkClicked ==true && model->data(index,Qt::CheckStateRole) == Qt::Checked)
{
model->setData(index,Qt::Unchecked,Qt::CheckStateRole);
indexList.removeOne(index);
}
}
}
If you connect a signal to a slot n times, emitting the signal once will call the slot n times. If you call markSeveral() multiple times, you have multiple connections.
You should do the connect() call only once, usually in the ctor of Browser.
Or ensure that there is only one connection, by using Qt::UniqueConnection:
connect( list,SIGNAL(clicked(QModelIndex)),this,SLOT(setCheckBoxes(QModelIndex)), Qt::UniqueConnection );
This ensures that there is exactly one connection.
The former option (calling connect() once when setting up the widget) is to be preferred though.
Related
I found time to investigate a bit into QT, and it is very interesting for me. However, right now I am encountering a problem that I am not aware about how to solve it. My aim is actually simple. I have a QCheckBox that I want to activate. If it is activated, I am starting a process (I am opening a file, reading it, taking some values out and change different labels accordingly). This process is repeated until the user is deactivating the QCheckBox. Some small code example to get a better idea of what I am going to do.
void Analyzer::on_actualTemperature_stateChanged(int arg1)
{
// Read data and change labels
if (arg1 != 0)
{
qDebug() << "Start data analysis";
// Infinity loop to get the data and display it
while true
{
// Open file and extract data
const actualTemperature = getData();
// Change any label or do something with the data
ui->anyLabel->setText(actualTemperature);
// Some break
QThread::sleep(1);
// Leave the loop if user deactivate the QCheckBox
// Something like on_actualTemperature_stateChange == 0
}
}
// Stop reading the data
else
{
qDebug() << "Stop data analysis";
}
}
It is obvious that after activating the QCheckBox, the loop will not finish at all and the GUI will not recognize anything anymore. Hence, I guess I have to start some new thread and have to kill it. However, I have no idea how to proceed here. An idea would be:
void Analyzer::on_actualTemperature_stateChanged(int arg1)
{
// Read data and change labels
if (arg1 != 0)
{
// Start reading the file and updating the label using some other thread
startThread(XY);
}
// Stop reading the data
else
{
// Kill thread 1234
killThread(XY);
}
}
Any hint is warmly welcomed and I hope this question is not too basic for you. Thank you for reading, Tobi.
I think killing a running thread is not a decent behavior. Let's be gentle to our threads with a loop control variable. In this example it named keepLoop. Set keepLoop when checkbox checked. Then start thread if it is not running. We are using QtConcurrent::run, and monitoring it by a QFuture in this case.
connect(ui->checkBox, &QCheckBox::toggled,
[&](const bool checked) {
analyzer->keepLoop = checked;
if (checked && !future.isRunning())
future = QtConcurrent::run(analyzer, &Analyzer::on_actualTemperature_stateChanged);
}
);
Don't call user interface slots directly, instead connect them to signals. Connections will be queued connection when signals emitted from another thread. It means slots will be called in event loop of main thread and changes will be shown when the next frame painted.
connect(analyzer, &Analyzer::temperatureCalculated, ui->anyLabel, &QLabel::setText);
Our asynchronous function does not forced to die immediately when user toggle checkbox. Instead we letting it to finish the iteration it already on halfway through.
Analyzer::on_actualTemperature_stateChanged() {
while (keepLoop) {
// Open file and extract data
const QString& actualTemperature = getData();
// send data
emit temperatureCalculated(actualTemperature);
}
}
You can use atomic bool if you want a more precise loop control.
Bonus:
If you don't want to mess with threads, you can avoid GUI freezing by using QTimer to run your loop periodically in main thread.
I see the accept() somewhat similar to a return, so I've been putting it a the end of my slots with no code afterwards. That is, the accept() "finishes" the execution of the dialog.
Nevertheless, I came across the need to close a dialog and open a new one from a slot in the first one. Therefore, what I thought was moving the accept() to the beginning of the slot and initializing the second dialog after it. Something like the following:
void FirstDialog:slotFirstDialog()
{
accept();
// Setup second dialog arguments
// ...
SecondDialog *sd = new SecondDialog();
sd->exec();
}
Is this use of accept() valid? Is it good practice?
I'd avoid it. Calling accept() can trigger a delayed deletion of FirstDialog (say, if it has the Qt::WA_DeleteOnClose flag set)1; in that case, it would be deleted in one of the first events dispatched by the nested event loop (sd->exec()), which would lead to go on executing code in a method of an instance that has been deleted. This is just a sample problem on the top of my head, I'm sure others can be found.
I'd probably just hide the dialog before calling exec() on the other, and call accept() after the end of the nested event loop.
void FirstDialog:slotFirstDialog()
{
// Setup second dialog arguments
// ...
SecondDialog *sd = new SecondDialog();
hide();
sd->exec();
accept();
// NB are we leaking sd?
}
By the way:
SecondDialog *sd = new SecondDialog();
sd->exec();
here you are allocating on the heap a dialog without a parent, so either you set the Qt::WA_DeleteOnClose or explicitly call this->deleteLater() inside its code, or you are leaking the dialog instance.
Notes:
and it is explicitly remarked in the documentation
As with QWidget::close(), done() deletes the dialog if the Qt::WA_DeleteOnClose flag is set.
QDialog::accept calls QDialog::done with a dialog code Accepted. Here is how QDialog::done looks like:
void QDialog::done(int r)
{
Q_D(QDialog);
setResult(r);
hide();
d->close_helper(QWidgetPrivate::CloseNoEvent);
d->resetModalitySetByOpen();
emit finished(r);
if (r == Accepted)
emit accepted();
else if (r == Rejected)
emit rejected();
}
which, according to the documentation:
Hides the modal dialog and sets the result code to Accepted.
With this in mind, I think this is not a question of a good practice, but of what your application logic requires.
I'm using PNaCl and I'm in a situation where first I receive a message that is handled in the 'HandleMessage' function as the normal way, but then in the current HandleMessage execution, I need to wait for a user input that would come from an other message in order to complete the execution.
I'm wondering if this is possible to do that (handling a message while already waiting in the 'HandleMessage' function) ? And if so, can someone give me a trick ?
Thanks !
HandleMessage is currently called on one thread, the main thread. So you cannot receive a message while you are handling another message.
We typically suggest you spawn a new thread to do your work, and leave the main thread to handle messages, and queue them for the new thread to handle. Take a look at the nacl_io_demo example in the SDK for an example of this technique (found in examples/demo/nacl_io).
Another solution is to use a state machine; i.e. keep track of your current state in a variable instead of on the stack.
For example:
enum State {
STATE_INIT,
STATE_WAITING_FOR_INPUT,
STATE_DO_OTHER_STUFF,
};
State state_;
virtual void HandleMessage(const pp::Var& var_message) {
switch (state_) {
case STATE_INIT:
if (var_message.AsString() == "first_message") {
state_ = STATE_WAITING_FOR_INPUT;
// Do some work before you need the user input ...
}
break;
case STATE_WAITING_FOR_INPUT:
if (var_message.AsString() == "user_input") {
// Do more work, now that we've received input from the user...
state_ = STATE_DO_OTHER_STUFF;
}
break;
}
}
I use checkboxes in my GUI to toggle bits in a class controlling a maschine connected by signals/slots.
I also need the opposite direction, because if some commands to the maschine toggle the same bits, my GUI should reflect the changes.
My problem is:
When I click the checkbox, its state is not yet updated when the signal is sent.
So the first signal arrives at the maschine, the bit gets toggled, the maschine responds with the second signal and arrives at the GUI handler method 'updateCheckBoxXYZ'.
Now I want to figure out if I need to update the checkbox.
If the whole chain is started by user, the checkbox will be updated automatically at last.
If an internal command directly toggled the bit, the checkbox will need to be checked to reflect the internal change.
Because the checkbox has not been checked yet, I can not ask for 'isChecked()'.
What should I do to not getting trapped in an endless loop?
Update:
I just tried something like the following code:
// slot called by toggled(bool)
void DialogXY::checkBoxXYChanged(bool bState)
{
if (bState != m_bGuiStateXY)
{
m_bGuiStateXY = bState;
emit GuiXYChanged(bState);
// optional: .. do some GUI related things ..
}
}
// slot called on signal 'GuiXYChanged(bState)'
void Machine::changeXY(int iModul, bool bState)
{
if (bState != m_bMachineStateXY)
{
emit MachineXYChanged(bState);
}
// .. change machine configuration ..
}
// slot called on signal 'MachineXYChanged(bState)'
void DialogXY::updateCheckBoxXY(bool bState)
{
if (bState != m_bStateXY)
{
ui.checkBoxXY->setChecked(bState);
// will signal toggled()
}
}
But I need extra variables for each GUI item,
I have to initialize then correctly, etc.
I would prefer something more elegant.
I have a QTableView, populated with a QStandardItemModel.
I update the model frequently over network and the model is also updated by user directly via the QTableView.
Now I like to call a method when the user is changing some data, so i did:
connect(model, SIGNAL(itemChanged(QStandardItem*)), this, SLOT(dataChanged(QStandardItem*)));
The Problem now is, that my dataChanged method is called, also when the item is updated over the network.
model->setData(index, new_val);
Is there another signal which is only emitted if, the user is changing something inside the QTableview ???
No, AFAIK there is no such signal but you there is a way to hack it.
When editing an item from the QTableView the activated signal will have been emited. The idea is to catch this signal and connect it to a slot that will store the last manually changed item.
connect(view, SIGNAL(activated(QModelIndex), this, SLOT(manuallyActivated(QModelIndex)));
void manuallyActivated(QModelIndex index)
{
// This variable should be in your header file...
lastManuallyModifiedIndex = index;
}
Now simply modify your dataChanged slot to check if the item that changed corresponds to the last modified item.
void dataChanged(QStandardItem* item)
{
// If it is invalid simply ignore it...
if (lastManuallyModifiedIndex.isValid() == false)
return;
// only if it is modified manually we process it
if (item->index() == lastManuallyModifiedIndex)
{
// make last modified index invalid
lastManuallyModifiedIndex = QModelIndex();
doSomething();
}
}
You could block the table signals when an update comes in from your network.
QObject::blockSignals(bool block)
or you could listen for click and edit event in succession.