>Ed thanks for your reply.
>
>Just one comment you make :
>>>>>And the usual issues of CPU speed sensitivity of FPW
>
>Do I detect some underlying FPW problem here ?
>
FPW's underlying engine is sensitive to the speed of the CPU it runs on; there's a patch available from MS (also linked via
www.abri.com) to correct the problem, but -only- for FPW 2.6a (you have to upgrade to that version before patching) and it doesn't work all the time from what I've seen - I've gotten intermittent reports of continued problems running on some fast Athlon boxes. It does not apply to FPDOS or VFP; the problem is something in the FPW engine (actually, it has to do with the C engine used with FPW; there are other old apps written with the same compiler that also are plagued by the same problem, and plenty of stuff with timing loops that depended on a guesstimating timing loop to let something load before continuing that also will run into problems.)
>
>Regards,
>
>
>Gerard
>
>
>
>>>I have a FPW app which calls a VFP app and just does on thing and then retuens back to the FPW app. The VFP app ia made up of just one screen and a few controls that require no user intervention at all. VFP app is called:
>>>RUN /N MYVFPAPP.EXE "MyParam1" "MyParam2"
>>>
>>>(I need to do it like this because my VFPAPP has a particular Activex control which ,definitely works from a screen, but may not work if instantiated separately)
>>>
>>>I am able to hide both the screen, and the controls on the secreen, but for the 2 seconds that the VFPAPP runs, it brings up the VFP main Foxpro Window momentarily.(i.e. A Visual Foxpro app window with File Edit Windows Help on it)
>>>I dont want the user seeing this screen at all.
>>>
>>>Is there a way of completely hiding the VFP window when the VFP app runs. so that the user has tha appearance that an external app is not being loaded ?
>>>
>>
>>Yes - embed a CONFIG.FPW in it with the line:
>>
>>SCREEN=OFF
>>
>>The problem is, you'll never be able to detect termination. You might consider deplying the VFP app as a DDE Server, and using DDE to control it, rather than using RUN /N, which does not wait until the VFP app terminates to return control to FPW. In addition, right now you have no way to directly return results from the VFP app.
>>
>>And the usual issues of CPU speed sensitivity of FPW, the fact that it's no longer a supported product, and the ever-increasing difficulty of integrating Win16 apps with COM, the Win API, and I suspect the .Net architecture when that arrives in a year or so. We tentatively know that VFP will be relying on the Interop services, which rely on COM to interface with the .Net environment; I've not really explored what Win16 will be able to use.
>>
>>>Regards,
>>>
>>>Gerard