Oh. I didn't get that from the OP's text. Makes sense.

What's needed is a watchdog that gets pet every so often. That can be your original VFP app. Just pass your HWND as a command line parameter to the launched process, and have a timer setup in the APP which sends a WM_USER + N message back to your form's HWND on the main app once a second or so. On your form's Init() event, BINDEVENT(thisForm.hwnd, WM_USER + N, thisForm, "myCustomWatchdogPetHandler") and then in that code store the last datetime() it was pet. Have a timer on your main form compare against the datetime() and if it gets to be too high take some action (launch a user form to see if it's still running, launch a separate process to shut it down and force a restart, etc.).

Lots of options. Depends on how far the OP wants to go.

Craig's suggestion of checking CPU utilization isn't always a good test depending on networking protocols involved. It could be in a wait state for a remote server to respond, apparently doing nothing, but actually working properly.

The Windows message queue, for all its flaws, is a pretty decent way to make sure the app is still running. If it's still processing messages, it's likely still running.

Best regards,
Rick C. Hodgin


>Hi Rick, Larry
>
>The problem with that approach is that WMI will tell you that the EXE is in memory, not necessarily running, for example it might have had a network problem or data corruption and it will be waiting for the user to close a message like "Error reading file" or similar and then you'll think is running normally.
>
>We tackle this with a double approach, writing into a "Heartbeat" table and optionally checking some other table to see when it was last updated (not thru the OS last modified, that might be an option in some particular cases, but we use a date/time field)
>
>For example:
>
>We have lots of data loggers that have a serial connection and we need to write the input from it into tables 24/7, now the heartbeat will tell us that the program is running, but it says nothing about receiving data from the serial port, for that we check the table were we save the data to be sure that is also writing, then we have a definition table that tells us what is the expected frequency of received data, some tables might be writing several records per second, others only a few per day so the monitoring program compares the elapsed time since the last record written against this expected frequency and if there are no new records the monitor will mark it as "Idle", if there is no heartbeat in the defined heartbeat frequency for that particular server then is marked as "Down"
>
>Also whenever a status of a server changes we record this change and the date time, so we could (we use to but now we do not) produce statistics about down/idle times for each server.
>
>
>
>>If scripting is available, look at this to see how to do this in VFP without running a separate EXE (it should be fairly straight-forward to translate the VB code to VFP):
>>
>>http://msdn.microsoft.com/en-us/library/windows/desktop/aa394599%28v=vs.85%29.aspx