>>>>Should be faster. It doesn't involve the whole expression evaluator, this is just the simper "get me a property value" mechanism.
>>>
>>>Then the rules from above do not change. Simpler in otherpropuser. Thanks for the hint.
>>
>>Well I'm not quite clear on what the rules are, but at least this way you can bind multiple properties to the same method, and the method would know the name and value of the property which changed. If you need something else, then I solved the problem you didn't have :).
>
>Oh, my problem is that I have method that needs the value from a property. What property is not fixed. The method is used independend of the change of the property. I have more changes then uses. And I have more time on the use then on the change, for that. That defines the rules - as less calls to EVAL or GETPEM as possible.
>
>You helped with the solution - by bringing up GETPEM. :)

I must say I still have not grokked your main intent and was tentatively visualizing a logger you can bind to a list of properties like Dragan hinted.
But you also repeatedly mentioned "A" property and speed - when I last timed in vfp6, _access & _assign method calls were quite fast, and in there you already have the value as parameter. And if your method needs to be fed by ***some*** properties, defining _assing methods should be easy, and perhaps a quick check whether that event in this situation should call your method is an easy call to a hash...

Sometimes you should give a broader pic (including numbers like # of properties to bind eventually and concurrently) to minimize the guesswork.
If you are really after a logger for timing, C is necessary most of the times. Been there, done that - back in fpw times and that fwk is harder to set up, but has less Heisenberg effects than coverage profiler.