>I have almost the simplest possible COM server. COMServer.prg has this code:
>
>define class COMServer as Session olepublic
> function Hello(tcName)
> return 'Hello, ' + tcName
> endfunc
>enddefine
>
>The only other file in the project is Config.fpw:
>
>logerror = off
>talk = off
>safety = off
>bell = off
>notify = off
>confirm = on
>deleted = on
>exclusive = off
>resource = off
>time = 1000000
>refresh = 0,200
>keycomp = Windows
>screen = off
>status bar = off
>
>The project's name is COMServer.pjx, Project Info/Servers is set "Single Use" instancing, and I build a single-threaded DLL named COMServer.dll. When I use this code:
>
>loServer = createobject('COMServer.COMServer')
>
>a new DLL is created in the folder named comserverr1.dll. Why would instantiating a COM object cause a new DLL to be created? I see this on Windows XP, Window 7, and Windows 8.1.
>
>Normally I wouldn't care about this weirdness except if the application is installed in a read-only folder like all good apps should be, the CREATEOBJECT statement fails because the new DLL can't be created.
>
>Has anyone seen this? TIA
Just tested using your code. Win7 Ultimate 64-bit. First, running VFP9 as admin (because I remember getting Registry access errors if I don't):
- used your code, built, ran - no extra file created
- checked project information, it was multi-use by default, changed to single-use
- rebuilt with recompile all, ran - no extra file created
Then tried rebuilding with VFP not run as admin - got Registry access error, error when tried to run the build anyways "No such interface supported".
So, assuming you're running VFP9 as admin it should work.
Do you have anything hooked into your project that runs at build time?
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