wxTipWindow mostly ignores BoundingRect

[wsu-cb]

Description

Bug description:

The wxTipWindow is not fully respecting its bounding rectangle.

Expected vs observed behaviour:

The wxTipWindow constructor has a (optional) rectBounds argument.

Expected: If the mouse leaves the rectBounds area, the wxTipWindow is supposed to close.

Observed: If the mouse leaves rectBounds but does not enter the wxTipWindow, the wxTipWindow does not close.

Patch or snippet allowing to reproduce the problem:

wxTipWindow-BoundingRect-bug.patch

To Reproduce:

Steps to reproduce the behaviour

1. Apply the attached patch and run the dialogs sample
2. Move the mouse cursor to roughly the middle of the dialogs sample
3. Hit Ctrl+Shift+H to open the wxTipWindow
4. The patch is written to set the rectBounds to the wxSize(5, 5) square around the initial cursor position. Move the cursor AWAY from the displayed wxTipWindow so that it leaves the initial wxSize(5, 5) square. No matter how far away the mouse is moved from its initial position, the wxTipWindow stays open.
5. Now move the cursor over the wxTipWindow. The wxTipWindow closes.

The problem is that there is a wxEVT_MOTION handler in the wxTipWindow that checks the rectBounds, but if the mouse is not over wxTipWindow, the handler is never called.

Platform and version information

• wxWidgets version: master ~ 2024/04/16
• wxWidgets port you use: wxMSW, but I'm pretty sure this is true for all ports
• OS and its version: Windows 10 22H2

[wsu-cb]

I tried to modify the wxTipWindow implementation to wxEventHandler::Bind() a wxEVT_MOTION handler to the constructor's passed-in parent window to work around the problem. However, I discovered that the dialogs sample actually passes the MyFrame pointer rather than the MyCanvas pointer as the wxTipWindow's parent. Since the MyFrame is largely covered by the MyCanvas, the MyFrame didn't receive any wxEVT_MOTION events either, so this workaround didn't help at all. Is passing MyCanvas instead of MyFrame as the wxTipWindow parent an additional bug, or is there some need to do that? A quick test of passing MyCanvas instead of MyFrame didn't show any problems, and allowed this workaround to succeed.

[vadz]

This is going to be tricky to fix because the only way to get mouse events when the mouse is not over the window is to capture it — but doing this will prevent the user from clicking on the other elements without closing the tip window first, which risks being inconvenient.

[paulcor]

the only way to get mouse events when the mouse is not over the window is to capture it

That's already what wxGTK does. But it won't work for wxMSW, as capture does not provide motion events outside of the capture window unless a button is down. AFAICT, the only way BoundingRect can work for wxMSW is if the "parent" is the window the rect is for, wxTipWindow can intercept mouse events from that window.

but doing this will prevent the user from clicking on the other elements without closing the tip window

Um, what? wxTipWindow is a wxPopupTransientWindow, it should close on any button or key press.

[vadz]

but doing this will prevent the user from clicking on the other elements without closing the tip window

Um, what? wxTipWindow is a wxPopupTransientWindow, it should close on any button or key press.

I was thinking about elements inside the window.

[paulcor]

I was thinking about elements inside the window.

By "window", do you mean the wxTipWindow? It doesn't have any elements.

[vadz]

Sorry, I somehow thought it could have buttons inside it but I confused it with something else.

Anyhow, the only ways to implement support for bounding rect in wxMSW that I see is to:

1. Forward all mouse events in all windows of the application to the currently shown tip window.
2. Use a timer and check if the mouse is still in the bounding rect.