STR #1521

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

Return to Bugs & Features | Roadmap 1.1 ]

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:

Receive EMails Don't Receive EMails

Trouble Report Files:


Name/Time/Date Filename/Size top right image
 
#1 wilson.afn
08:06 Nov 30, 2006
foo.zip
1k
 
bottom left image   bottom right image

Trouble Report Comments:


Name/Time/Date Text top right image
 
#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.?
 
bottom left image   bottom right image

Return to Bugs & Features ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2022 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.