-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I said I'd report when I know more, so here goes...
The problem isn't with DefWindowProc at all (in fact
DefWindowProc doesn't do anything except default handling -
duh!). My apologies for being misleading.
The memory usage in the task manager thingee is useful, but
inherently misleading. It isn't a cache allocation thing or anything
like that, again sorry for being misleading.
The problem is with the C-perl interface. The WindowMsgLoop
needs a good perl start, and end block:
dSP;
ENTER;
SAVETMPS;
....
FREETMPS;
LEAVE;
This is because it calls into the perl interpreter. The Dialog XSUB
doesn't need those blocks explicitly however because they are
added by xsubpp. However because the Dialog XSUB pretty much
never exits (and therefore calls FREETMPS) it accumulates TMPs.
There are (I believe) two ways to fix this:
1/ make the dialog XSUB return after processing one message,
and call it from perl like
while( Win32::GUI::Dialog() ) {
}
2/ give the Dialog XSUB an explicit block around the perl interpreter
calls it makes. I believe that this will work fine, but I haven't tested
it. I implemented (1) in my copy of win32::GUI.
NB:
It may be necessary to add blocks in other places (in fact I'm sure
of it), but this is the only problem I am aware of.
I can't create and distribute a patch on work time, but in my own
time (of which I have very little unfortunately) I will create a patch for
0.0.502, and send this to Aldo, if he so desires.
-----BEGIN PGP SIGNATURE-----
Version: N/A
iQA/AwUBOlsd7ZsRND2Z+TaWEQLI4ACfT9k/+/Lm84a6GAhfnF8sa91kBGEAoIXP
QULIwerislw19RYsRAihlTY+
=5seU
-----END PGP SIGNATURE-----
Sam Jacobson
R & D Manager / Software Engineer
Selective Communications
Ph +64 9 302 1142
www.selective.co.nz
