Marathon Griffin Computers and Service - Computer and Laptop Sales - Computer Repairs and Service - Network & Accounting Specialist

 

Advanced Loader.EXE written in Visual FoxPro

 Back to Tech Tips Index Page

DISCLAIMER:
PLEASE BE ADVISED, THIS PROGRAM IS OFFERED FREE OF CHARGE AND "MARATHON GIFFIN COMPUTERS" ASSUMES NO LIABILITY WHAT-SO-EVER IF YOU DOWNLOAD THIS PROGRAM, OR DISTRIBUTING IT TO OTHERS. ANY ISSUES "REGARDLESS OF THE OUTCOME" IS AT YOUR OWN RISK OR THOSE YOU PASSED THIS PROGRAM OFF TO !
PLEASE PAY SPECIAL ATTENTION TO THE DATABASE OVERWRITE OPTION AS YOU DO NOT WHAT TO OVERWRITE ANY PRODUCTION DATA. PLEASE TEST THIS PROGRAM FULLY PRIOR TO DEPLOYING IT IN ANY PRODUCTION ENVIRONMENT.

Click Here to download the Advanced Loader Project 

OVER VIEW AND HISTORY
Over the past couple of years I have seen several examples of Visual FoxPro applications that were coded with the intent that they could be installed in a users workstation and a desktop shortcut place on the desktop to launch a specifiic targeted application EXE.

The sole purpose of this application called a "Loader.exe" was to run another EXE from a network shared drive. If the IT group copied a newer version of the application into the network shared folder where this application EXE's resided, the Loader.exe would check for the most recent EXE based upon the EXE's datetime stamps and launch it. Normally there could be EXE's on the shared network drive such as:

  • ClassicPos01.EXE DateTime : 2012.03.04 15:45:03 PM
  • ClassicPos02.EXE DateTime : 2012.06.30 17:32:22 PM
  • ClassicPos03.EXE DateTime : 2012.08.04 12:45:33 AM

This Loader.exe would run the Visual FoxPro ADIR() function to load all EXE's mathcing a skeleton name in an array and then step through the array until it found the EXE that matched the skeleton name with the most recent datetime and then launch it. In the example of the three EXE's above, the skeleton could be the first 4 characters of the EXE such as "CLAS".

Stepping through the array one can find the most recent EXE named:
"ClassicPos[n].EXE" and launch it.

Such a Loader.exe source code looks like the example shown below:

* --- Loader.prg
* --- It will load the newest version of your VFP exe found in a
* --- network share.
LOCAL lcExecPath, lcFileName, lcSkeleton, lnFileCount
LOCAL lcExe, ltLatest, lnI
LOCAL ARRAY laFiles(1)

* --- Get the path to the executable directory.
lcExecPath = JUSTPATH(SYS(16))

* --- Make the above path your default.
SET DEFAULT TO (lcExecPath)

* --- Build an array of all possible EXE names.
* --- Below you place some wild card to provide a skeleton
* --- to your exe naming convention.
* --- In the below example my exe is CLASSICPOS03.EXE
lcSkeleton = "CLAS*.EXE"  && lcSkeleton Wildcard file spec for ADIR()lnFileCount = ADIR(laFiles,lcSkeleton)

* --- Look for the most recent EXE file.
lcEXE = ""
ltLatest = {}

FOR lnI = 1 TO lnFileCount
  IF FDATE(laFiles(lnI,1),1) > ltLatest
  ltLatest =
 FDATE(laFiles(lnI,1),1)
  lcExe = laFiles(lnI,1)
  ENDIF
ENDFOR

* --- Launch the most recent EXE file.
IF NOT EMPTY(lcExe)
 
  DO (lcEXE)
ENDIF

CAVEATS OR CONS TO THE ABOVE PROCESS
1. The above code example represents a simple and basic stand-a-alone Visual FoxPro executable. There is no graphics interface to change things such as the EXE skeleton, thus each Loader.exe must be modified and compiled for each executable it is ment to run.
2. The Loader.exe will only run an EXE from someplace like a centrailzed Server network shared folder.
3. There is no capabilities to actually obtain the most recent EXE and supporting files and copy them down to a workstation so that the Loader.exe can launch an executable copied down and residing locally on a workstation.
4. Most of us realize the speed improvement if running an EXE locally versus running across the network from a server's network shared out folder is far better with a locally installed EXE and required files.  On top of this the total network traffic is reduced.

 

MY RECENT GOAL
Several months ago I started to think about coding a new updated version to the old Loader.exe program. Then a few weeks ago I obtained a 3rd party contract to code exactly what I was thinking about doing.



