| [ Return to Bugs & Features | Roadmap 1.1 | SVN ⇄ GIT ]
STR #1521
Application: | FLTK Library |
Status: | 1 - Closed w/Resolution |
Priority: | 4 - High, e.g. key functionality not working |
Scope: | 3 - Applies to all machines and operating systems |
Subsystem: | Core Library |
Summary: | Wild and crazy event dispatching |
Version: | 1.1-current |
Created By: | wilson.afn |
Assigned To: | matt |
Fix Version: | 1.1-current (SVN: v5607) |
Update Notification: | |
Trouble Report Files:
|
#1 | wilson.afn 08:06 Nov 30, 2006 |
| foo.zip 1k | |
Trouble Report Comments:
|
#1 | wilson.afn 08:06 Nov 30, 2006 |
| """A "modal" window, when shown(), will prevent any events from being delivered to other windows in the same program...""" seems to be currently false.
I was surprised when my supposedly anesthetized main window, laying on the operating table, chest open, and connected to a heart-lung machine arose in response to FL_MOUSEWHEEL events!
Test code (attached) demonstrates that modal windows leak events: FL_NO_EVENTS are understandable; even my unconcious window can handle those. When the cursor is in the normal window, FL_KEYDOWN events go to the modal window, but FL_KEYUP are dispatched to the normal one. Sure enough, FL_MOUSEWHEEL events are likewise delivered to the normal window.
FC6, all yummed up. GCC 4.1.1 | |
|
#2 | matt 02:44 Jan 18, 2007 |
| Fixed in Subversion repository.
Mousewheel events are now no longer propagated to the original widget if a modal window is up.
KEYUP events are now sent to the widget that has focus. If the user pressed the arrow key and moved focus, this may be a different widget than the one that received the corresponding KEYDOWN event. Fixing this would require extensive logging of all keyboard events and verification of the existence of widgets. But it sure beats sending KEYUPs at whatever widget is first in the list ;-) | |
|
#3 | matt 02:45 Jan 18, 2007 |
| PS: please don't post .zip file. Just post two text files instead.
PPS: I added the eventnames.h file to the SVN. Thanks, Greg! Maybe we should just call it "names.h" and add all the text representations of predefined values like colors, boxtypes, etc.? | |
[ Return to Bugs & Features ]
|
| |