>>No. I can only write back to the place that created it, ie: and active server page. The client application knows nothing about the COM object. However, you can make it work the way you want, but the client will need to run Internet Explorer. I don't think this will will work in Netscape.
>>
>>1. With your application, you will distribute COM component A (COM-A).
>>2. The user will go to your web site in their browser and enter the code.
>>3. The ASP script on the web server will launch COM component B (COM-B)
>>4. COM-B will determine the key that is needed and return this information to the ASP page in the form of an ADO record set.
>>5. The ASP page will generate a return HTML page and send the HTML page and the ADO record set to the client.
>>6. The HTML page will instantiate COM-A on the client.
>>7. COM-A processes the ADO record set and updates the VFP table.
>>
>>Simple, huh!
>
>OH. :(
>That is really depressing. I AM using IE4, but I'm not sure it's worth it. Maybe I should just have the user manually TYPE in the Reg #, a COM object (or just ASP code) can generate the Auth Key and show it to the user, and the user can TYPE in the Auth Key manually. I had no idea it was so complicated - or does it just SEEM complicated, and it's really not that bad??
>
>Can you tell me if there is a list somewhere of commands that you can't do from a .dll? I know you can't have an User Interface and now I see that you can't _directly_ write to a VFP table... are there other restrictions too?
>
>Thanks -
> ~ellen

You can do anything except UI. There is information in the VFP documentation and on the VFP web site that talks about creating COM DLLs.