FS#1725 — Mouse events being treated twice
Attached to Project— OpenTTD
Opened by Chidambar Zinnoury (illogict) - Wednesday, 30 January 2008, 10:44AM
Opened by Chidambar Zinnoury (illogict) - Wednesday, 30 January 2008, 10:44AM
| Patch | |
| User Interface | |
| New | |
| No-one | |
| All |
| High | |
| Normal | |
| Devel (specify rev) | |
| Undecided | |
| Undecided | |
 |
Hello!
While porting for Maemo, I observed that some mouse events were treated twice. In fact, video subparts generate an event and thus call HandleMouseEvents themselves, but HandleMouseEvents is also called in InputLoop, thus leading to mouse events being treated twice in race conditions. This patch will remove the call in InputLoop.
Please comment.
Patch is against r12018.
twice_treated_mouse_events.patch
While porting for Maemo, I observed that some mouse events were treated twice. In fact, video subparts generate an event and thus call HandleMouseEvents themselves, but HandleMouseEvents is also called in InputLoop, thus leading to mouse events being treated twice in race conditions. This patch will remove the call in InputLoop.
Please comment.
Patch is against r12018.
twice_treated_mouse_events.patch
This task depends upon
This task blocks these from closing
A side effect of the patch : when you click on the patches configuration window's [< >] buttons, the clicked button does not get raised unless you actually take your mouse pointer out of the way.
A bit not really wanted pattern, i might say...
Maybe there might be other ways to achieve your goal.
Ok, I've understood the problem. So here is an updated version of the patch.
As for scrolling, now HandleMouseEvents will not be called in InputLoop unless there were no InputEvents during the tick.
Please comment.