At 10:55 2001-11-04 -0600, Mark Wilkinson wrote:
> > I say this because there appears to be **nothing** passed
> This isn't so.
well... an examination of @_ at the beginning of the event handling
subroutines
says it is so... nothing is *passed*
Ah. I was referring to your comment about using strict.
Some things are passed to some types of event handlers, but never the
window or control itself.
> What you need is an entry point to your window variables. From there you
> can access all the contained controls.
Window variables, yes, but other program variables (which may be required
by that
subroutine) no.
Ok, then take a look at the Singleton approach in TGL and Perl Oasis.
They use one singleton for each window, but you can have one "application"
singleton which contains the window objects and the rest of your
application logic.
Granted, Win32GUI handles this in its own way, by requiring that each
widget have
a "name", and that name becomes part of the name of the event-handling
subroutine... but... ugh! If I am dynamically generating multiple copies
of the
same widget (thus with the same name) how do I know which instance was
clicked if
the widget ref is not passed back to the event handler?
You don't do that. Empty your glass before you fill it.
If you create controls dynamically, you don't give them the same name. If
you create controls dynamically, you also create the event handlers
dynamically (probably they just call some other sub to do the actual
processing).
Example of creating a Click event handler that passes a certain object
($objControl) for each control to a single sub:
#Create the event handler
my $perlEvent = qq{
{
my \$obj = \$objControl; #Nice little closure
sub ::${name}_Click { #Adding new subs _will_ leak memory...
::mnuPopupSelect(\$obj);
}
}
};
eval $perlEvent; #...not to mention string eval
print "Error: $@" if($@);
(I have since learned that there are better ways than "eval STRING" to add
subs.)
Agreed... it isn't "all that bad", but it is limiting/frustrating
nonetheless...
especially given how simple it would be to add this functionality (i.e.
the widget
ref must be available inside of the widget code itself, deep in the guts of
Win32GUI, and thus be available to the code making the callback... so
there is no
obvious reason why it couldn't be passed...)
I thought so too but then I looked in the XS code. While it's obviously
doable (most things are), I'm not convinced it's a walk in the park.
/J
------ ---- --- -- -- -- - - - - -
Johan Lindström Boss Casinos
Sourcerer [EMAIL PROTECTED]
http://www.bahnhof.se/~johanl/
If the only tool you have is a hammer,
everything tends to look
like a nail
