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.
Nice. I hadn't thought of holding a separate reference to the userdata,
and so avoiding the circular references. I think we may still see problems
with the reference causing 'late destruction' in some cases, but I could be
wrong (I still can't really get my head round the way objects are tied,
resulting in more than one call to the classes DESTROY method).
It does need more testing, and no doubt issues will crop up. 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('');
}
It would be nice to have tests for everything we add, and we should
certainly try going forward. There are some things I just don't know how
to test yet. I'd like to encourage everyone to put tests into the test
directory - I've not really got a naming scheme yet, but think something
will become obvious once we see some more contributions. For methods, I
started numbering at 50, with test names XX_Classname_Methodname.t, but
don't know if this will hold up or not.
Ok - I'll add these scripts later. Does anyone know a way to test for memory
leaks?
Cheers,
jez.
