A mouse click ending up in wrong window(?)

Development Third-Party
1

I’ve encountered a bit of a puzzling bug with CapitalBe. If you want to set the date for a new transaction by clicking the calendar button, a borderless window opens with a calendar view similar to the one when clicking on the clock in the Deskbar. Now, when you doubleclick a date, the date gets inserted into the date-box of the new transaction and the calender window is closed.

Now the bug: a click from the doubleclick into the calender window finds its way to the window beneath it that shows a list of all transactions, selecting the ‘accidentally’ clicked on transaction (which leads to its date being inserted into the to be created transaction, replacing the date picked from the calendar just before).

How does the click triggering the date-selection in the calendar window end up in the main window with the transactions list? Shouldn’t the clicks be swallowed by the calendar window?

I created a PR ( Avoid stray mouse-click after choosing date with calendar by humdingerb · Pull Request #133 · HaikuArchives/CapitalBe · GitHub ) that originally simply snoozed for 1/5 s before closing the window. That solved the issue.

(@korli suggested to send the message with the new date (fInvocationMessage) sychronously, i.e. the closing of the calender window will wait until the new date’s inserted in the new transaction’s date-box. This didn’t solve the issue, probably because it’s just too fast to accomplish whatever the “snooze” accomplishes.)

Anyone got an idea? It’s a behaviour I haven’t seen anywhere else…

2

On a QEmu VM, I would suspect the second mouse device (It is impossible to remove the PS/2 mouse automatically inserted by the emu.) but, I guess you’re on bare metal…
Could it be that the window with the list is somehow stealing the focus and so ends up being clicked?

3

Yeah, no VM here.

Now that’s the question… It is weird. You doubleclick a date. The invokation message reaches the CalendarWindow’s MessageReceived(). From there a message with the date’s data is sent to the calendar widget that’s doing its thing to fill in the new date into the transaction etc. When it’s done it sends back the reply message to the calendar window. Now the CalendarWindow gets quit, the main window gets back the focus…. and somehow a click from the double-click on the CalendarWindow tunnels through the quantum foam from the past to register in the transaction list of the main window now. :exploding_head:

4

Is it possible that only the mouse button up is received by the parent window, and that this event triggers the selection?

5

Quite possible. When I doubleclick on a date, but don’t let go of the mousebutton on the second click, the date gets chosen, and the calender window closes. Then, when I let go of the mouse button, the transaction under the pointer is selected.

Question is, is that expected behaviour? If so, how best to fix that? Can I somehow kill the mouse-up from the queue? Or is the very easy “fix“ of snoozing for a few msec acceptable?

6

In what situation could this be wanted behaviour? For a longer click, this could be a drag event.

However, it would be interesting, if the final window just receives a mouse up, or also a mouse clicked event. I would argue that the latter would be a bug that should be fixed in the app_server.

I don’t think waiting is a good way of working around this issue. You could notify the window or view to ignore the next up or clicked event in this case.

7

keep the calendar open until it receives the “mouse up” event? That will make sure the event is not reaching another window, and no arbitrary “snooze” will be needed.

8

A solution, though it seems to be quite some of effort - creating my own BCalendarView to override MouseUp() (and KeyDown() because you could keyboard-navigate and use RETURN to choose a date). All to work around something Axel rightly wonders:

Should the invokation message get sent on the mouse-up instead? Anyone confident enough to change that and let us test what sideeffects that’ll have… :slight_smile:

I dimly remember something about BListView got a change to react to MouseUp instead of MouseDown. So if I remember right (big if…) that stray MouseUp wouldn’t have been a problem in the past…

9

I meant fixing BCalendar to do that.

Personally I’m very happy to see things happen on mouse up as it allows to “cancel” a click by moving your mouse out of the button before releasing. But there will be people arguing that it adds a few milliseconds of delay and noticeably slows them down.

2 Likes
10

Me too, I was about to mention that IMO advantage myself. And in this case of doubleclicking there isn’t even a perceivable delay.

Oh, right. Though I have to say after a quick look, I don’t feel up to that… How do you trigger the BCalendarView::Invoke() on MouseUp of the doubleclick (instead of MouseDown as I assume it is now)?

Or would you put the sending of the message into MouseUp() (and KeyDown())?

I fear I’d waste people’s time having to slowly guide me to the solution… :slight_smile:

11

Hold on… Or do you just change “MouseDown()” to “MouseUp()”… :slight_smile:

I’d have to see how to test that change…

ETA: I’ve put just the double-click handling into a new MouseUp(). Though, after compiling libbe.so and putting it alongside CapitalBe in a “lib” folder, I still see the same behaviour. According to listimage, CapitalBe is using the new new libbe.so…

12

I’m often arguing for latency, but this is just the wrong thing to optimize for this.

We should use MouseUp normally exactly for what you mentioned (and to easily distinquish a click from a drag in situations)

1 Like