FoxPro File Associations and Working Directory

1) PRGs are open for editing in VFP development version. That's OK because the development version is primarily derived for coding not for the app run.  You have to reference FXP (compiled PRG) in the Scheduled task.

Of course, the correct approach is to create an EXE from your PRGs and execute these EXEs under VFP run-time module.

2) Do you use some configuration file (CONFIG.FPW) ?

Independently on the answer you may place following command at the beginning of your PRG:

SET DEFAULT TO JUSTPATH(SYS(16))

and the directory will be changed to the one you expected.  !! This command must be in the main program not in some procedure !!  (Procedure would require different command.)

Open is the normal DDE action for PRGs, running a PRG is not foreseen. What could run is an FXP, but compiling an EXE to use for the scheduler would be the ideal solution.

The default actions for the file extensions on your previous server have been changed, obviously, this is nothing you could fix with /regserver for sure. No change of working directory is closely coupled to that, too, for sure. You could change directory via prg modifications or start a lnk defining the correct working directory.

Are you sure you started prgs on your old server, anyway? It's not very likely.

Bye, Olaf.

Yes, the old server called both PRGs and FXPs. I have no problem changing the scheduled tasks to call FXPs instead of PRGs (making problem #1 irrelevant).

The big issue is that I have to get the default directory corrected via the environment. Somehow that was done on the old server but on the new one it seems to be ignoring the "Start in" directive.

So what we would do is call the FXP in lets say D:\Files\Programs and we would want the "Start in" to be D:\Files. But when it calls the FXP, the CURDIR() is D:\Files\Programs.
screenshot.jpg

I don't know how you could correct that from outside, but the one line of code Pavel suggests is easy enough to apply, isn't it? I'd take that as the solution instead of investigating ho that worked on the old server. All I know is a lnk setting of the working directory would solve that, and perhaps a general config.fpw would solve that, too.

Bye, Olaf.

Well yes it would be easy if we weren't talking about as many programs as we're talking about. The bottom line is the scheduled task should be taking the 'Start in' parameter but it isn't.

It's apparently ignoring the config.fpw files I've tried as well. I've got about 10 of them on the server in various locations setting DEFAULT="D:\Files" and it isn't working.

You could set "Default Directory" in the "File Location" Tab of the VFP9 Options dialog, if it's always the same location and then save that via "Set as default" button.

Bye, Olaf.

We've also tried that. It doesn't appear to hold the location when the FXP is called. If you launch Fox, it's correct. If you launch the FXP, it's not.

To execute some PRG in VFP 9 you just need -SHELLRUN parameter in the command line:

"C:\Program Files\Microsoft Visual FoxPro 9\vfp9.exe" -SHELLRUN "SomeScheduledFile.PRG"

OTOH,  -SHELLOPEN  opens PRG for editing or runs FXP.

I hope it could be possible to change this assignment just once in the PRG file extension association in Windows Registry. I just don't have WS  2012 to point you to the right place. Older Windows allow to do this change in Folder Options dialog.

VFP 9 executed this way always uses CONFIG.FPW from its home folder. You may test it on a short scheduled program. BUT it ignores some settings. Reasons for that you will understand later...

If you use following setting in CONFIG.FPW

_startup = "d:\path\SomeStartupProgram"

then the program is executed and it may change the default folder. Unfortunately VFP changes it again to the folder where the SomeScheduledFile.PRG resides...

So the solution is to start your programs from the future default folder or to add SET DEFAULT command at their beginning. You can do it programatically for all of them.

Another option is to execute some new PRG and pass the old PRG as a parameter. The "new PRG" can set the default folder and execute the PRG passed as parameter.

Depends on you what is easier to implement. Wheter to change all scheduled tasks or to change all PRGs etc.

Last idea: try PATH="D:\Files" in a config.fpw.

I tested configuring a scheduled task via "start in", and that works in Win7 with VFP9SP2, so at least it's not the fault of VFP. Maybe ask a scheduled tasks expert, under which circumstances the "start in" setting does not work. I can't think of anything on the VFP side to hinder a default path setting.

Bye, Olaf.

>when it tries to DO a program within the program the task scheduler calls, the path is off >and it errors and stops

So you have DO \Programs\someother.prg inside your prgs?

Then you could solve that by adding D:\Files into the %PATH% windows environment variable or you create a PJX, add all PRGs by drag&drop int the project manager and use code references to do a search&replace with the full path.

I'd go for the %PATH% change first.

Bye, Olaf.

Great!

This works for me:

CONFIG.FPW in a folder from which it starts:
PATH = "d:\folderOfThePRGfile"
_STARTUP = "d:\path\SomeStartupProgram"

Program used in _STARTUP parameter:
SET DEFAULT TO "d:\DefaultRunningFolder"

The PATH partially worked, but not completely. I did finally figure out how to get it to use the DEFAULT= in the config.fpw file. If you just call the FXP in the scheduled task, it doesn't use the config.fpw (no matter where you put it). But if you put the FXP as a parameter and actually call the FoxPro EXE (not compile an EXE but call VFP9.exe with the FXP as a parameter), that works (it uses the options set up).

Actually I thought running fxps will start vfp9.exe anyway and therefore also load the config.fpw, if you store it in HOME(), but OK.

So, what's not working now? I think Pavel has found a way surely not as it was beforehand, but wouldn't that work?

I also still wonder, why Start In works for me, but not for you, but that probably has to do with Win7 vs 2012R2.

Bye, Olaf.

The default folder (or Start in) seems to be unexplainable. It does not even work on XP under some circumstances. It simply forces the default folder to the one where the FXP resides.

I would recommend to start just one PRG with one parameter. And FoxPro can decide about further processing based on this parameter. If you change the environment then everything you have to do is to update this one PRG.

Yea we'll give that a look, pcelba. That does seem to be the better way to do it.

Any issues with splitting the points on this one? You both helped out in my view.

What about applying Sergey Bereznikers reg "hack" to the file associations?

http://www.berezniker.com/content/pages/visual-foxpro/fix-vfp-file-associations-open-files-one-vfp-instance

It makes a nice change from default associations in that double clicking a DBF does open it in an already running Foxpro IDE, if there is one.

You might also change
HKEY_CLASSES_ROOT\Visual.FoxPro.Program\shell\open\command
to
"C:\Program Files (x86)\Microsoft Visual FoxPro 9\vfp9.exe" -SHELLRUN "%1"
instead of SHELLOPEN

Maybe that was a change you applied to the old server registry.

Bye, Olaf.

OK with me.

You should also think about an EXE creation because to use VFP9.EXE on the server means EULA violation in many cases:

2. INSTALLATION AND USE RIGHTS.  If you comply with this agreement, for each license you acquire, you have the rights below.

   a. General.  One user may install and use copies of the software to design, develop, test and demonstrate your programs.  Testing does not include staging on a server in a production environment, such as loading content prior to production use.

Scheduled tasks executed regularly on the server do not fit to "design, develop, test and demonstrate"...

Well, the registry hack worried me only in that some things are supposed to "open" (DBFs for instance), so that's the only reason I didn't go with that selection.

Also a good point, pcelba. I didn't realize that it couldn't be used that way. Thanks for pointing that out.

Thanks for the feedback guys.

>some things are supposed to "open" (DBFs for instance),
Each extension has it's own actions. so that wouldn't change behavior of all file types.

Sergey's reg file really is a nice one. It does things different in defining ddeexec entries, which allows that twist of reusing one IDE instance.

Bye, Olaf.