>>>>I think that these methods fail because of a simple hard fact: there is no
>>>>built in automatic mechanism that watches the values of properties of
>>>>controls and notifies us. Each property takes care of itself internally,
>>>>and the people who designed those controls didn't think that we developers
>>>>need to automatically know when the value changes. If we want to know, we
>>>>have to check it ourselves. The timer method is not only (I believe) the
>>>>best method we have, but it is the published and standard method not only
>>>>in VFP, but in VB, and I suspect in other event-driven languages.
>>>
>>
>>>Since the timer has its drawbacks (like overhead, firing at wrong
>>>moments etc), this way is an alternative - it costs you only firing
>>>thisform.refresh when you want to see the controls changing value,
>>>caption, color or whatever, based on the value of any other control's
>>>property.
>>>
>>>(I'm not sure who originated this thread - probably it was Dan, but then
>>>my initials are DAN, so it's half mine - I just got curious). HTH to
>>>whoever needed this.
>>
>>
>>Renarto Bertuol is the Original Creator.
>>
>>This message if for Erik. Am I correct in assuming that when you are you using the timed event. Your having this timer fire once every 3 seconds for example. It would then call a procedure or method that would check these properties enabled or visible. If this is right, maybe you can answer the above comment about the drawbacks of the timed events.
>>
>>Dan
>
>
>Sure. Timers _can_ be a mess. In my implementations of this strategy, the timers fire once every .5 seconds. If you need a lot of code executed every time, this is a _lot_ of overhead.In all of the forms I have ever created, however, I have only had use for this technique twice, and the specific situation gave me no problems, because the forms were fairly simple. I don't promote this method because I think it will make your problems go away, or they are a perfect substitute for native events, because that is not the case. But if you _must_ have an event that the language doesn't provide, this is the only method I have seen to do so. In 99% of all cases, you can avoid this by checking
the property where it really should be checked, or with a wrapper method that is called instead of directly toggling the property. This still puts the responsibility on the calling code to check the property, though. My first suggestion to anyone that wants a custom event like this is to thik about what
>you _really_ need done, and if it really needs to be done exactly when the value of the property changes as opposed to the next time the form (or control)is refreshed.
>On a side note, the above mentioned problems with timers are not by a long shot the only problems they exhibit. There are situations where they don't fire at all (open messagebox, certain menu activities) and sometime they will pile up missed timer events andfire them all at once. It's a horrible control, in my opinion, and I avoid it wherever possible. But sometimes we don't have a choice.

Thanks for the info.

Dan