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.
