GUI event blocking

kshegunov

The problem is, my produceReportAndWaitForFinish() in the top-level dialog does not have any kind of
[snip]
inside it (and I don't want it to). It has more like:

This is of no consequence, I've put the event loop/QWebEngineView here only for completeness. You can connect the grab/release slots directly from the button/custom class that generates the pdf respectively. Basically, the same as what you have now, but including 1 event override and putting in the grabMouse and releaseMouse at the appropriate places.

JonB

@kshegunov
Hmm, so you mean in my dialog button:

blockInputs()
ReportProducer rp;
rp.doWhateverToProduceHtmlAndPdf()
releaseInputs()

Right?

kshegunov

Yep, that should work.

JonB

@kshegunov
So, to be pedantic, and hoping I'm not annoying you, I want precisely that code/behaviour wrapped around every single button handler I have anywhere in my code, just in case the code the button invokes happens to create a thread or process events which could cause re-entrance. Which was the reason I posted this thread in the very first place.

There is supposed to be nothing special about my doWhateverToProduceHtmlAndPdf(), it's a complete accident/coincidence that it happens to use something (a QWebEngineView) which itself has to spin an event loop to achieve its work. I might change that tomorrow. Which is why I wanted to isolate anything about its event behaviour down inside the class which creates the QWebEngineView and not up at the caller dialog level. This approach will work in this particular case, but not in other random places in code where a button's actions might happen to spin an event loop, and that bothers me....

Ah well, such are the dirty practicalities of coding...!

EDIT: Bear with me, I'm going to post a new thread to ask a particular question which would satisfy me, just to know if it's possible.... See https://forum.qt.io/topic/88481/is-it-possible-to-intercept-a-modal-dialog-s-event-loop

kshegunov

@JonB said in GUI event blocking:

This approach will work in this particular case, but not in other random places in code where a button's actions might happen to spin an event loop, and that bothers me....

You could in principle adapt it to the general case. Something along:

class UiGuard : public QObject
{
public:
    UiGuard(QWidget * ui)
        : widget(ui)
    {
        widget->grabMouse();
        widget->grabKeyboard();
        widget->installEventFilter(this);
    }

    UiGuard::~UiGuard() override
    {
        widget->releaseKeyboard();
        widget->releaseMouse();
    }

    bool eventFilter(QObject *, QEvent * event) override
    {
        return dynamic_cast<QInputEvent *>(event);  // Eat up the input events
    }

private:
    QWidget * widget;
};

And then you use in the places you have threads and/or event loops spinning, by just creating an instance:

// ...
{
    UiGuard guard(this);  // Prevent input events while in this method
    ReportProducer rp;
    rp.doWhateverToProduceHtmlAndPdf()
}

JonB

@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! :)

kshegunov

@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 the QCoreApplication object (with the proper modification), where you'd filter the events globally, but seems rather dubious decision.

JonB

@kshegunov

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....

kshegunov

@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. :)

JonB

@kshegunov
Of course you must, and get back to fixing those nuclear reactors/missiles you work on :) Thanks so much for your comments!

ambershark

@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. :)

JonB

@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

@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.

JonB

@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

@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.

JonB

@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

@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.