GUI event blocking
-
@kshegunov
Yes indeed, but as we said:And then you use in the places you have threads and/or event loops spinning, by just creating an instance:
In principle I have no idea where code might have "threads and/or event loops". (Seriously, it took me days & debugging to even discover this particular button invoked code which did that, I had no idea it did! Which is my point.) So in effect I'd like this around every single UI slot handler (or probably 99% of them but not 1%), and I'm not prepared to edit thousands of places to do that! :)
@JonB said in GUI event blocking:
So in effect I'd like this around every single UI slot handler, and I'm not prepared to edit thousands of places to do that!
That might be rather bad idea, as event filters do hurt performance, even though in this case it's only a single
dynamic_cast. You're trying to fight against the way UIs work - i.e. event driven. You could install that kind of class directly on theQCoreApplicationobject (with the proper modification), where you'd filter the events globally, but seems rather dubious decision.Read and abide by the Qt Code of Conduct
-
@JonB said in GUI event blocking:
So in effect I'd like this around every single UI slot handler, and I'm not prepared to edit thousands of places to do that!
That might be rather bad idea, as event filters do hurt performance, even though in this case it's only a single
dynamic_cast. You're trying to fight against the way UIs work - i.e. event driven. You could install that kind of class directly on theQCoreApplicationobject (with the proper modification), where you'd filter the events globally, but seems rather dubious decision.You could install that kind of class directly on the QCoreApplication object (with the proper modification), where you'd filter the events globally, but seems rather dubious decision.
That indeed sounds more like it, because I could do that in my own object which tests a flag to cause this behaviour, and where the flag would be set by the called code which knows it needs it and not the calling code which does not know that. This could be precisely what I am looking for....
You might look to look at my new https://forum.qt.io/topic/88481/is-it-possible-to-intercept-a-modal-dialog-s-event-loop now, where I'm asking just that about application versus dialog event loops....
-
You could install that kind of class directly on the QCoreApplication object (with the proper modification), where you'd filter the events globally, but seems rather dubious decision.
That indeed sounds more like it, because I could do that in my own object which tests a flag to cause this behaviour, and where the flag would be set by the called code which knows it needs it and not the calling code which does not know that. This could be precisely what I am looking for....
You might look to look at my new https://forum.qt.io/topic/88481/is-it-possible-to-intercept-a-modal-dialog-s-event-loop now, where I'm asking just that about application versus dialog event loops....
@JonB said in GUI event blocking:
You might look to look at my new
Will do, but later, as I have some work to do now. :)
Read and abide by the Qt Code of Conduct
-
@JonB said in GUI event blocking:
You might look to look at my new
Will do, but later, as I have some work to do now. :)
@kshegunov
Of course you must, and get back to fixing those nuclear reactors/missiles you work on :) Thanks so much for your comments! -
You could install that kind of class directly on the QCoreApplication object (with the proper modification), where you'd filter the events globally, but seems rather dubious decision.
That indeed sounds more like it, because I could do that in my own object which tests a flag to cause this behaviour, and where the flag would be set by the called code which knows it needs it and not the calling code which does not know that. This could be precisely what I am looking for....
You might look to look at my new https://forum.qt.io/topic/88481/is-it-possible-to-intercept-a-modal-dialog-s-event-loop now, where I'm asking just that about application versus dialog event loops....
@JonB Another thing you could try is to disable all the controls you don't want being activated during processing. Then enable them when processing is done.
This would be better handled via a modal dialog with a progress bar (even an indefinite one) and a cancel button.
But the other option is just setting
QWidget::setEnabled(false). People using the app may be confused why things were disabled all of a sudden though so I still think the modal progress dialog would be the best way.But you could keep a list of QActions and/or QWidgets you want disabled during that call and just iterate through the list and
setEnabled(false)until complete then iterate through again and enable them.Just another suggestion that may work for you. You have lots of choices on how to handle this and I don't have any great advice on the "best" way so just throwing things out as I think of them. :)
My L-GPL'd C++ Logger github.com/ambershark-mike/sharklog
-
@JonB Another thing you could try is to disable all the controls you don't want being activated during processing. Then enable them when processing is done.
This would be better handled via a modal dialog with a progress bar (even an indefinite one) and a cancel button.
But the other option is just setting
QWidget::setEnabled(false). People using the app may be confused why things were disabled all of a sudden though so I still think the modal progress dialog would be the best way.But you could keep a list of QActions and/or QWidgets you want disabled during that call and just iterate through the list and
setEnabled(false)until complete then iterate through again and enable them.Just another suggestion that may work for you. You have lots of choices on how to handle this and I don't have any great advice on the "best" way so just throwing things out as I think of them. :)
@ambershark
Hi amber,The application has 100 "top-level" dialogs, with an average of 3 buttons each (without even including other input controls which cause code to run). That's 300 potential "callers", which might lead to "re-entrancy".
Meanwhile, it has 3 "bottom-level" functions which cause a thread/event loop to be spun, which, if hit, will allow fatal "re-entrancy" in the ultimate, top-level dialog (i.e. allow another a button to be pressed while still servicing the original button press).
To use
setEnabled(false), or keep a stack of callers, or any solution aimed at the caller, requires me to put code in 100, or 300, places. And furthermore to maintain that as further dialogs/buttons are added in future. To deal with it by causing a block, somehow, in the offending callee requires code in 3 places.Which would you rather do?
That's why I started new thread https://forum.qt.io/topic/88481/is-it-possible-to-intercept-a-modal-dialog-s-event-loop ...
-
@ambershark
Hi amber,The application has 100 "top-level" dialogs, with an average of 3 buttons each (without even including other input controls which cause code to run). That's 300 potential "callers", which might lead to "re-entrancy".
Meanwhile, it has 3 "bottom-level" functions which cause a thread/event loop to be spun, which, if hit, will allow fatal "re-entrancy" in the ultimate, top-level dialog (i.e. allow another a button to be pressed while still servicing the original button press).
To use
setEnabled(false), or keep a stack of callers, or any solution aimed at the caller, requires me to put code in 100, or 300, places. And furthermore to maintain that as further dialogs/buttons are added in future. To deal with it by causing a block, somehow, in the offending callee requires code in 3 places.Which would you rather do?
That's why I started new thread https://forum.qt.io/topic/88481/is-it-possible-to-intercept-a-modal-dialog-s-event-loop ...
@JonB Lol yea that sounds nasty... It sounds like it needs a massive rewrite of it's GUI. These things are not normal issues for normal guis.
Having 100s of dialogs is already pretty suspicious by itself. I've written some very large GUIs (million+ lines of code) and those never even came close to 100s of anything, much less of the rarely used (in modern guis) dialogs.
It sucks you got stuck supporting that. It will not be a fun job, lol.
My L-GPL'd C++ Logger github.com/ambershark-mike/sharklog
-
@JonB Lol yea that sounds nasty... It sounds like it needs a massive rewrite of it's GUI. These things are not normal issues for normal guis.
Having 100s of dialogs is already pretty suspicious by itself. I've written some very large GUIs (million+ lines of code) and those never even came close to 100s of anything, much less of the rarely used (in modern guis) dialogs.
It sucks you got stuck supporting that. It will not be a fun job, lol.
@ambershark
Well, the principle is exactly the same regardless of whether one has dialogs, windows, widgets or whatever. It's that I don't want re-entrancy when a button/other input element is clicked, till whatever code it executes has completed. And putting the onus for writing the code on the caller, of which there are potentially many, instead of in the callee, of which there are a handful if any, just seems absolutely crazy to me. Even though I seem to be a lone voice in this.... -
@ambershark
Well, the principle is exactly the same regardless of whether one has dialogs, windows, widgets or whatever. It's that I don't want re-entrancy when a button/other input element is clicked, till whatever code it executes has completed. And putting the onus for writing the code on the caller, of which there are potentially many, instead of in the callee, of which there are a handful if any, just seems absolutely crazy to me. Even though I seem to be a lone voice in this....@JonB said in GUI event blocking:
@ambershark
Well, the principle is exactly the same regardless of whether one has dialogs, windows, widgets or whatever. It's that I don't want re-entrancy when a button/other input element is clicked, till whatever code it executes has completed. And putting the onus for writing the code on the caller, of which there are potentially many, instead of in the callee, of which there are a handful if any, just seems absolutely crazy to me. Even though I seem to be a lone voice in this....That is exactly how it works. You just happen to be invoking asynchronous code so it is telling the caller that it is "done" before it actually is. I still feel the easiest way to deal with this is to show progress and shut down reentrance to the GUI functions that should be locked during processing.
I actually have an "ActionManager" class I use for this purpose in async areas of my guis. It basically just manages the whole gui so I can say something like
myActionManager->disableSet(mySetofActions).. And that will disable everything in that set while my gui processes.Along those lines I still feel just a popped up modal "progress dialog" would completely protect you and stop all GUI processing until you told the progress dialog you were done and to close.
I mean you could even go with the awful idea of a global variable that tells when to allow entrance to a gui function and when to not.
My L-GPL'd C++ Logger github.com/ambershark-mike/sharklog
-
@JonB said in GUI event blocking:
@ambershark
Well, the principle is exactly the same regardless of whether one has dialogs, windows, widgets or whatever. It's that I don't want re-entrancy when a button/other input element is clicked, till whatever code it executes has completed. And putting the onus for writing the code on the caller, of which there are potentially many, instead of in the callee, of which there are a handful if any, just seems absolutely crazy to me. Even though I seem to be a lone voice in this....That is exactly how it works. You just happen to be invoking asynchronous code so it is telling the caller that it is "done" before it actually is. I still feel the easiest way to deal with this is to show progress and shut down reentrance to the GUI functions that should be locked during processing.
I actually have an "ActionManager" class I use for this purpose in async areas of my guis. It basically just manages the whole gui so I can say something like
myActionManager->disableSet(mySetofActions).. And that will disable everything in that set while my gui processes.Along those lines I still feel just a popped up modal "progress dialog" would completely protect you and stop all GUI processing until you told the progress dialog you were done and to close.
I mean you could even go with the awful idea of a global variable that tells when to allow entrance to a gui function and when to not.
@ambershark
Thanks. But in a word, this approach relies on knowing which buttons will end up invoking something which creates a thread or processes the event loop. For the hundreds of buttons I have, I want a solution where it works for all of them, given that they have no idea what the code they invoke might, might, might do. For example, this whole business of producing PDF worked fine with QWebKit without any asynchronicity/re-entrancy, and broke once it moved to QWebEngine, which is invoked way down in the code far away from the button. I had no way of knowing I ought to be looking at various buttons' code in this light, and I do not want to have to change code relating to every single button in the interface. -
@ambershark
Thanks. But in a word, this approach relies on knowing which buttons will end up invoking something which creates a thread or processes the event loop. For the hundreds of buttons I have, I want a solution where it works for all of them, given that they have no idea what the code they invoke might, might, might do. For example, this whole business of producing PDF worked fine with QWebKit without any asynchronicity/re-entrancy, and broke once it moved to QWebEngine, which is invoked way down in the code far away from the button. I had no way of knowing I ought to be looking at various buttons' code in this light, and I do not want to have to change code relating to every single button in the interface.@JonB Oh I get it now... You changed webkit to webengine and that caused these issues.
Now I understand why you keep talking about all these buttons in your app. It's because the app was fundamentally changed by replacing a technology. So it's not as easy as replacing your async places with progress dialogs since you don't necessarily know where all those places are.
That is a nasty thing to deal with. I wish you luck, lol.
