>>Actually, this ones a little trickier. AFIELDS, like a few other VFP data functions (to my infinite frustration) doesn't throw an error when there is no table open in the current area, it displays an Open dialog. Only after cancelling put of the dialog does the error get thrown.
>>
>>Paul, to solve your problem, just fix your code and make sure that there is a table open in the current work area. To try to avoid future issues like this, you can see if SYS(2335) will disable this dialog in your dll server (it is really meant for exe servers, but it might do the trick).
>
>Thanks for your help everyone. It was an "error". This is turning into a big learning experience.
>
>Am I correct in assuming that even though I do an create("myapp.myclass") on my dll and it's running in-process, that any tables that are open in VFP are not available to the process? For example, I have a table REPORT open and I want the dll to run some functions on it. If I just pass it the alias it won't be able to find it but if I pass it the filename it can open and process it. Correct?
>
>paul

Correct. COM servers can only access VFP environment stuff through objects you might have passed it.

Ask your self this question though: if your COM server were to rely on data open in the VFP environment, why is it a COM server at all? The purpose for COM is get cross-platform compatibility. If you are calling your COM srever from VFP, and the COM server was written in VFP to only work with a VFP client, why the heck is it a COM server and not just a class?

You are not the first person to ask this question on this forum, but the fact that it is getting asked worries me that many people are miunderstanding the purpose of COM. We should not be building COM server for the sake of building COM servers. If your only client for your server is VFP an the source for the server was VFP, you shouldn't be leaving the VFP environment to do this work. There is no use using a the Windows mechanism for object brokering when the objects are internally native in the first place. Trying to do this just makes implementation awkward, and greatly degrades performance as far as object instanciation times.