Re: [win32gui] [perl-win32-gui-hackers] Commit

[Robert M. <rm...@po...>]

Jeremy White wrote:
>> Have you tried this?  It's sort of equivalent to
>>
>> }
>>   my $mw;
>>   $mw = Win32::GUI::Window->new(
>>     ...
>>     -onTerminate => sub { undef $mw },
>>   );
>> }
>>
>> Which uses a closure to stop $mw's ref count going to zero at the end 
>> of the enclosing block, but forces it to zero in the onTerminate handler.
> 
> 
> Humm - I've just had a bit of a play, and I am not convinced the window 
> destruction logic is correct. Under the hood a window is both an object 
> and a tied hash ref right? Could it be the case that we're destroying 
> one and not the other?

Ah.  I've come across this problem too when trying to add my own DESTROY 
method to a subclass of a Win32::GUI window/control object.

There's definitely some nastiness lurking in the way that the object is 
tied to Win32::GUI::WindowProps.  I couldn't quite get my head round it 
when I last looked there, but the DESTROY method gets called twice, with 
different objects (try print $self; within the DESTROY method).  I 
*think* there are actually 2 perl objects created for each window;  but 
as I said I never got to the bottom of the logic to my satisfaction.

When I last looked at this I thought that the best solution would be to 
remove the tied mechanism altogether - there's not much functionality 
added;  besides we should not be encouraging people to access the object 
hashes directly - it's not very 00.  But I haven't found the time to 
look at exactly how much functionality would be lost, and how hard it 
would be to add that functionality back using a more traditional 
approach (if indeed it is possible at all).

Rob.