>>>>>I don't think DoEvents and AutoYield are relevant for DLL.
>>>>
>>>>Communications via COM depend on parts of Windows that are outside of VFP. If VFP is blocking processing of Windows events, it might interfere with that.
>>>>
>>>>Testing of these is easy, literally one line of code each.
>>>
>>>Seems like it made no difference. I added DOEVENTS following with
>>>_VFP.AutoYield = .f.
>>>
>>>---------------------------
>>>I'm closing for now, will resume Saturday night.
>>
>>_VFP.AutoYield is global, set it once before any of your test code runs.
>>
>>I'd put DOEVENTS as the last line in your loop.
>>
>>To be thorough, you have 4 tests:
>>
>>1. .AutoYield = .T., no DOEVENTS
>>2. .AutoYield = .T., with DOEVENTS
>>3. .AutoYield = .F., no DOEVENTS
>>4. .AutoYield = .F., with DOEVENTS
>
>I see, you suggest to put it in the test procedure, not in the dll's code?
It sounds like:
- you have a loop that repeatedly tests your COM DLL
- you are seeing an increase in execution time between the first and last tests
Unless your DLL is setting .AutoYield, you can just set it at the start of your test code, and since the COM DLL is in-process, your test setting should remain in effect.
Definitely put the DOEVENTS in your test code.
Regards. Al
"Violence is the last refuge of the incompetent." -- Isaac Asimov
"Never let your sense of morals prevent you from doing what is right." -- Isaac Asimov
Neither a despot, nor a doormat, be
Every app wants to be a database app when it grows up