Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Launcher() or Loader() - Best practices
Message
 
 
To
22/12/2000 11:53:35
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Miscellaneous
Thread ID:
00456354
Message ID:
00456369
Views:
27
YOur code sample is on the right track. What I do involves a standard data directory tree that all my apps use:
ServerRoot
   + Apps
     + AppName
       + Data
       + Reports
       + Updates
The app is installed locally. My app looks for the data folder using UNC path. It then backs up one level and knows [with code] that all program updates are in the Updates folder in the data tree. I do an adir() on the Updates folder and loop through all the files in that array. If the date/time stamp is newer than what is in the app installation folder or the file does not exist in the installation folder, I copy that file from the server. The last line of code in my launcher EXE is to DO ("MyAppName").

As a safety precaution, I have the following as the first lines in my loop to prevent overwriting development files:
if version(2) = 2
   exit
endif
>Ed Rauh and George Tasker just mentioned they use a Launcher() for LAN apps.
>
>I am in the process of creating a new launcher for an app. I want to throw my old one away and re-do it properly. What's the consensus/best practices?
>
>1) What's best: compare local.exe and lan.exe datetime stamp or use aGetFileVersion() and read compare build numbers?
>
>i.e. ADir() vs. aGetFileVersion()
>
>n = ADIR(laLocal, "MyProg.Exe")				&& find local copy
>IF n > 0
>   n = ADIR(laRemote, lcCSSPath + MAINPROGRAM)	&& find remote copy to compare
>   * compare name and date/time stamp
>   IF (laLocal[1,3] == laRemote[1,3]) and (laLocal[1,4] == laRemote[1,4])
>      * they are equal
>   ELSE
>      * different, inform user and update local copy
>   ENDIF
>ENDIF
>
>
>2) Keep workstation's mapping data in local Config.fpw (requires recompile of local laucher.exe?). Or use Registry (using registry.vcx or sfregistry.vcx or similar). Or an INI. Maybe a local Setup.XML file instead of a setup.INI?
>
>3) A little unrelated best practice Q: If Registry is used, and the same prg needs to instantiate WSH/FSO fpor other things, is it worth to eliminate the registry class and just use WSH as it can also read/write registry?
>
>I use Doug Hennig's SFRegistry.vcx which is excellent.
>WSH 's registry functions are a little more limited than SFRegistry.
>
>i.e.
>
>oReg = CREATEOBJECT("SFRegistry")
>lcDataPath = ADDBS(oReg.GetKey(lcSubkey, lcDataKeyName))
>* or
>lcDataPath = loWshShell.RegRead("HKCU\" + ADDBS(lcSubkey) + lcDataKeyName)
>
>
>SFRegistry has oReg.IsKey() while WSH does not have a direct way to query if a key exists (that I can see).
>
>So, is it worh to have both instantiated or just throw one away for this proj.
>
>4) Am I wasting too much time on a simple task and there are online samples to look at, not to reinvent the proverbial wheel?
>
>TIA
Mark McCasland
Midlothian, TX USA
Previous
Reply
Map
View

Click here to load this message in the networking platform