Unfortunately I do not have your original code Gene (if you showed it in an earlier email).
If you know your config files differ between your startup and your main, it might be an issue. I'm assuming you have tried compiling the config.fpw into the .exes to see what happens (you can include it under the 'other' files). But I cannot vouch for the situation as my config.fpw files pretty much the same regardless of the app.
I have not used the RUN /N, I usually use WinExec. You need to register the function, here is a block of code I use to declare it:
*-- Declare the Win API function for running other executables *-- The uIntCmdShow can be: *-- SW_HIDE - 0 *-- SW_FORE_AND_MAX - 3 *-- SW_MINIMIZE - 6 *-- SW_DEFAULT - 10 *-- ....??? *-- Make sure and put a CHR(0) on the end of the parameters *-- cExecutable = 'f2pdfgen.exe' *-- cParameters = ' 1 2000 c:\dev\form2\data\ f2newpdf' + CHR(0) *-- cCommandString = cExecutable + cParameters *-- x = WinExec(cCommandString, 0)
DECLARE INTEGER WinExec IN Win32API STRING @lpszCmdLine, INTEGER uintCmdShow
Anyway, I'm not sure why you would have a problem with the updater updating the main .exe. If the update is failing the mainexe may still be running? But if the only way to run your main .exe is by running the updater that should not happen. I did put a piece of code in my updater app that would write a 'special file' - the main exe looks for the existence of that special file and if it is not found, it immediately exits. If it does exist it erases it and continues on its merry way.
But one thing I had to do was not try to update the updater exe. I fixed that by not trying to update the updater .exe until I exited the main .exe - e.g. AFTER the CLEAR EVENTS in my main .exe.
I also download my updates to a holding folder, not directly to the .exe files. I did that partly for testing/tracing at first, but then I saw the 'copy to update' process was so fast that there was no reason to change to direct downloads. After I saw that, doing my above process (updating the updater only when my main .exe exited) became very easy.
So, to sum up, - my updater downloads (or copies from a server) all needed updates into a holding folder. - if the main .exe was part of those updates, it copies the .exe from the holding folder over the main .exe and then deletes the main .exe from the holding folder (for me, the holding folder is subfolder under the main .exe folder). - the updater app creates a 'special file' to show that it has been executed - then I run the main .exe and let the updater app exit out - in the main.exe I check for the 'special file' - if it exists, it is erased and the .exe continues, if it does not exit, the .exe immediately exits (do not pass GO, do not collect $200) - then in the main .exe I have code after the CLEAR EVENTS (e.g. aka in the ON SHUTDOWN code, or whatever) that looks to see if there is a new 'updater.exe' waiting in the holding folder. If there is, I copy that, delete it from the holding folder, and then continue on to let the main.exe exit.
I have never had "timing update" problems with the above. I have a feeling the above design would work using "RUN... /N" as well.
HTH, -Charlie
On Mon, Oct 7, 2019 at 4:49 PM Gene Wirchenko gene@shaw.ca wrote:
At 13:11 2019-10-07, "Tracy Pearson" tracy@powerchurch.com wrote:
Gene,
How you launched the 2nd executable from the 1st executable may have been
a
cause. The VFP RUN command will block if you don't use the /N clause with it.
I did use run /n. It works like a charm with my one-level loader.The ShellExec API should have returned control allowing you to exit the
1st
executable. There are a couple of API's that will wait for the 2nd executable to
return
before continuing.
The VFP RUN command the CMD window to run the 2nd executable. ShellExec
will
not.
So how does this make a difference? It is bothersome trying to debug this, because I can not seewhat is happening. Because the loaders are .exe programs, I do not have the benefit of the debugger, etc.
I have been wondering if having two VFP .exes running at onceis an issue. (Is there a conflict between config files?)
[snipped previous]
Sincerely,
Gene Wirchenko
[excessive quoting removed by server]