Upsizing and VFP  
Author Message
mvermef





PostPosted: Visual FoxPro General, Upsizing and VFP Top

I currently have some software that was originally created in the dark ages of Fox, my task is to upsize (make it more marketable) and use Sql Server as the backend. The tables are all upsized roughly 580 of them (ugh!!). Out of that 580 most of them are look ups.

Venturing back to the software, the original developer was either a hobbyist or someone who loved job security because there is little or no comments in spaghetti she wrote. Also she wrote her own procedure for handling data calls (this is good, at least at first glance for me since I think I can get it to connect to sql backend without to much work) except that I can't get it "DO" without errors on run, errors related to file locations that don't have files since they are procedures in another prg file she used the SET command on

set procedure to jbprocs && file she called not sure what the meaning of JB is but oh well, might be her initials now that i think about it...

jbprocs was set at the part of "main" call file before the rest of the app is initialized

anyway I tried moving the problem procedure to its own file but it made no difference not sure why.

Also, I am more of C# than a VFP developer so bare with me. Once we re-release back to the folks already use the software, we plan a rewrite in asp.net


Morgan Vermef
pcasoft.net


Visual FoxPro1  
 
 
AndyKr





PostPosted: Visual FoxPro General, Upsizing and VFP Top

Morgan

It is not quite clear what you are asking here, is the issue that you need to reference a procedure that is defined in another file

If so, the answer depends on the version of Fox you are using. Prior to VFP 3.0 (i.e. in FoxPro DOS or FoxPro Win 2.6) you could only have one procedure file set at any time. So if you needed multiple files you had to load/unload procedure files during run time. Since the introduction of VFP, this restriction has been removed and you can use the ADDITIVE keyword for SET PROCEDURE to load multiple procedure files into memory.

Typically the code used looks something like this:

IF NOT "MYPROC" $ UPPER( SET( "PROCEDURE" ))
SET PROCEDURE TO myproc ADDITIVE
ENDIF

Once loaded, the procedure file (and all its contained procedures) should be available without further qualification.

If you do not want, or cannot use, multiple procedure files, another option is to use the IN clause of the DO command to specify the location of the desired program (for all the options and ramifications see the help file) The basic format is simply:

DO myroutine IN myextras.prg

Providing you have a search path set you do not even need to specify the file location, merely the name.



 
 
CetinBasoz





PostPosted: Visual FoxPro General, Upsizing and VFP Top

(Disclaimer: Analogies between .Net framework and VFP is not one to one match, similarity and unofficial)

In C# when you compile a solution (VFP project - "solution" do not exist) the result is an exe (PE) and even if you delete all the source files it'd run. PE knows the file locations (more precisely it doesn't need locations/files anymore). In VFP files are compiled on the fly and run (but compiled files are not in a single exe unless you build an exe). That means VFP needs to access source or compiled versions if you're not running an EXE (and I assume you're not running an EXE, trying to run it from within IDE with something like "do main.prg").

Like C# IDE's solution explorer, VFP's project keeps track of files' locations. However if you:

do main.prg

and a line refers to a file that's not in current 'search path', project wouldn't help it to locate the file (you're somewhat running it independant from project, project knows the place but it just isn't helpfull). For example at a line:

set procedure to jbprocs

would error if jbprocs.prg is not in 'search path'. And it's not different than you're trying the same line at comman window (VFP is an interpreted and interactive language - you could execute each line in command window, except loops which require to be executed in blocks, simply that's doable too but beyond this message).

To workaround this is fairly easy and can be done in more than one ways:

1) VFP uses 'search paths' to locate files. It's a combination of VFP's own search path and DOS search path. This is generally the easiest and preferred solution.

-Open the project and note the files' locations. Say files are in "c:\my Path\Forms", "d:\my Path\commonProgs" etc.
You can build a search path separating paths with a semicolon and keep it in a prg file to restore on demand. Go to comman window and execute:

_cliptext = set("path") && VFP's current search paths
modify command myPath && create a prg which you can run whenever you want to set paths for testing

Paste in code window opened and after putting a semicolon at the end add yours that you noted above:

