>What you have with AEVENTS() works and it's all we have apart from calling separate methods for each. I think I would personally rather call separate methods for each and bypass the overhead of wasting processing time requesting that VFP create and populate an array with information we'll almost always need to know anyway.

Definately agree with the above, but

>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). Since we have no choice but to call AEVENTS() explicitly to obtain even the object/property causing the event, then there should also be no reason why we couldn't have passed additional parameters to the BINDEVENT() definition in the first place, which are then also returned in the array as additional columns after the explicit call.

would slow ALL such extended processing of bound events down. My guess is the "naked bindevent" was targeted for performance reasons - and there are scenarios where the embolded assumption is untrue. Adding more overhead to AEvents() IMO would be falling in the trap of bad design (god method) as well. Offering more special functions IMO would be much better here as well.