Vlad,

This is another one of the countless properties/events/methods/commands which need FAR more documentation than is supplied in the VFP docs!
For instance, AutoYield applies to "Windows Events", which should go far beyond just OCX-related stuff.
And I wonder just how one is supposed to KNOW that an OCX *needs* AutoYield set to .F. when there is really no mention of such requirement in the documentation of the few OCXs I have reviewed. Bad results = put-it-in, I guess! We should not have to guess at these things.
And wouldn't it be nice if AutoYield cause VFP timers to fire ON TIME rather than only when VFP finally gets control? We could surely use *something* to make this so!

Personally, the sparse documentation on AutoYield and DOEVENTS makes them seem "dangerous" to me. When (as it appears) there are cases where one *MUST* set AutoYield, then better documentation is called for so that we can have a decent chance to know what is actually happening.

Cheers,
Jim N

>Assuming that you don't want to set it at the beggining of you app, I would say that you should have a global var or app property to keep the number of active OCX that need Autoyield = .F. You should increment it in Init and decrement it in Destroy. The ocx that decrements it to zero, resets it to .t.
>
>Otherwise, if you have more than one ocx... I'm sure you understood the "scenario"! :)
>
>Vlad
>
>>I'm trying to make my opinion on the good use of the Autoyield property. I've come to the following conclusion: generally you should leave it to its default value (.T.). But if you have use an ActiveX control on a given form, you should set _VFP.Autoyield = .F. in its init() and reset it to .T. in its Destroy() . Do you agree with this simplistic approach?
>>
>>Althought it should be much easier to set it to .F. at the top of the application, I've experienced that it generates at least refreshing problems.
>>
>>José