On 3/20/24 18:59 Gonzalo Garramuño wrote:

On 3/20/2024 2:26 PM, 'Albrecht Schlosser' via fltk.coredev wrote:

I'm glad you found the issue.

FTR: The only thing we could do in FLTK to prevent such kinds of errors
would be to make some of the protected members private but
Fl_Text_Display is such a "beast" that I wouldn't want to open that can
of worms.

I thought the same, and was about to suggest it.  But... you can have
multiple shared Fl_Text_Buffers or a single one used in one
Fl_Text_Display and you might want to delete them in the destructor
like I do.

I may misunderstand what you wrote above but I'd say it's the opposite:
you can have one (shared) Fl_Text_Buffer attached to multiple
Fl_Text_Displays at the same time.

Making the variables private would prevent you from deleting them.

Making the variables private would only prevent direct access to them.
If we did that we'd obviously have to provide read-only accessor methods
for whatever users might need and the existing methods to attach a text
buffer to and remove it from an Fl_Text_Display. Of course you could
still delete the Fl_Text_Buffer object but you'd have to maintain a kind
of reference counting yourself.

I think the best solution would be to document this with a note in the
buffer() function.

I agree.

--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/4e115110-1e76-4d43-87d1-84932482db13%40aljus.de.