>Man, what a story;

Did I see a tear in your eye :-)


>Before reading it carefully, I'll have another one, to get you confused ;)
>
>I know you will be using the build for now, so the next won't apply really, but you can give it a thought;
>
>From our early days, we have a construction for demo's, which anticipated on temporarily changing some functions of the app, possibly needing some data-structure changes too;
>Our one app -just like yours- is devided over many directories (over 50 or so);
>De tables (when native VFP) are addressed directly (i.e. with full path), but the programs are found via the path. The CurrentDir will always be the main app's directory (about 4,000 exe's (fxp's !) in there), and the subsystems are reached via the path (another 3,000 exe's scattered over 4 or 5 dirs for one consistent environment).
>
>Now our demo-construction, comprises of another directory (DemoDir or so), in which all adjusted programs and tables (and indexes) are placed, and which becomes the CurrentDir for the app. This will work at the customer's site obviously too. In the path the usual CurrentDir is added (leftmost), and the rest you can imagine yourselfl this is a means to override all what you want on a temporary basis.
>
>Sadly this won't work with the build, unless you start putting full path's in front of the DO's which all point to ... an unexisting directory. I never tried this, but I think it 'll work, and since the directory is empty it won't even slow down noticeable. Thus, Fox should find the program in the EXE (or APP) again. But, if the direcory contains some temporary adjusted program it will use that one.
>

I have tried something similar before but it was more in hook terms, I had distributed the EXE with a call to a PRG. This PRG can be same or different on machines.


>I don't think you will ever be using this, but it may possibly be part of your solution in the end.
>
>
>Note that there is another trick too, I myself was looking for many years, and only found it last year :
>
>For our framework we have this large Procedure, containing some 800 programs. This one is send to the customer as one big file (about 2,5 MB) and if therein something is wrong, it's hard to debug at the customer's site. Note : for you this will be always the problem, because you will have to rebuild and send all,

Actually the framework is a seperate .APP and actually in my EXE there is a stub procedure to start the main PRG in the lib, this stub has all empty function definations, these are in the main PRG of the lib as the current executing PRG is the LIB PRG these functions (actually there) are used, around 225 functions, then the menu boots in and rest are called from the EXE. Execution is like this EXE main stub file, calls the main procedure file of the LIB.APP this sets up the menu and becuase of the execution method both work concurrently. The main procedure file automatically becomes as if it is loaded in the memory using SET PROC. Yet I have SET PROC free for use on an apps basis (FPD25 remember only one SET PROC).


>possibly with some Wait's in there. The (obviously simple) trick is to have another copy of the program at the top of "the whole chain", which comes to having a copy of the one program as a function in a calling function. Litterally this comes to :
>
>Procedure XX
>Function F1
>xxx
>Function F2
>xxx
>Function F3
>xxx
>
>Now we have a program A1.
>In program A1 Function (f.e.) F2 can be put as Function F2 again, and because Fox will look in the current program firstly, it will find it in A1, and not in Prodedure XX.
>
>Sadly (and again) this doesn't allow a build, because you couldn't touch A1 without a rebuild. But anyway, maybe you can use this too.
>
>Regards,
>Peter