Re: [fltk.bugs] [HIGH] STR #1894: Fl_Group::clear() accesses potentially deleted widget

DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L1894 Version: 1.3-current Please don't spam this specific STR with such considerations. Instead, discuss what you may not understand about fltk1.x memory management polici

Re: [fltk.bugs] [HIGH] STR #2004: 2 fixes for img->release() in Fl_Help_View.cxx

[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2004 Version: 1.3-current Fix Version: 1.3-current (r6169) Fixed in Subversion repository. Tested & Working on Mac OS X, WinXP, Linux. Thanks Mark and Seb, for your feedback and suggestions. Link: http://www.fltk.org/str.php?L2004

Re: [fltk.bugs] [HIGH] STR #1894: Fl_Group::clear() accesses potentially deleted widget

DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L1894 Version: 1.3-current If modifications to fltk's memory management are being contemplated, I'd suggest that it would also be nice if this program didn't crash (#includ

Re: [fltk.bugs] [HIGH] STR #1927: tool to modify all build environments in one go

DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L1927 Version: 1.3.0 I would consider as a first step to remove unusual compilers like old borland, watcom, visualc,vcnet that are not maintained anymore by their authors,

Re: [fltk.bugs] [HIGH] STR #1927: tool to modify all build environments in one go

DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L1927 Version: 1.3.0 I would consider as a first step to remove unusual compilers like old borland, watcom, visualc,vcnet that are not maintained anymore by their authors,

Re: [fltk.bugs] [HIGH] STR #1894: Fl_Group::clear() accesses potentially deleted widget

DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L1894 Version: 1.3-current I also think less (modifications) is better, especially in the fltk1.x branch. This is why I suggested first this idea of unregistering the paren

Re: [fltk.bugs] [HIGH] STR #1894: Fl_Group::clear() accesses potentially deleted widget

DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L1894 Version: 1.3-current Fabien, thanks for your comments. IMHO, your suggestion to remove a widget from its parent group in its destructor is the proper way to go. Meanw

Re: [fltk.bugs] [HIGH] STR #1894: Fl_Group::clear() accesses potentially deleted widget

DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L1894 Version: 1.3-current Wouldn't it be better to solve such problems to add in the the Widget destructor a parent remove() call so that the widget smoothly detach from i