Thought we haqd it...but...

[John Esak]

I thought we were done.  Eventually, after fixing glitches, extra stuff and pairing the calling batch script down to its most atomic needs, the program seemed to be "working" in all aspects.

Here is what worked, which btw, is the HelpFile suggested "correct" way to assign the filePro PATH variables in the situation we have - so that filePro itself can find the user designed filePro folders, and its own executables and config files.

The batch script should be self-explanatory if you know that directly under the root of the Y: filesystem root is a folder "\appl" and below \appl are "the two folders fp" and "filepro" both on the same level (y:\appl\fp and Y:\appl\filepro)
 .

@echo off

Net use Y: \\ds620-1\home /persistant:YES 2>NUL

set PFDSK=Y
set PFDATA=Y:
set PFPROG=\APPL
set PFDIR=\APPL

set PATH=Y:\appl\fp;;%path%

p.exe UserMenuName

As I said, this is as simple as it gets, and everything worked fine, and that was that.  Before that we had copied the entire "fp" and "filepro" folders from their previous location on another mounted (mapped) filesystem G:.  in order to have them be under Y:\appl as they need to be. (Y: is a new NAS array stack made by Scenology.) 

(Unbelievably, there was/is a *third* and *fourth* pair of filePro folders under the C:\ of the two computers which access this LAN (so on one machine c:\fp and C:\filepro, and the same for the second machine)   It's not worth commenting on this maze of filePro programs and data, it is just the way the gentleman did it, and it has worked that way for him for years, decades actually. He bought his latest copy of 5.0.14d9 in 2010. I had forgotten the strange licensing format and location for the license file for 5.0.14 but after a while, determined what used to be done in that regard, and it is the same authorizing key in all the fp locations.

Okay, if you've stayed with me. We were happy, but the man who runs the system was considering the suggestion I had made to consolidate all of his working "fp" folders into just ONE all encompassing "fp" folder somewhere. that would run the various datasets he has on different mapped drives.

While the above batch script *was* running, he had seemed to have some trouble with a new menu or something, and to isolate the actual location of the "menus folder that was being accessed, he put an "x" in front of the C:\fp folder on the first machine (the one he was running things from at the time.  Meaning, he was trying to make the C:\fp folder invisible to anything filePro-based by renaming the "fp" folder to "xfp".  Actually, a great diagnostic technique.

Guess what, and this is why I'm writing such a detailed explanation... the above batch script simply errored out with the message "This product has not been formally registered with FP Technologies..."  or something very close to that.  A big black screen, and then no going further.

Help me figure that one out, and we will be a long way into solving this strange PATHing problem.

Why is filePro checking in C:\fp for the correct license key?

Now, just to be really crazy, here is another piece of info that is sort of impossible.  After putting c:\xfp back to its original name c:\fp, the script starts working again (Quite obviously because it finds a C:\fp folder, (and maybe the license key there??  BTW, does the DRIVE you are running a batch script on have *anything* at all to do with what is inside the script???  I can't imagine that it does, but I do see on most Windows 10 machines a variable called "homedrive" set to C:.  Don't know enough about windows to know why this is there.

Meanwhile, after putting C:\xfp back to C:fp, more impossibility seems to happen.   when I had the gentleman enter the filePro Directory (the ? on the main filePro menu) and from there have him edit the config file that is being used, IT IS CLEARLY THE file "Y:\appl\fp\lib\config" and not the "C:\fp\lib\config" on the machine he is running the batch script from.

This means (at least it appears to mean to me) that filePro needs there to be a C:\fp folder for licensing up correctly, but then goes ahead and uses the "fp" location specified in the calling batch script! It seems to use the PATH variables as specified in the script in the first place... why doesn't it look for the license key there as well?!!! Very strange.

		So, that is problem 1.  This second one is part and parcel of everything above, but it is so outlandish, that nothing lets me give it much credence at all, he has shown me repeatedly that the "fix" he came up with below for the batch script seems to fix the problem!!!  However, as  you all can see, the PFPROG variable has been change to something that will NEVER allow filePro to find the correct location of the executables and other configuration stuff.  (Or, will it???? It works as we step through the file echoing each variable as they are constructed and filePro finds menus, filePro folders, etc., etc.   Maybe the PFDATA variable can be duplicated in the PFPROG variable??? And the program just uses the %PFPROG%\fp if it comes out to whatever it would have constructed itself?  Sorry, that's too convoluted even for my broken old mind... but I can not understand why the following, simple change to the batch script fixed the problem of not having a C:\fp folder, and DID NOT BREAK ANYTHING ELSE!!!

☹

Here is his fix:

@echo off

Net use Y: \\ds620-1\home /persistant:YES 2>NUL

set PFDSK=Y
set PFDATA=Y:
set PFPROG=Y:\APPL
set PFDIR=\APPL

set PATH=Y:\appl\fp;;%path%

p.exe UserMenuName

I'm not sure how *anyone* can help without a system (the system) to try things yourself, or make changes and test them as you go, but after weeks of trying to shoot this, I have no solution.  


BTW, the person running this 5.0.14d9 system did purchase it, it is clearly licensed to him and he is only operating it on his own home LAN.  Him being 6 years older than I am, and I'm 75! Tells me not to try and fix his system by telling him to just upgrade to something newer. For someone like myself who still, amazingly , helps legacy clients from time to time, I don't mind buying current copies of filePro.  It is the only fair and intelligent thing to do. 

However, this is something that I just don't understand about how the filePro internal PATHing works, and want to figure out just to stay conversant with how one would implement other even more complicated "virtual" installations.  .  The FP Web still intrigues me, and I'm doing some testing now on whether my latest screen reader can keep  up with enough of it to go ahead and get a copy, or just go with the latest version