On 05/29/12 19:26, David Currie wrote:
> Consider the following,
When you receive control back from Fl::run(), your program
is supposed to exit.
When you hit ESC, fltk has already deleted the widgets.
Doing the delete's outside the Fl::run() is redundant,
causing the undefined behavior; by that time, the pointers
are wild.
> Secondly, each example that I have seen has ONLY 1 window(++...).
> This code makes a window(++widgets) appear AND disappear.
> I would assume that it should clean up after itself CLEANLY (memory wise).
>
> It seems to me theoretically that each
>
> win = 0x93f0008 disp = 0x93f00b0 tbuff = 0x93f0350 sbuff = 0x93f07c0...Run...
> win = 0x93f0008 disp = 0x93f00b0 tbuff = 0x93f07c0 sbuff = 0x93f0350...Run...
> win = 0x947c308 disp = 0x947c3b0 tbuff = 0x93f0350 sbuff = 0x93f07c0...Run...
>
> should have the SAME VALUES.
The C library does not guarantee anything about pointer values
once they are freed, so make no assumptions about them being
reused exactly as they were.
> Also I see 1.3.1 is being touted for release.
> I STR'd Background colors in Fl_Text_Text_display + Underscore/Strike-thru
> recently.
(STR#2838)
Sounds like an RFE; we only address HIGH and CRITICAL priority
STRs when preping for a release.
> I know this is only one small part but I was wondering about the ABI breakage
> testing
> and/or inclusion results ?
My guess is it won't be addressed in the near term.
Also, Fl_Text_Editor is one of the most complex widgets we have,
so it will take some time to get to it.
I've noticed some odd bugs with the text editor wrt text selection
sometimes not working (I've seen this in fluid), but could never
pin it down.
I imagine we can address RFEs while fixing such bugs.
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
