—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
Interesting, this (or very similar) bug was supposed to have been fixed relatively recently, see #10924. I am not sure why the fix there doesn't work in your case, please try to debug it if you can and/or please make the smallest possible patch to the MDI sample allowing to reproduce it. TIA!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
I've just run into the same problem using a wxListBox (wxWidgets-3.2.5).
Double-clicking the listbox when its containing dialog is over another window results in the background window getting a spurious wxEVT_LEFT_UP (which then causes havoc in my application). I tried to process the wxEVT_LEFT_UP in the dialog, but the event seems to be generated after the dialog is already dismissed...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
I placed DrainMouseMessages from #23944 after the dialog completes (and wx object deleted).
However, the event is propagated into the background window before the dialog processing returns, so that doesn't work.
Only works if I DrainMouseMessages in the dialog's double-click handler...
Hope that helps fix this,
Best Regards, Dave
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
Before the fix in #23944, I was using this simple workaround, which may help you solve the havoc from spurious events in the background window in the short term.
Perhaps there will be some clues as to why #23944 is not working in this case from inspecting the MSG and return values from PeekMessage within DrainMouseMessages.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
Thanks @charvey2718, but in my case the window receiving the spurious events (in back of the dialog) is 3rd-party code, so much more difficult to intercept the spurious event. This is a generic problem with Windows dialogs and would best be handled within the wxWidgets message queue processing, no? Not in a specific dialog handler like wxFileDialog? Also it likely applies to (less common) right-double-click etc. Thoughts?
Thanks again,
Best Regards, Dave
PS: peekMessage sometimes doesn't see the spurious events in the locations I've tried; I don't know when/where these events get routed...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
Problem noted above is also generic (to all dialogs): #10924
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()