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.