How to set path

[alisaif]

Hi

I am developing the Multi-User application in my PC (D-Drive), for testing on Lan I want to copy the compiled file (.exe) on client side along with run times files. The question is should I copy this .exe on each client side for better performance and keep the table directory (\data) on network directory? If so how can I set the path for tables directory only? Should I define it in main.prg? Or set defa to k:\fas\data is sufficient. (where 'K' is network drive.

Thanks

Saif

 

[GriffMG]

Hi Saif

You do want to have the .exe file running from the client workstations. This reduces network traffic and enables you up update
the .exe, without having to get everyone out of yor system. The best way to do this is to copy the .exe from the server to
the workstation when it is newer than the one already on the workstation.

Do do this, you will need to have a 'stub loader' which you run first, which then runs your actual application (after updating if
required).

With regard to the datapath, I would suggest you develop an .ini file which knows where the data is and where the update might
be - read that in your stub-loader and then use set path and set default to access the data.

That way, if your users have different drive mappings, they can have them set in the .ini file.

Good luck

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[Mike Lewis]

should I copy this .exe on each client side for better performance and keep the table directory (\data) on network directory?

Yes. That is the recommended way of doing it.

But it's not just a question of copying the EXE and the runtimes. They should be installed with a proper setup program, which you should create with Inno Setup, InstallShield, or something similar.

If so how can I set the path for tables directory only? Should I define it in main.prg? Or set defa to k:\fas\data is sufficient.

You shouldn't set the default directory to the data directory. The default directory is normally the one from which you launch the EXE. It's better simply to put the data directory on the search path (using SET PATH). By all means, define it in Main.PRG (that's what I always do, although there are other approaches).

You can refer to the data directory by its hard-coded path (K:\fas\data in your example). But it's better to store the path somewhere where you can easily change it if you need to. I usually store it in an INI file (which then resides in the default directory) or in the Registry, from where I can read it into the program. That way, if you move the data to a different directory or drive, you won't have to rebuild and re-distribute the executable.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[alisaif]

Thanks for the reply,

How can I generate .ini file and what is Stub Loader.

Please help

Saif

 

[GriffMG]

An ini file is usually a text file that contains a series of keys and settings like:

UpdatePath = K:\APPS\MYAPP
DataPath = K:\DATA

A stub-loader is an application that you write which runs your actual application or updates it and runs it.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[Olaf Doschke]

While the others already answered your questions:

Both the stub-loader and the ini (or other type of) config file are making use of one important concept of programming: decoupling things. Delegating responsibilities, making things more flexible and configurable.

You know, if you'd write code to open tables like USE K:\data\mytable.dbf and the data would move, you'd need to change several lines, maybe hundreds or thousands. Even if using search&replace this is cumbersome.
So you already have a good idea in setting the path once. SET PATH is what you do, no SET DEFAULT, but that's ok, your idea was already the right idea. Now you only have one place to change. This is already decoupling.

Now using a INI file enables you to change that path in a separate file from the EXE, which doesn't improve the aspect of how many places need to be changed, but you can now change the path without changing code and without recompiling and distributing the new EXE. The EXE reads in the INI via FILETOSTR, for example, to eventually get a different path, when the INI changed.

The stub loader makes use of the same concept, because instead of starting your exe users start this stub-loader to eventually load a newer version then the one you would start not using a stub-loader.

Introduce decoupling whereever you have such questions as "how do I know something?". As developer you are working at design and there are two things you can do: Either you define something constant or you define something configurable/flexable/changable with low effort from outside. It's not always good to make anything configurable, there ar constants, which really are constants, but there are more constants, which change in time, eg the number of places needed to stare a postal code or tax rates are famous examples, century/y2k is another.

Now for the details:
Where do you know where the ini file is? Somehow storing a path in a file does only shift the problem. But there is an easy answer to that: Within the same folder where you store the EXE.
How do you change the INI then, if it needs to change and you don't want to do it at every PC? The same way you update the EXE, via the stub loader.
And how would such a stub loader be done? Simplest case would be a apploader.bat with a XCOPY line copying only newer files from the central current version folder to the users installation folder.

If you make use of ActiveX you won't get around installing activeX controls on each PC, there are also ways to automate this, if that is too cumbersome. A customer has made the VFP runtimes and several activex controls a standard package installed on every new computer, therefore I have the advantage to rely on these being present. There also is WSUS and similar ways to remotely and centrally provide software installed at all clients, especially in enterprise windows versions for bigger corporations. If all else is not available a classic setup would install runtimes and activex and you can still update your exe via an XCOPY batch file.

Bye, Olaf.

 

[Mike Lewis]

Saif,

I suggest you don't worry about the stub loader for now. I agree with Griff that this is a useful feature, and it's one I use myself. But it's not directly related to your problem, and will involve more work than you need. A stub loader can be used as part of a system for checking for updates to your executable, but it's not necessary for setting paths.

As for the INI file, these is just a text files, as Griff has said. You would usually create it with an ordinary text editor, and install it in your executable directory. You (or your customer) can update it simply by editing it.

Windows defines a strict format for INI files, and it offers various tools for reading them. But you don't need to worry about that. The point is that you will just use a text file to store the path to your data directory. In your application, you can read the text file using FILETOSTR().

Hope this helps.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

...As developer you are working at design time and there are two things you can do: Either you define something constant or you define something configurable/flexable/changable...

Bye, Olaf.

 

[foxlover2012]

Here is the code I use in each system.
My main program calls cpsetpath.prg
Each workstation has a dbf call cpwsconfig.dbf
In this table, I have a field which stores the path to the main networked folder, for example, \\pos2\appname\databasesI have a cpsetup.exe on each workstation which calls a form that allows the user to edit this field and more.
Also, notice that the cpsetpath.prg program checks for the required folders. So on my development computer the path would be set because those
folders exist, but not on the workstation computers.
I just like working with dbf tables over INI files because I find them easily to program and for users to make changes.
Here is my basic structure...

*-- CPMAIN.prg
clear all
close all
set talk off
local llret
llret = .f.
DO CPSETPATH with llret && sets path for the entire system - see below
if not llret
=messagebox("Could not set path...etc.",16,_screen.caption)
quit
endif

DO CPREGCHECK && checks for workstation registration
DO CPLOADENV && loads cp environment
DO FORM CPMENU && do the main form
READ EVENTS
DO CPCLOSE && close environment
RETURN




*--========================================================================================= CPSETPATH.prg
*-- cpsetpath.prg
*-- Last Edited: 02/21/2013
*-- Sets the path for the system.
parameters llret
CLOSE ALL
IF NOT FILE("cpwsconfig.dbf",1) && this file must be present on the client computer in the folder where the .exe starts.
=MESSAGEBOX("Error locating workstation configuration table (cpwsconfig.dbf). System cannot continue!",16,_screen.caption)
RETURN llret
ENDIF
SELECT * FROM cpwsconfig INTO CURSOR _setpath && get workstation info
IF USED('_setpath')
LOCAL lcbasepath,lcnetpath
lcbasepath = SYS(5)+SYS(2003) && return the start drive/directory
SET PATH TO (lcbasepath)

*-- Set path to the main CP databases - Does not need '\' in the subfolder.
lcnetpath = Alltrim(_setpath.path_cpdbc)
SET PATH TO ','+lcnetpath+'database' additive && for the main CP DBC files
SET PATH TO ','+lcnetpath+'labels' additive && for any shared labels
SET PATH TO ','+lcnetpath+'reports' additive && for any shared reports

*-- Reports and labels Path - Must include '\' for subfolder
IF DIRECTORY('reports',1)
SET PATH TO ','+(lcbasepath)+'\reports' additive
ENDIF
IF DIRECTORY('labels',1)
SET PATH TO ','+(lcbasepath)+'\labels' additive
ENDIF



*-- SET PATH FOR DEVELOPER ENVIRONMENT

*-- Forms Path
IF DIRECTORY('forms',1)
SET PATH TO ','+(lcbasepath)+'\forms' additive
ENDIF

*-- Library Path
IF DIRECTORY('library',1)
SET PATH TO ','+(lcbasepath)+'\library' additive
IF DIRECTORY('library\classes',1)
SET PATH TO ','+(lcbasepath)+'\library\classes' additive
ENDIF

ENDIF

*-- Shared library folder for all systems.
IF DIRECTORY('C:\CP_Library',1)
SET PATH TO ','+'C:\CP_Library' additive
SET PATH TO ','+'C:\CP_Library\graphics' additive
SET PATH TO ','+'C:\CP_Library\forms' additive
SET PATH TO ','+'C:\CP_Library\classes' additive
SET PATH TO ','+'C:\CP_Library\prgs' additive
SET PATH TO ','+'C:\CP_Library\reports' additive
SET PATH TO ','+'C:\CP_Library\utils' additive
SET PATH TO ','+'C:\CP_Library\apps' additive
SET PATH TO ','+'C:\CP_Library\sounds' additive
SET PATH TO ','+'C:\CP_Library\programs' additive
SET PATH TO ','+'C:\CP_Library\cpdocuments' additive
ENDIF

*-- Path to CatalogPro Images
IF DIRECTORY(ALLTRIM(_setpath.path_cpimg))
SET PATH TO ','+ALLTRIM(_setpath.path_cpimg) additive
ELSE
UPDATE cpwsconfig SET path_cpimg = ""
ENDIF


* close setpath cursor
USE IN _setpath

ELSE
=MESSAGEBOX("Error initializing cpwsconfig cursor in cpsetpath.prg!"+chr(13)+chr(13)+"CatalogPro cannot continue!",16,_screen.caption)
RETURN llret
ENDIF
CLOSE TABLES all
* CLOSE DATABASES all
llret = .t.
RETURN llret

 

[alisaif]

I would like to thanks all of you to clarify this key matter for me and will try my best to implement as stated by you fox guru. And, thanks to foxlover2012 for the code to describe the subject more clearly.

Saif