Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
How fast is too fast??
Message
From
30/08/1999 20:58:22
 
 
To
30/08/1999 20:48:00
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
00259461
Message ID:
00259466
Views:
16
>I have this VFP5a EXE that has this code at the start of the program.
>
>IF NOT tsprgrun('TERMISRV')
>
> RUN /n2 TERMISRV.exe
>ENDIF
>
>IF NOT tsprgrun('RELAYSRV')
>
> RUN /n2 RELAYSRV.exe
>ENDIF
>
>Where tsprgrun is a function to check(using API's) if the app is already running and TERMISRV.exe & RELAYSRV.exe are 2 VFP5a DDE Servers.
>

You might want to look at my API_APPRUN class (downloadable from UT's File Section under Win32 and Other APIs; you could modify the code for the LaunchAppAndWait method to launch the app, and wait to return control until the launched app finished loading. Change the code for LaunchAppAndWait (or better, add a new method with the revised code) as follows:
#DEFINE cnINFINITE 		0xFFFFFFFF
#DEFINE cnHalfASecond	500	&& milliseconds
#DEFINE cnTimedOut		258	&& 0x0102
*	We need some API calls, declare here
*	GetCurrentProcess returns the pseudohandle of the current process (ie VFP instance)
DECLARE INTEGER GetCurrentProcess IN WIN32API AS GetCurrProc
*	WaitForIdleInput waits until the application is instantiated and at it's event loop
DECLARE INTEGER WaitForInputIdle IN WIN32API AS WaitInpIdle ;
	INTEGER nProcessHandle, ;
	INTEGER nWaitForDuration
*	WaitForSingleObject waits until the handle in parm 1 is signalled or the timeout period expires
DECLARE INTEGER WaitForSingleObject IN WIN32API AS WaitOnAppExit ;
	INTEGER hProcessHandle, ;
	INTEGER dwTimeOut
*	Save the Process handle if any and the result of LaunchApp
*	Fire the app and save the process handle
LOCAL uResult
uResult = 0
WITH This
	.icErrorMessage = ''
	IF .LaunchApp()
		uResult = 1
		*	It's been launched;  wait until we're idling along
		=WaitInpIdle(GetCurrProc(),cnINFINITE)
		*	As long as the other process exists, wait for it
                *
                *  Modification here - remove the DO WHILE lopp that waits for
                *  the launched app to terminate
*		DO WHILE WaitOnAppExit(.inProcessHandle, cnHalfASecond) = cnTimedOut
			*	Give us an out in case the other app hangs - let <Esc> terminate waits
*			IF INKEY() = 27
				*	Still running but we aren't waiting - return a -1 as a warning
*				.icErrorMessage = 'Process started but user did not wait on termination'
*				uResult = 0
*				EXIT
*			ENDIF
*		ENDDO
	ELSE
		*	Return 0 to indicate failure
		uResult = 0
	ENDIF
ENDWITH
RETURN (uResult = 1)
>The problem is that on the latest 450+Mhz computers, the run command does not happen. The code in the IF - ENDIF does not execute.So the DDE servers do not start up.So what I usually get is TERMISRV.EXE runs but RELAYSRV.EXE does not execute.
>
>On slower computers (350mhz) it works fine. If I add the following line just before the RUN on the 450's:
>
>WAIT WIND "" TIMEOUT .3
>
>This works on some speedsters and on the really fast ones I have to add:
>
>WAIT WIND "" TIMEOUT .5
>
>to make it work.
>
>What is happening here? Is the CPU "too fast" for VFP or what?
>
>So on 450 Mhz--------------
>
>IF NOT tsprgrun('TERMISRV')
> WAIT WIND "" TIMEOUT .3
> RUN /n2 TERMISRV.exe
>ENDIF
>
>IF NOT tsprgrun('RELAYSRV')
> WAIT WIND "" TIMEOUT .3
> RUN /n2 RELAYSRV.exe
>ENDIF
>--------------------------------
>And on faster CPU's / Computers
>
>IF NOT tsprgrun('TERMISRV')
> WAIT WIND "" TIMEOUT .5
> RUN /n2 TERMISRV.exe
>ENDIF
>
>IF NOT tsprgrun('RELAYSRV')
> WAIT WIND "" TIMEOUT .5
> RUN /n2 RELAYSRV.exe
>ENDIF
>--------------------------------
>
>works! Starnge eh?
>
>Anyone else have this problem of having to SLOW DOWN their code to make it work??
>
>Bernard
EMail: EdR@edrauh.com
"See, the sun is going down..."
"No, the horizon is moving up!"
- Firesign Theater


NT and Win2K FAQ .. cWashington WSH/ADSI/WMI site
MS WSH site ........... WSH FAQ Site
Wrox Press .............. Win32 Scripting Journal
eSolutions Services, LLC

The Surgeon General has determined that prolonged exposure to the Windows Script Host may be addictive to laboratory mice and codemonkeys
Previous
Reply
Map
View

Click here to load this message in the networking platform