Solved accepting dialog before/after a mass update
-
@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...
-
@user4592357
Purely at a guess, you passthis
as 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, sothis
is 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.
-
@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
, oropen
with 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. -
@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.
-
@SGaist
I totally agree, and that's what we have said to OP. However, if his "binding" really just does not allow that....
Anyway, I think we have said what we can.