Solved

FoxPro File Associations and Working Directory

Posted on 2014-04-23
22
1,277 Views
Last Modified: 2014-04-24
I have recently migrated FoxPro to a Server 2012 R2 environment. This server has many scheduled tasks that run and it's having issues.

1. First off, PRG's don't execute when they're referenced in the scheduled task. It only opens them for editing (which is wrong)


2. Secondly, when the scheduled task executes, it's ignoring the 'Start in' directive. All of these programs need to start in the directory above where the program actually resides, but for some reason it's ignoring that. So when it tries to DO a program within the program the task scheduler calls, the path is off and it errors and stops.


Any help fixing these two issues would be greatly appreciated. For the first issue, I have tried the VFP9.exe /RegServer and it doesn't seem to be changing anything.
0
Comment
Question by:street9009
  • 9
  • 7
  • 6
22 Comments
 
LVL 41

Expert Comment

by:pcelba
Comment Utility
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.)
0
 
LVL 29

Expert Comment

by:Olaf Doschke
Comment Utility
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.
0
 

Author Comment

by:street9009
Comment Utility
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
0
 
LVL 29

Expert Comment

by:Olaf Doschke
Comment Utility
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.
0
 

Author Comment

by:street9009
Comment Utility
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.
0
 
LVL 29

Expert Comment

by:Olaf Doschke
Comment Utility
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.
0
 

Author Comment

by:street9009
Comment Utility
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.
0
 
LVL 41

Expert Comment

by:pcelba
Comment Utility
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.
0
 
LVL 29

Expert Comment

by:Olaf Doschke
Comment Utility
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.
0
 
LVL 29

Expert Comment

by:Olaf Doschke
Comment Utility
>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.
0
 
LVL 41

Expert Comment

by:pcelba
Comment Utility
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"
0
How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

 

Author Comment

by:street9009
Comment Utility
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).
0
 
LVL 41

Accepted Solution

by:
pcelba earned 250 total points
Comment Utility
Yes, I've proposed the command line containing VFP9.EXE.  If you use just the shell assignment of the default program to PRG/FXP extension then WS2012 does start VFP differently. (Or it does not provide the -SHELLRUN parameter at least.)

Remember this behavior is highly OS dependent.
0
 
LVL 29

Expert Comment

by:Olaf Doschke
Comment Utility
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.
0
 
LVL 41

Expert Comment

by:pcelba
Comment Utility
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.
0
 

Author Comment

by:street9009
Comment Utility
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.
0
 
LVL 29

Expert Comment

by:Olaf Doschke
Comment Utility
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.
0
 
LVL 41

Expert Comment

by:pcelba
Comment Utility
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"...
0
 

Author Comment

by:street9009
Comment Utility
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.
0
 
LVL 29

Assisted Solution

by:Olaf Doschke
Olaf Doschke earned 250 total points
Comment Utility
Points split of course is ok. I think Pavel contributed more to a working solution, anywaqy how you split points is up to you and I don't remember any occasion of envy, here.

If you take that EULA conditions more serious ( you didn't as far) compilation of all the PRGs into one EXE would perhaps work and also get rid of the pathing issue, as you can DO somewrongpath/some.prg inside the EXE and it'll look for the fxp inside the EXE anyway.

You could create a main.prg taking the fxp you want to start first as parameter, then. About the same solution as Pavel already suggested, just calling your new EXE as start point instead of an initial SomeStartupProgram it's main.prg of that EXE.

Bye, Olaf.
0
 

Author Closing Comment

by:street9009
Comment Utility
Thanks for the feedback guys.
0
 
LVL 29

Expert Comment

by:Olaf Doschke
Comment Utility
>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.
0

Featured Post

How to improve team productivity

Quip adds documents, spreadsheets, and tasklists to your Slack experience
- Elevate ideas to Quip docs
- Share Quip docs in Slack
- Get notified of changes to your docs
- Available on iOS/Android/Desktop/Web
- Online/Offline

Join & Write a Comment

Creating and Managing Databases with phpMyAdmin in cPanel.
If you’re thinking to yourself “That description sounds a lot like two people doing the work that one could accomplish,” you’re not alone.
Video by: Steve
Using examples as well as descriptions, step through each of the common simple join types, explaining differences in syntax, differences in expected outputs and showing how the queries run along with the actual outputs based upon a simple set of dem…
In this fifth video of the Xpdf series, we discuss and demonstrate the PDFdetach utility, which is able to list and, more importantly, extract attachments that are embedded in PDF files. It does this via a command line interface, making it suitable …

728 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

9 Experts available now in Live!

Get 1:1 Help Now