>This info stored under the \HKCU\Software\CompanyName\SoftwareName\VersionNum setting. After making this change, their app should have started up with the standard "This is the first time you've run this" message (since it will be looking at a different spot in the registry). Is this what happened?

I don't know yet since my contact at the client's site is on vacation this week but I suspect that the standard dialog did not run. I'll have to wait until the client contact returns (I did return them to the backup .exe so they are fine for the time being.

>>BTW, while looking around my Cursorsource under the oErrorLog in the EventLogEnvironment got changed to "..\h.dbf" Is the correct cursorsource 'errorlog'?

It's '[errorlog]'

>That sounds like the environment got messed up by the builder - it's happened to me on a few occasions. Usually at that point I'll just delete the environment and recreate it. I think there was a thread here sometime back about this (and some fixes), but I don't remember what the specifics were.

Yes, that's what I do whenever I mess up that property. But I've suspected is a VFP problem revolving around the name 'cursorsource' and not an MM Builder problem initially. If you mess with the environment outside the builder you can duplicate this same problem. Switch default folder, open the environment, select the oCursor class, save it and watch the relative pathing go from "..\h.dbf" to something like "..\..\h.dbf"

I started using a launcher program, aptly named 'Launcher.prg' which was written by Nick Neklioudov. This sits on the C: Drive, checks the Server for a newer datetime stamped file(s) and copies it down to the C: Drive and launches the .EXE. I am wondering if this qualifies for the caveat in the SetProcsAndLibs() in Setup.prg as a STUB program and if this is the cause of the problem that caused me to start this thread in the first place. I guess I'll have to test this on the family pc....