accepting dialog before/after a mass update
-
@user4592357 said in accepting dialog before/after a mass update:
i tried single shot with 0, but it didn't even update the db (consequently, neither the table view). i did that before accepting the dialog.
Well you may need to sort out what you did/didn't do there. (Don't forget, it won't do anything before you close the dialog on the next line, the idea is that it will happen afterward.) If you want the dialog to close and then the updates to happen, it may be what you need, given that you can't get result back from dialog.
@JonB
i need the dialog to be closed after the data is updated in the database.the reason for this is that, when the dialog is closed, its event loop is finished, and the control returns back to main thread, which receives paint event and the table view is updated with new data.
if i put the accept dialog code before updating the database, the dialog will be closed immediately (that's what i want), then database will be updated. BUT in this case, table view will not be updated with the new data immediately because dialog's event loop was finished before updating the database. when i trigger a repaint, e.g. click on a table cell, only then i see the new data (this is NOT what i want).
-
@JonB
i need the dialog to be closed after the data is updated in the database.the reason for this is that, when the dialog is closed, its event loop is finished, and the control returns back to main thread, which receives paint event and the table view is updated with new data.
if i put the accept dialog code before updating the database, the dialog will be closed immediately (that's what i want), then database will be updated. BUT in this case, table view will not be updated with the new data immediately because dialog's event loop was finished before updating the database. when i trigger a repaint, e.g. click on a table cell, only then i see the new data (this is NOT what i want).
@user4592357 said in accepting dialog before/after a mass update:
when i trigger a repaint, e.g. click on a table cell, only then i see the new data (this is NOT what i want).
Indeed, that should not be the case.
When I suggest
QTimer::singleShot()and have that do the updates (after the dialog exits), you should see the updates reflected in the table view. Without you having to click anything, or code doing any explicit repaints. This would happen a little after you close the dialog, according as the time you say it takes it to update. Which I think you will settle for/is what you are looking for, as you have to spend the update time somewhere. If you are not getting it to work this way, you are not succeeding in using the timer as it should be.If you cannot get all this to work, you could just go back to your original code and have it put up some indication to the user while the database updates take place before the dialog closes. That could be changing wording on the dialog, putting up a "wait" cursor, or putting up a further dialog to say "Updating...".
-
@user4592357 said in accepting dialog before/after a mass update:
when i trigger a repaint, e.g. click on a table cell, only then i see the new data (this is NOT what i want).
Indeed, that should not be the case.
When I suggest
QTimer::singleShot()and have that do the updates (after the dialog exits), you should see the updates reflected in the table view. Without you having to click anything, or code doing any explicit repaints. This would happen a little after you close the dialog, according as the time you say it takes it to update. Which I think you will settle for/is what you are looking for, as you have to spend the update time somewhere. If you are not getting it to work this way, you are not succeeding in using the timer as it should be.If you cannot get all this to work, you could just go back to your original code and have it put up some indication to the user while the database updates take place before the dialog closes. That could be changing wording on the dialog, putting up a "wait" cursor, or putting up a further dialog to say "Updating...".
@JonB
these are last two lines of ok button's slot:QDialog::accept(); QTimer::singleShot(0, this, [&] { // update the database });with this i get a segfault with stack trace looking like this:
QEventLoop::exit(int) () from ... QCoreApplication::exit(int) () from ... ?? () from ... QMetaObject::activate(QObject*, int, int, void**) () from ... QWidgetPrivate::close_helper(QWidgetPrivate::CloseMode) () from ...and if i mix up the lines, then the database is not updated...
-
@JonB
these are last two lines of ok button's slot:QDialog::accept(); QTimer::singleShot(0, this, [&] { // update the database });with this i get a segfault with stack trace looking like this:
QEventLoop::exit(int) () from ... QCoreApplication::exit(int) () from ... ?? () from ... QMetaObject::activate(QObject*, int, int, void**) () from ... QWidgetPrivate::close_helper(QWidgetPrivate::CloseMode) () from ...and if i mix up the lines, then the database is not updated...
@user4592357
Purely at a guess, you passthisas the context, but the dialog dies once you accept it and exit? It's up to you to write the database update code so it does not depend on the dialog being in existence.If you or someone else has a better solution. I suggested it as an approach, I don't know what the whole of your code does, nor what the "language binding" might affect.
-
@user4592357
Purely at a guess, you passthisas the context, but the dialog dies once you accept it and exit? It's up to you to write the database update code so it does not depend on the dialog being in existence.If you or someone else has a better solution. I suggested it as an approach, I don't know what the whole of your code does, nor what the "language binding" might affect.
@JonB
i wasn't sure what else to put in context.
actually, updating the database uses parameters passed to the dialog invocation, sothisis touched when invoking database update lambda. -
One thing you could do is write down how you want your logic to work.
Most of the time, like already written in this thread, its:
- Show dialog
- Click Ok / Cancel -> closes the dialog
- If Ok, grab data from dialog
- Do update
- Be happy
If "Do update" takes some more time, you can use a progress bar / sign so your users know that something is happening without having the feeling that your application is somehow stuck because the dialog is still there and nothing is updating.
-
One thing you could do is write down how you want your logic to work.
Most of the time, like already written in this thread, its:
- Show dialog
- Click Ok / Cancel -> closes the dialog
- If Ok, grab data from dialog
- Do update
- Be happy
If "Do update" takes some more time, you can use a progress bar / sign so your users know that something is happening without having the feeling that your application is somehow stuck because the dialog is still there and nothing is updating.
@SGaist
i do echo what is happening so the user knows that updating is in progress.
my whole concern is the dialog still being there. -
Well, that's step three: processing happens after the dialog has been closed. because you either used
exec, oropenwith a slot which in both case should result in the logic continuing after the dialog has disappeared.Interested in AI ? www.idiap.ch
Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct -
Well, that's step three: processing happens after the dialog has been closed. because you either used
exec, oropenwith a slot which in both case should result in the logic continuing after the dialog has disappeared.@SGaist
You have to read up. Remember, OP claims he cannot receive result from dialog via his "binding", so he has to put the update logic to be called from within the dialog.in my method i don't have the pointer to the dialog.
invoke dialog with name='updateDialog'
it's tcl language binding for c++. actually it has the idea of return value, but in case of dialog invocation the result is not set to the result of dialog execution.I did ask whether it is really not possible to retrieve the dialog result. I did also suggest a message while updating.
@user4592357
So long as your update logic relies on the dialog being in existence, you may have problems doing it when the dialog is no longer there, as you want. You may have to divorce your update code from the dialog, if you really need this. -
@SGaist
You have to read up. Remember, OP claims he cannot receive result from dialog via his "binding", so he has to put the update logic to be called from within the dialog.in my method i don't have the pointer to the dialog.
invoke dialog with name='updateDialog'
it's tcl language binding for c++. actually it has the idea of return value, but in case of dialog invocation the result is not set to the result of dialog execution.I did ask whether it is really not possible to retrieve the dialog result. I did also suggest a message while updating.
@user4592357
So long as your update logic relies on the dialog being in existence, you may have problems doing it when the dialog is no longer there, as you want. You may have to divorce your update code from the dialog, if you really need this.@JonB I do but I don't think it's a good idea to make the dialog responsible of the update. It needs to provide information for it to happen, no problem with that, but it's not its role to perform the update itself.
Interested in AI ? www.idiap.ch
Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct -
@JonB I do but I don't think it's a good idea to make the dialog responsible of the update. It needs to provide information for it to happen, no problem with that, but it's not its role to perform the update itself.