REQUIREMENTS FOR THE NEW ADVANCED LOADER.EXE SOFTWARE
❶  Loader.exe need to not only launch EXE's from a centralized server network shared folder, but must also be able to sync the most up to date files from a server down to a workstation and then launch the most recent EXE off the local workstation.
❷  Need to be able to sync folders from the server down to a workstation and create the entire sub-directory tree on the local workstation to match the folder hierarchy found on the server for that particular application.  For the purposes of what to call this advanced Loader from now on I will refer to it as the "Loader / Upgrader" application.
❸  Must support a graphics IDE encorporated with the now expanded Loader / Upgrader to allow IT staff to modify the settings controlling the Loader / Upgrader core logic flow.  If running an Active Directory network the IT folks could using the NetLogon, use scripts to actually update the controlling memory file that stores the "Loader / Upgrader" applications configuration settings.   Very powerful stuff in the right hands. 
❹  Adility to change the Loader / Upgraders settings, need to be only available via a user definable password that shall be encrypted when saved to disk and unencrypted when read from disk.
❺  The Loader / Upgrader application requires a physical form to appeared and present a progress bar corresponding to the progress percentage of files copied in real time to keep the und user aware of what is happening.
❻  For the purposes of the call from the Loader / Upgrader to the EXE it was setup to load, this will be accomplished via the Windows shell API call not the DO (lcEXE) call.  This is done so the Loader / Upgrader EXE can be killed and not be running as a process once the real EXE to be loaded is running.
❼  Needs to be able to deploy a database folder containing; Database files, DBF's, CDX's, IDX's, etc. from a Database folder on a server down as well to the local workstation.  This is in the event of a brand new system to be deployed on workstation where the database will in fact be running locally.   As and example, a grocery store where there are 10-15 checkout tills and the database files and daily information are stored locally until the day end close where a centrailzed server polls the tills to obtain each tills data.  Then once the polling of data is successful, the data files on the Tills are Zapped so they are ready for the next day of business operations.

Now all of the above sounds simple, but in actually coding such an application I was in for some major work - lol
After going through the complex coding logic with this project I now 100% understand why nobody else has tackled and completed such a Visual FoxPro project.

 

Lets look at some of the issues and code beneath the hood and how I tackled them and why I did what I did?

  1. First off I needed a recursive program to obtain all the source folders and files from the targeted server's network share for the application to launch in question.  In this program or routine I needed all the folder even if no files existed in them, and as well folder with files in them each in their individual record prepped in a local cursor I could manipulate.  DOWNLOAD the full project and pay special attention to the source code in the "RecurseDir_New.prg".  Mega work here to get this recursive program to do what I wanted it to.
  2. Next major issue was to code in pure VFP, the code required to take the now existing local cursor and duplicate the hierarchy of folders as they exist on the server and create them locally on a workstation.   DOWNLOAD the full project and pay special attention to the source code in the "AdvLoader.prg". 
  3. In order to create a graphic user interface this was not any problem with Visual FoxPro, however I did need to reference the frmInfo properties externally from the frmInfo form so in the MyMain.prg "Startup program" I called the frmInfo using the NAME and LINKED options so I could in fact reference any form object from within my application.  Pay attention to the code in "MyMain.prg". 
  4. Saving the "Loader / Upgrader" configuration settings I decided to use the Visual FoxPro's memory file capabilities.  This hold the complete configuration settings including the encrypted password to login and change the configuration settings.  The goal here is to achieve the end resulting project without the use of any database or DBF files, thus the simple VFP memory file was used.
  5. To try and avoid PUBLIC memory variables I used _screen properites such as: _screen.AddProperty("scr_Password",p_Password)
    declared in MyMain.prg.
  6. Another thing I wanted to do is to avoid the DO (FileName.EXE) to load the EXE to be launched by the "Loader / Upgrader" application. So I decided to go with a full Windows API shell command to launch the required EXE to be run. Once the targeted EXE was launched I killed the "Loader / Upgrader" with a Windows Kill API command.
  7. I added in extensive in-source documentation into all my routines so my code should be easy to follow and understand what I am doing and why!
  8. I used 100% Visual FoxPro code and some training examples of how to code and call Windows API's. This project greatly displays how you can easily extend the Visual FoxPro language's capabilities by using Windows API calls.
  9. I tried to eliminate classing so "Newbies" could follow the logic flow of what is in fact happening, but I did resort to classing in my "RecursiveDir_New.prg". I also did violate my "Best Practice Rules" and used one PUBLIC memory variable in this same "RecursiveDir_New.prg".  I looked at this and really felt in this case I would use 1 PUBLIC memory variable rather than resorting to a _screen property and all the related code to work with it. This is where shades of grey come in folks!
  10. I did code one simple ERROR trapping form, but this I can be worked on moving forward and possibly greatly enhance the error trapping process.
  11. I looked at using an array instead of a local cursor for listing all my recursive folder paths and files, but eventually decided on a local cursor as this was far easier to look at with break points and greatly simplified the entire debugging process.
  12. I did extensively use the SET FILTER command to manipulate the local cursor holding all recurive folders, paths and file names.  In a small recordset with say under 2 - 3 thousand records, the SET FILTER is faster than SQL - Select statements. 

OK, that pretty much sums up my top 12 points and why I did what I did!

 

NOW OFF TO THE FINAL PRODUCT
Below is a screen shot of the graphics user interface if you enter in the password within 3 seconds of launching the "Loader / Upgrader" application installed on a local workstation with a Windows Desktop shortcut pointing to it :

AdvLoader

 

Below is a screen shot of what the "Loader / Upgrader" application displays visually for the end user when clicked:

Progress

 

I personally feel that this application represents an excellent training tool for anyone interested in some advanced, yet easy to follow Visual FoxPro coding examples.

NOTE: This project has been written in Visual FoxPro 9.0 with SP-2 applied, the Visual FoxPro runtime libraries for Visual FoxPro 9.0 are required to run this application.

You can download the entire project and all source code from the link below at my website:

Click Here to download the Advanced Loader Project

Have fun from the IceMan from the Great White North of Canada, ay!

 Back to Tech Tips Index Page

SystemsLaptop 
Tower 
Monitor 
Office