>Bill,
>
>Sorry for the delay I've been out of town and mostly offline the last few days.
>
No problem. I'm grateful for any input.

I finally got it to work after a lot of reading, hair pulling, etc. I got the DLL to work ok when called from VFP with two parameters passed by reference, one a string type the other an integer type. On the C++ side I used BSTR* for the receiving string type and long* for the receiving integer type. The BSTR* was apparently necessary to satisfy the COM interface requirement of passing VARIANT types across COM interfaces. I haven's been able to get, e.g., a LPSTR type to work on the VC++ side. I've tried so many combinations they've gotten a bit blurry, but I think the VC compiler screams at this. I had to do some conversions in the C++ to get C++ data types, do my work then convert back to COM variant types. This was all working when called from VFP. Funny thing is that I couldn't get it to work from VB ( one plus for VFP over VB ... just kidding :-) ). Best I can tell from the reading I've done is that VB strings are of a "BSTR" type with special attributes and which is not "friendly" to C++ types. There are some MS KB articales about this, one showing how to pass VB strings to an API style C++ DLL, which really doesn't help for the COM DLL case. I am wondering if it's even possible to pass VB strings to a COM DLL and would like to find out the answer to this, and how if it's possible. To solve my immediate problem, I eliminated the string parameter and am returning the string as the return value from the function. This is working in VB and VFP. I would prefer to stick with an integer return indicating success/failure of the call and the string loaded in a pass by reference parameter since this seems to be the more "standard" way of doing it. But until I get some more smarts regarding this or someone who knows the answer to how to pass a VB string to a COM DLL function, or verifies that it simply can't be done chimes in, I'll stick with my curernt working solution.

Thanks for taking the time to give this thought.
Bill

>>I chose the ATL Wizard because presumably you can build a lightweight item with it ( i.e. lighter than using the MFC with it's overhead ). Honestly, in relation to COM DLL vs. API style DLL, I don't know what switches have to be thrown to determine which it will be. What determines this attribute?
>
>It's not just compiler switches. If you are doing COM I imagine that ATL is better than MFC at this point. I don't know if there is significant "weight" differences between the two in all honesty. They both end up using a ton of DLL from the Windows\System folder.
>
>To create an API style DLL start the VC project using the MFC AppWizard (dll). This is what the two VC++ examples on my website use.
>
>>Since you say that the COM DLL handles everything with VARIANT type parameters, it generates a couple of questions. How would these parameters be declared on the C++ end in this case?
>
>I was wrong with that because I have spent so much time calling a VFP COM object from VC lately. In the VC COM I think you can use normal C++ types. But I can't verify it because I can't seem to get the method as part of the public interface of the test code I just created. I get unknown name COM errors when trying to call it from VFP.
>
>>Since I want to make API calls in the DLL to return system data, am I approaching this the wrong way, and if so, what should I do different?
>
>I think it should work just fine.