Re: Wx::Perl seems to be leaking memory

Hi,

A top level window is a Wx::Frame or a Wx::Dialog - or any class that 
derives from them. You can find which built in classes are top level 
windows from http://docs.wxwidgets.org/3.0/classwx_top_level_window.html

You don'thave to explicitly destroy children ( controls ) of your top 
level windows. A Wx::Panel is just a type of control - not a top level 
window.

Note that if you choose to make them so in their contstructors, top 
level windows can be children of other top level windows. In which case, 
destroying the parent will destroy all children too.

An approach that can be used in an application with many Wx::Frames is 
to add an EVT_CLOSE handler to your Wx::Frame derived class and have the 
frame call $self->Destroy in your EVT_CLOSE handler. That way whenever a 
frame is closed, it will be properly deleted during idle time.

Hope it helps.

Mark
On 11/05/2015 17:05, Steve Cookson wrote:
> Hi Mark,
>
> Thanks for this.  So the short answer was that I had indeed made a 
> fundamental error.  I should update PM.
>
> Maybe I knew all this once upon a time, but I had definitely forgotten 
> it long since!!  It explains why I had leaks all over the place.  Some 
> of which must have been quite big because of embedded scrolling photos 
> and other stuff.
>
> Can I just clarify what is meant by "toplevel".  I guess it means 
> anything that groups controls that you would normally expect to 
> disapear because of going out of scope: any Dialog, Panel or Frame 
> with children or indeed a tree of descendants.  Or does it just mean 
> the application main frame?
>
> And if a whole tree goes out of scope simultaneously, eg controls in 
> sizers on panels within panels in a dialog, is it enough to Destroy 
> the dialog?
>
> Thanks again,
>
> Regards,
>
> Steve.
>
> On 11/05/15 11:52, Mark Dootson wrote:
>> Hi,
>>
>> See 
>> http://docs.wxwidgets.org/3.0/classwx_window.html#a6bf0c5be864544d9ce0560087667b7fc
>>
>> details for wxWindow::Destroy.
>>
>> As you have determined, top level windows you create need to be 
>> destroyed with $win->Destroy;
>>
>> The C++ structure for a Wx::Frame contains a reference to the 
>> associated Perl SV. So that SV won't go away until the C++ structure 
>> is deleted - which will never happen until your event loop is running.
>>
>> Hope this helps.
>>
>> Mark
>>
>>
>> On 11/05/2015 14:32, Steve Cookson wrote:
>>> Hi Guys,
>>>
>>> I started to talk about this on Perl Monks, you may have seen it here:
>>>
>>> http://www.perlmonks.org/?node_id=1125580
>>>
>>> An anonymous monk posted some code that showed just about every call 
>>> to Wx leaking a scalar or two.  I've played about with the posted 
>>> code and there is a copy attached to this email.
>>>
>>> The main part of the code, here:
>>>
>>>         $count1 =  Devel::Leak::NoteSV($handle);
>>>         for(1..100){
>>>             my $f=Wx::Frame->new( undef ,-1,"goner" );
>>>             my $p=Wx::Panel->new (undef ,-1 );
>>>             #my $b=Wx::Button->new ( $f ,-1 );
>>>             #my $t=Wx::TextCtrl->new($f, -1, "");
>>>             #$t->Destroy;
>>>             #$b->Destroy;
>>>             #$i->Destroy;
>>>             $p->Destroy;
>>>             $f->Destroy;
>>>         }
>>>
>>>         $count2 =  Devel::Leak::CheckSV($handle);
>>>
>>> seems to show that if you do not ->Destroy a Wx object, it will not 
>>> go out of scope naturally and even if you do destroy a Wx::Frame 
>>> object, it will not go out of scope.  The monk also tried Weaken and 
>>> undef, with the same results.
>>>
>>> Please have a look at this and make sure that I have not (or the 
>>> Anonymous Monk has not), made some fundamental error.
>>>
>>> I have checked it both in 2.8.11 and 3.0.2 with the same results.
>>>
>>> I look forward to hearing your feedback,
>>>
>>> Regards
>>>
>>> Steve.
>>
>>
>