| | [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #1873
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| Priority: | 4 - High, e.g. key functionality not working |
|---|
| Scope: | 2 - Specific to an operating system |
|---|
| Subsystem: | Core Library |
|---|
| Summary: | more fl_ask issues |
|---|
| Version: | 1.3-current |
|---|
| Created By: | wavexx |
|---|
| Assigned To: | fabien |
|---|
| Fix Version: | 1.3-current |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #1 | wavexx
13:31 Feb 14, 2008 |
| There are some weird issues going on when fl_ask (&family) is being used. It is possible to make an application crash when fl_ask is used in callbacks.
I was able to track a crash down to a simple test case while debugging another str. It crashes on OSX, but may apply to others. | |
| |
| #2 | wavexx
11:04 Feb 18, 2008 |
| This is a nasty one.
1: window is shown, focus goes to Fl_Input
2: press ESC, default_atclose calls hide()
3: hide() fixes focus, calling FL_LEAVE
4: FL_LEAVE causes Fl_Input to generate its callback
5: now enter the fl_ask's innards, re-entering Fl::wait
6: move the mouse over the main window
7: motion event is delivered to the window, which has "i" set to 0 to avoid drawing
8: watch it die!
In general, it's true that FL_HIDE should _not_ draw to the window, however I think we must not remove the xid handler until all events have been dispatched. It is possible that, during recursive behavior, other events gets generated. I don't think checking shown() for every callback ever made is a good idea.
This basically requires to move "i = 0" from Fl.cxx:935 to somewhere after Fl.cxx:956:handle(FL_HIDE);. This would also remove the need of the invasive cursor handling stuff in this function, that could be moved in the respective widget's FL_HIDE code.
SVN reveals this code is pretty old, so I'm unsure about the requirement of having "i = 0;" set as soon. Any comment?
I'm attaching a patch that fixes the recursive events sent to dying windows on carbon. It seems that the default carbon handler already checked for this, but not the mouse/activation/wheel handler.
The patch fixes THIS issue, but I strongly suggest to revisit this behavior. | |
| |
| #3 | matt
10:19 Feb 20, 2008 |
| This bug was pushed up from 1.1 . Even though the patch was applied and fixes the immediate problem, a better, more general solution must be found. IMHO, xid=0 should not be done until required. However, an existing xid (and theassociated window) also means that more event can be received.
Anyway, this needs some review. | |
| |
| #4 | fabien
10:31 Oct 04, 2008 |
| Is it still crashing in latest svn ?
I tried to reproduce the bug but didn't succeed under osx quartz. | |
| |
| #5 | fabien
01:57 Nov 07, 2008 |
| I reviewed that one twice and didn't find any crash situation, following the mentioned test case, again. | |
[ Return to Bugs & Features ]
|
| |