...;c:\my path\Forms;d:\my Path\commonProgs

Ctrl+W to save and exit.

Do myPath

or:

myPath()

would set those search paths. Now you can run your app with do main.

2) You could hardcode the paths (and no need to explain to a developer what a worst choice it would be to hardcode paths but it works and I wanted to note that workaround too:)

set procedure to ("c:\my Path\my Progs\jbProcs") && VFP is case insensitive and for a procedure file .prg is default extension

3) Yet another quick and dirty solution, you could create a test folder and copy all project files to that single folder. Change your current directory to test folder:

set default to ("c:\My Work Path\Test") && or: cd ("c:\My Work Path\Test")

and run do main.prg. VFP wouldn't complain not finding the files this time because due to VFP's behavior even if a file's path were hardcoded, it uses the file it finds in its search path when it cannot find it in hardcoded path.

As you, I think jbprocs is named that way because the developer had initials JB:) I use cb_ similarly in different places (like property names to differentiate from built-in ones). You can think of it as a way to 'invent' namespaces:)

PS: (this is easy to say but not as easy as to do:) Can't you directly do a rewrite with ASP.Net, windows forms and web services in mind from the start Upsizing VFP's data (especially with VFP's own upsizing wizard) to SQL server w/o rearchitecting might be inefficient. I don't know, just thinking, within context of many new features of SQL2005. Even with SQL2000 I was writing my own upsizing with rearchitecting (and own code generators to cut down writing all those .sql). Good luck, you have an hard task.


 
 
CetinBasoz





PostPosted: Visual FoxPro General, Upsizing and VFP Top

BTW you can get all the files locations in a project file in a single shot. A project file is a table named with an .pjx extension.

select name from myproject.pjx

With an OleDbDataReader and Path class it'd be a piece of cake for you to get all available filenames with their paths if you're more comfortable in C#.

PS: Path names might just have a filename meaning it's location is same as where pjx file is.


 
 
mvermef





PostPosted: Visual FoxPro General, Upsizing and VFP Top

Thanx for the great input. Another reason i said it the developers initials was she appeard to use her name in her encryption/decryption procedure for her license file she would make for customers purchasing the software. Kinda blew my mind..

Now back to the problem... So VFP that I am using is 9 the original was use created for folks in windows 95 or earlier iwth 12 inch screens so the main program window is hardcoded to like 640x480 (yuck), part of the task to release and start making money on the current code base to to make it resizeable as well work with the sql back end.

Now you also said that VFP uses its own path system as well as combination from the windows pathing system so I have to add to the path on my development machine the location of the source for this application

Morgan
pcasoft.net


 
 
CetinBasoz





PostPosted: Visual FoxPro General, Upsizing and VFP Top

640*480 was all we had in old days (and mostly not allowed to use 800*600), worse we had 80*25 character inputs only:) Resizability is easy and there are bunch of ready/free classes for that, as well as scrollbars/anchor etc support. Working with SQL backend is also easy with VFP.

Yes VFP has an "own" path + OS path. But I didn't exactly mean "you have to add to the path on your development machine...". I just showed you what ypu should do if you're testing it from within IDE directly. If you used other languages like Python the case there is similar. You add search paths. It's also same for say command line compiling. You can't just open a DOS command window and say "csc". You need to set OS search paths and VS command prompt is a ready one for that. Think with C# you need an external source and you don't supply the full path. You simply use its name and extension and you can use it even if it's not in current dir. Or with ASP.Net virtual directories as location identifiers etc. VFP similarly just needs to know where to find jbprocs.prg.

In a built VFP application (build an EXE from a project) VFP doesn't need that pathing for any one of its included files. Files are already within exe. For excluded (ones that are not part of exe - ie: tables) still need to be located some way. Either via paths or dialogs to enduser.

PS: I think you'd need help from a VFP professional nearby if you think to touch existing app. or use that as a basis checking its code. Otherwise just check screens and flow to rearchitect for .Net. Don't take this wrong. That's what I do for VFP applications even if I know the VFP code to its last byte (but how many developers tend to write from scratch).