| [ Return to Bugs & Features | Roadmap 1.1 | SVN ⇄ GIT ]
STR #181
Application: | FLTK Library |
Status: | 1 - Closed w/Resolution |
Priority: | 5 - Critical, e.g. nothing working at all |
Scope: | 3 - Applies to all machines and operating systems |
Subsystem: | Core Library |
Summary: | Crash, when destryoing widgets |
Version: | 1.1.4 |
Created By: | AlbrechtS |
Assigned To: | mike |
Fix Version: | 1.1.5rc1 |
Update Notification: | |
Trouble Report Files:
Trouble Report Comments:
|
#1 | AlbrechtS 06:29 Oct 13, 2003 |
| When destroying widgets, it may sometimes happen that a crash occurs within FLTK. I tracked it down to, e.g. Fl_Input_.cxx, where the windows cursor is being modified on an FL_LEAVE event:
int Fl_Input_::handletext(int event, int X, int Y, int W, int H) { switch (event) {
...
case FL_LEAVE: if (active_r()) window()->cursor(FL_CURSOR_DEFAULT); return 1;
However, window() may return a NULL pointer, if the widget or a parent group has been remove()d before.
Note: there are many more widgets with code like this.
I know of two solutions, but don't know the correct/best way:
(1) modify all relevant lines to be like:
if (active_r()) if (window()) window()->cursor(FL_CURSOR_DEFAULT);
(2) modify Fl_Widget::active_r() to return true only if one of the parents of the widget is a window:
int Fl_Widget::active_r() const { int found_window = 0; for (const Fl_Widget* o = this; o; o = o->parent()) { if (o->type() >= 0xF0) found_window = 1; // HACK: FL_WINDOW = 0xF0, see Fl_Window.cxx if (!o->active()) return 0; } return found_window; }
Note: (2) would modify the functionality of active_r(), but IMHO in a consistant way.
Albrecht Schloßer
P.S. Sorry, if some lines wrap.
| |
|
#2 | gyohng.netscape 03:20 Oct 21, 2003 |
| Could be related to http://www.fltk.org/str.php?L177
When a widget is destroyed, window class may sometimes override the behavior. | |
|
#3 | mike 17:05 Oct 31, 2003 |
| OK, I've updated the four widgets that are affected; the problem only occurs when the cursor is changed in response to FL_LEAVE events.
The problem is not at all related to STR #177. | |
[ Return to Bugs & Features ]
|
| |