> 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



Reply via email to