Jeremy White wrote:
Just one comment here - if the parent doesn't have valid userdata,
should GetParent() return the hwnd, like most other calls do? Should
we be looking at extending/changing other api calls to return objects,
where such objects exist?
Both good questions and the honest answer is that I don't know:)
Personally I prefer using objects, but if we have methods that could
return either then it would mean that the user would have to test the
return value before each use.
I think that's good logic to use to say that a method should return
either object/undef or handle/undef, but never object/handle/undef.
In theory
you should be able to create a sell referencing window, which has no
global reference, with the window controlling when it's destroyed.
Something like this:
{#window constructor
my $win=create window;
#the window is stored within itself, and the ref count is increased and
wont be destroyed when
#the block is finished
$win->UserData($win);
}
onTerminateHandler
{
my $self=shift;
#Setting the userdata to a blank string causes the ref count to be
dropped on the window
#and therefore should kick in the destruction logic
$self->UserData('');
}
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.
Ok - I'll add these scripts later. Does anyone know a way to test for
memory leaks?
No idea how to test for memory leaks - it's such a hard problem that
there's a whole industry around making tools to do just that.
You'll find developer CVS is down for anything up to the next 36 hours
for maintenance.
Regards,
Rob.
