Closing QFileDialog opens toolbar menu, on windows only. WTF.

Moschops

I have a docking window, with a context menu. One of the menu options opens a QFileDialog. Upon closing that QFileDialog, the right-click context menu from the toolbar (which is way over at the top of the screen) appears where the docks own context menu previously appeared. As if it were the context menu for the dock, and I'd right-clicked again immediately in the same place. Although I hadn't. Just closed the QFileDialog.

Only happens on Windows. Utterly stumped. Anyone have any ideas?

mrjj

Ok, that really sounds WTF :)

I have had odd issues using exec() from within a say MousePress in a dialog but
your case seems really different.

For test, you could new the QFileDialog and use
->show().
Just for test to see if it still does it.

Moschops

It's currently a QFileDialog being created on the heap with new (as I need to modify it a bit and the static functions don't give enough flexibility), although in an attempt to isolate the issue it doesn't have anything done to it. Created, exec(), delete. Hello toolbar menu, in the dock :(

If I skip the exec() stage and just create it and delete it, nothing happens, so that's something at least.

If I replace exec() with show(), it flashes up for a moment (presumably before then being deleted on the very next line of code), and then there is no toolbar menu popping up. So maybe I can come up with some workaround involving show() rather than exec().

mrjj

Hi
If you new
it then it should not go away when it runs out of scope?
(unless u call delete on it :)

If you use new + show() +
dia->setAttribute( Qt::WA_DeleteOnClose );

It might be a workaround. ?

Moschops

I think that is where it's heading. Sure would have been nice to know WTF was going on.

mrjj

@Moschops
Hi
the exec() is a (local) event loop.
So the main loop ( GUI thread) get the mousepress on
the menu. then a new message loop is started to handle the dialog.
The mouse released is in the old event loop.
Then we quit the exec(), old loop is back. it sends
MouseReleased. Something like that,

Moschops

But the mouse release was already used, so to speak; that's how the menu item was selected. I would expect the event handler that dealt with that mouse release not to pass it onwards...

Although if it were passing it onwards, the next object in the chain that would get it would be the main window, which does hold the toolbar. So is this simply the context menu not marking the event as accepted and kicking it onwards, up the chain?

mrjj

@Moschops said:

Well the MousePressed was used
But in that event handler, a new loop is started so
i think MouseReleased is not fired if u call exec()
but is send after exec() ends.
I could be wrong but exec() does mess up in event handlers.

Im not 100% sure what happens but I could get it to be strange
with a colordialog and left click in a other case.

But your case seems extra wtf ? :)

kshegunov

@Moschops
Can you provide some source code. Why do you create local dialogs on the heap? The stack works just as fine, and even better.

@mrjj

I have had odd issues using exec() from within a say MousePress in a dialog

Never had any issue with exec(), ever.

SeeLook

Hi
I had some issues with doing something from press or release events and my workaround is to emit signal from timer slot:

void mousePressEvent {
//..
  QTimer::singleShot (5, [=]{ emit mySignal (); });
//...
}