[Solved] "Lock" the UI while waiting on an async event?

reactive

Gah! That didn't work. It seems that moving the mouse to the text edit component right above the button and then back down and clicking is sufficient to outsmart the filter. :(

EDIT: I figured out the cause! Clicking on the button and not releasing and then moving the mouse outside the button. I don't even have to release the mouse button. Just moving it outside fires the signal. Now to fix it...

andre

Wouldn't it make sense to simply disable all controls if you don't want them active?

Otherwise, you might look into invoking blockSignals() on your button. That should stop it from emitting any signal.

giesbert

locking the widgets is one thing (perhaps just disable main window?)
what about close event etc? Are this also disabled then?

reactive

Unfortunately it's not a trivial GUI with just a couple of static widgets. There are many nested pieces full of widgets that change with time. Many user actions must wait on a server response message that could take (uncomfortably) many seconds to come back. I really didn't want to blank out the screen or display a modal "waiting..." dialog for that long, but I would like to defend against impatient mouse clickers and button mashers.

I'm new to Qt so I have no idea what the best way to do this. I'm only trying the eventFilter way because that's the response I got. blockSignals() sounds good but I'd have to traverse the whole layout tree and do it on everything which doesnt sound appealing.

Gerolf, what did you mean by "disabling" the main window?

andre

Well, applying it to all buttons at least should be easy enough:

@
//mainWindow is a pointer to the widget that represents your ui widget

QList<QAbstractButton*> buttons = mainWindow.findChildren<QAbstractButton*>();
foreach(QAbstractButton* button, buttons)
button->blockSignals(true);
@

I think Gerolf was talking about this:
@
mainWindows->setEnabled(false);
@

reactive

SON OF A...! :)
mainWindow->setEnabled(false) was EXACTLY what I was looking for. Thanks so much.

Going back to that "glitch" for a moment, is that behavior a bug?
Clicking on a button without release and then moving outside the button while still
holding the button down, should not fire. In fact, in most cases isn't this exactly how
you cancel an accidental press.
I've never seen that type of behavior on any platform.

andre

OK, that's good. I marked the issue as "Solved".

I hope you did notice that the setEnabled() call also modifies the visual appearance of your application? I hope that is what you intended? Personally, I like it when I can see that clicking won't have an effect, but that wasn't too clear from your use case.

I think Qt normally won't fire a clicked() signal if you move the mouse off a button before releasing. If it does, I would considder that a bug, but perhaps it was caused by your own event filter (blocking a focus out, perhaps?)

ZapB

Apologies, I thought that you wanted the widgets left enabled otherwise I would have suggested that. My bad.

reactive

modifies the visual appearance of your application

TBH, I wanted to block for X seconds without a different visual appearance, and then
after a timeout then go to the disabled look. I'm not going to be choosy though!
The eventFilter() solution was almost perfect, but reliable code is more important.

Apparently, that unwanted button behavior happens when you consume mouse press and
mouse release (but not either alone). Another mark against the eventFilter method is that
if you right-click in a text box and popup displays that locks up the app for good.

Apologies... My bad

No way. Thanks for the help. It would have been a great solution without that one hiccup.

ZapB

You also have to block QEvent::ContextMenu event types to stop context menus appearing.

So can you only consume MousePress but not MouseRelease?

reactive

So can you only consume MousePress but not MouseRelease?

Well, the text box cursors move on mouse presses and the popup menu appears
on mouse release (in a text box) - so somehow text boxes are getting around
the mouse event filter.

I can't even guess at the button behavior, but it must somehow still knows you're clicking on it too.