>>>Since you can't pass parameters I think you'll have no choice but to implement a different method for it.
>>I've used aevents and it worked (the second element showed the property name).
>
>
>I'm glad it's working. Someone pointed that out on Foxite this morning (using AEVENTS() to obtain the source causing the event).
>
>-----
>The following is a bit of commentary not directed at you, Naomi, as I know you're a seeker looking for a solution. That is a most excellent thing to be, by the way, and when you find the solution that works I know you're happy and able to complete your work.
>
>But as for me, as a low-level system designer working on a product like Visual FreePro, I must direct these thoughts and this general feeling of angst and frustration toward Microsoft and the VFP designers regarding this "incomplete feature" they've given the VFP community, and in such a limiting way:
>
>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.
>
>It seems the VFP designers stopped short of doing it right, and were either on their way to doing it right in the next implementation in VFP10 (unlikely), or (I believe far, far more likely) were purposefully limiting this functionality to only then expose some of what would be needed in a proper design through this call to AEVENTS() as a way to appease the hard core Fox gurus who requested similar functionality. Again, I believe this stems back to the fact that Microsoft ultimately had to kill VFP because it was too powerful and would've taken business away from SQL Server and .NET, which was their plan for the future.
>
>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. At least by calling different methods you know what the trigger was, and you can know what parameters you need and would've passed had you been able to.
>
>VFP could've been so much more than it was. It was throttled in the extreme. And most people don't even realize this because they're not low-level system designers, but are developers writing code in VFP, rather than doing something like writing VFP. What Microsoft did with VFP was criminal. It was agenda-driven. And there are literally hundreds of thousands of VFP developers who were caught in the cross-fire of their agenda to move to .NET and SQL Server when such a move was not necessary.
>
>The VFP community is being pushed, bullied even, into the place Microsoft wants them to go. Unless we band together and work on a product like Visual FreePro, putting our developmental efforts into it ... it's all we're going to ever have.
>
>*SIGH!!*

Rick!
Wow that was a long and frustrating story. It just entered my mind: do you still have VFP installed on one of your pc's? If you tell me that you have meanwhile deleted all the VFP s*t I can understand after this extensive essay.
For such a talented low level programmer which such high skills I am sure there are lots of other products around on the market which do not have all those disadvantages you are able to produce about VFP.
Keep the spirit up old man.
Regards,
Koen