>>>I think it's a bad design in VFP that such an explicit call (AEVENTS()) is required when
>>>the same information (and more) is very likely almost always needed (along with
>>>some user-defined parameters being passed as per a custom basis).
>>
>>As someone who has used BindEvent() extensively, I disagree. I find that I rarely
>>need to know which object triggered the call. If you look back at my presentation,
>>I think you'll see that out of all my BindEvent() examples, only two or three call
>>AEVENTS().
>
>
>I think not knowing what a person doesn't have prevents them from realizing what's possible were it easily available.

No, it's no hardship to call AEVENTS() when I need it (and it offers me more than just the details of the binding that got me to the current point). Having the binding details as parameters would remove one of the very elegant things about BindEvent(), the fact that the delegate method receives exactly the same parameters as the bound event.

If the information weren't available at all, you'd have a point. Having to make a function call is just no big deal, especially since I need to do so less than half the time that I use BindEvent().

Tamar