> 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