> 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($@);
this is very pretty (esp. the sneaky closure at the beginning!! trez cool!)
I'll give that a try when I go back to my other machine later today... I still
can't help but say "it shouldn't take cool and sneaky tricks to accomplish
this...". :-)
> 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.
Hmmm... I was probably assuming too much. I haven't looked at that code, but I
assumed that the widget that was being manipulated would 'intuitively' know
about
itself, and thus events involving that widget could easily send the widget-ref
to
the callback... unless the widget-event and the widget are somehow "separated"
(e.g. if the event triggered is based on global mouse-coordinates, rather than
being triggered from within the widget... ugh!)
Anyway, your code example is really sweet! I think between your example, and
Morbus' global hash-ref-trash-can idea I can work around the problems that I
have
had so far.
Thanks guys!
Mark