On Sun, 8 Aug 2021 14:29:13 +0200 Ichthyostega <p...@ichthyostega.de> wrote:Shouldn't then the last two lines be better swapped? I.e shouldn't we better call the clear() on the scroller first, which supposedly detaches all child elements?
Am 08.08.21 um 14:42 schrieb Will Godfrey:
That's what I thought when I wrote the vector based code, but like that, a second attempt to open the filer segfaulted. This is why I was concernedthat there's some interaction I didn't understand.
Wow... this is a good lead.
Just tried that out with the debugger: the Scroll indeed destroys the
attached elements already:
Thread #15 [yoshimi] 10622 [core: 6] (Suspended : Breakpoint)
FilerLine::~FilerLine() at /Werk/devel/a/yoshi/build/MasterUI.cpp:158
0x555555e726bc
FilerLine::~FilerLine() at /Werk/devel/a/yoshi/build/MasterUI.cpp:160
0x555555e7276e
Fl_Group::clear() at 0x7ffff7cfd1d0
Fl_Scroll::clear() at 0x7ffff7d22170
MasterUI::fillfiler() at /Werk/devel/a/yoshi/build/MasterUI.cpp:2.514
0x555555e7f0e9
MasterUI::filerselect() at /Werk/devel/a/yoshi/build/MasterUI.cpp:2.555
If we swap those two lines, i.e. if we already have deleted those objects
through the filerlist.clear(), then strange enough the filerscroll->clear()
does *not* invoke the dtor of the FilterLine objects again.
Which basically confirms your suspicion: we are probably approaching it the
wrong way. Moreover, a shared_ptr wouldn't help us either here; rather we should
just allocate new FilterLine objects, add them over into the Scroll and forget
about them.
-- Hermann
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Yoshimi-devel mailing list Yoshimi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
