How to wait in a slot?
-
Hi,
You should rather use something like QDialog::open and connect a slot to the finished signal and change your variable there so there's no need for any while loop, you just check the value of the dialogShown. Note that the usual multithreading protection consideration should be taken.
There might be other ways but it alls depends on how that dialog is supposed to be used.
-
You should rather use something like QDialog::open and connect a slot to the finished signal
I learned that it is better than exec. But it seems not to help control the number of dialogs shown.
multithreading protection consideration should be taken
I do not quite understand. If you mean use mutiple threads, it certainly works. But I wonder is it really necessary?
-
You should rather use something like QDialog::open and connect a slot to the finished signal
I learned that it is better than exec. But it seems not to help control the number of dialogs shown.
multithreading protection consideration should be taken
I do not quite understand. If you mean use mutiple threads, it certainly works. But I wonder is it really necessary?
@tmp15711 said in How to wait in a slot?:
multithreading protection consideration should be taken
I do not quite understand. If you mean use mutiple threads, it certainly works. But I wonder is it really necessary?
no, he means if you use multiple threads, you need to protect your variables (mutex &co.)
regarding your problem: set a flag when showing the dialog, clear it on dialog close. if flag is set, don't show other dialog.
-
@tmp15711 said in How to wait in a slot?:
multithreading protection consideration should be taken
I do not quite understand. If you mean use mutiple threads, it certainly works. But I wonder is it really necessary?
no, he means if you use multiple threads, you need to protect your variables (mutex &co.)
regarding your problem: set a flag when showing the dialog, clear it on dialog close. if flag is set, don't show other dialog.
-
@aha_1980 I agree. Then, what is the proper way not to show other dialog? Return immediately? If so, showDialog will be tryied again and again to ensure a dialog is shown.
@tmp15711 said in How to wait in a slot?:
@aha_1980 I agree. Then, what is the proper way not to show other dialog? Return immediately?
from what we know about your task so far, yes.
If so, showDialog will be tryied again and again to ensure a dialog is shown.
then the question arises why the slot must be called again and again. which signal is it connected to?
(a possibility would also be to disconnect the slot from the signal when the dialog is shown and connect again after finishing)But maybe you could explain what you really want to do. maybe there is a simpler and less "hacky" solution.
-
@tmp15711 said in How to wait in a slot?:
@aha_1980 I agree. Then, what is the proper way not to show other dialog? Return immediately?
from what we know about your task so far, yes.
If so, showDialog will be tryied again and again to ensure a dialog is shown.
then the question arises why the slot must be called again and again. which signal is it connected to?
(a possibility would also be to disconnect the slot from the signal when the dialog is shown and connect again after finishing)But maybe you could explain what you really want to do. maybe there is a simpler and less "hacky" solution.
-
@aha_1980 The motivation is quite simple. My program will listen to some event, and then do something. But before that, I must get a confirmation from the user. At the same time, I want confirmations appear one by one. Any suggestions?
@tmp15711 technically you can use a fifo e.g.
QQueue. append every time you need to show a dialog but there is currently one open. when a dialog is closed, check if the fifo contains one more element. if yes, show the next dialog, otherwise stop.but from usuability, this sounds horrible. the user is degraded to confirm a bunch of dialogs. I hate every program that acts this way.
-
Is it only a yes/no question that you ask your user ?
-
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.
