Interesting. I'm doing some work with this stuff right now, my first thought would have been it would be fine to create your worker objects in .Init() - I would probably issue DODEFAULT() as the first line, though. How did you make your call? Did you create another method that was not PROTECTED so you could call it remotely? Can you elaborate on Rick's insight(s)?

>Hi
>
>Rick Strahl gave me a hint that solved the problem. I mistakenly created the worker objects in the "Init" of dcvfpsrvc. Once I moved the creation of the workers to a separate method everything worked fine.
>
>I have since created a windows service using PureBasic which creates the manager COM object (dcVFPSrvc) and the manager object creates worker COM objects as needed to run scheduled tasks for VFP. It is similar to the idea of ParallelFox with the added advantage of running as a service. It works very nicely. Now users can schedule reports, exports and other tasks in my VFP apps and they run unattended at the specified time and then reschedule themselves as necessary. When the user comes to work the reports or export files etc. are waiting for them in the inbox or they have been uploaded to an FTP site as requested by the user.
>
>Simon
>
>
>
>>>Hi
>>>
>>>Can anyone explain why "Do dcvfpsrvc.prg" works when I use CreateObject("dcvfpsrvc") but locks up VFP when I try CreateObject("dcvfpsrvc.dcvfpsrvc")?
>>>
>>>I created both dcvfpsrvc.exe and dcworker.exe marked both as OLEPublic.
>>>
>>>
>>>

>>>Public go
>>>
>>>Set Step on
>>>
>>>*go=CreateObject("dcvfpsrvc.dcvfpsrvc")
>>>go=CreateObject("dcvfpsrvc")
>>>For ln=1 to go.nWorkerCount
>>>   go.aWorkers(ln).Test
>>>EndFor
>>>go.StopWorkers
>>>go.DestroyWorkers
>>>
>>>Return
>>>
>>>Define Class dCVFPSrvc As Session OLEPublic
>>>
>>>
>>>   Protected nProcessQueue,cStartin,cAppBase,dNow,nServerOffset,height,width
>>>   Dimension aWorkers[1]
>>>   aWorkers(1) = NULL
>>>
>>>   Height = 63
>>>   Width = 100
>>>   *-- Process Task Queue Flag
>>>   nProcessQueue = 0
>>>   *-- The number of work COM Objects Created.
>>>   nworkercount = Iif(Version(2)=0,2,4)
>>>   *-- The folder from which the application was started.
>>>   cstartin = ""
>>>   *-- The base Directory for Customer Applications
>>>   cappbase = ""
>>>   *-- The time the service was run.
>>>   dNow = Datetime()
>>>   *-- The server's time zone offset.
>>>   nServerOffset = ""
>>>   
>>>   Name = "dCVFPSrvc"
>>>   
>>>   *-- Creates the Worker COM Objects
>>>   Protected PROCEDURE createworkers
>>>      Local ln
>>>      Dimension This.aWorkers(This.nWorkerCount)
>>>      For ln=1 to This.nWorkerCount
>>>         This.aWorkers(ln)=CreateObject("dcworker.dcWorker")
>>>         This.aWorkers(ln).oMain = This
>>>      EndFor
>>>   ENDPROC
>>>...
>>>EndDefine
>>>

>>My understanding is if you have built an EXE COM server named "dcvfpsrvc" with the above code, the call CREATEOBJECT("dcvfpsrvc.dcvfpsrvc") should work. But, I never name the EXE and its included classes the same, maybe that isn't allowed in COM. You could test by naming your EXE or class to something else.
>>
>>No sure answer, just a few SWAGs:
>>
>>- Are you working with Windows 7 (or Vista, is probably the same)? When you build an EXE COM server, the final step of the build is where VFP registers the server in your computer's registry. If you are not running your VFP dev environment as an administrator (even if your account is nominally an admin), this step will fail. If your newly built server isn't registered properly it won't work properly
>>
>>- Related to the above, you may think you can get around that by running a CMD window as administrator, then running dcvfpsrvc.exe /regserver at the prompt. I tried that a couple of times - it appears to work, but the servers I was testing with didn't work properly. Bottom line, to minimize headaches when building EXE COM servers, I run VFP9.EXE as an administrator (right click, run as admin).
>>
>>- Is it possible you have another dcvfpsrvc.exe earlier in your PATH, or somehow being accessed, that does not contain the dcvfpsrvc class?
>>
>>- Just an observation, your test code doesn't include a call to go.CreateWorkers( ), so the .Test's will fail