|
|
MIGRATION
Convert FoxPro 2.x Apps to Visual FoxPro Gradually!
It’s possible to keep applications running in both environments as you update and upgrade your code.
By Chuck Urwiler
During 1997, I spent several months touring the country, showing developers (and a few managers) how to convert their FoxPro 2.x applications to Visual FoxPro, based on a methodology that was conceived at Micro Endeavors, Inc. where I work. This let me take in some sightseeing, meet interesting people, and even find out a thing or two about how people have written FoxPro 2.x applications.
One fact stood out in each city I visited -- there are a lot of FoxPro 2.x applications out there! Folks are using these applications to run their businesses, or have developed systems that they sell to others. Many of these same people really don't want to upgrade to Visual FoxPro because if it ain't broke, don't fix it.
This made me wonder why the folks who attended my seminars were interested in converting to Visual FoxPro. The answer to that one was easy -- they have pressure from one or more sources telling them they must upgrade. For some, it's the fact that Windows 95 solves certain Windows problems, but causes some flakiness with FoxPro 2.x. Others told me that they must upgrade because they can no longer obtain the necessary support for Windows 3.x or FoxPro 2.x tools. Still others told me they need the technical advantages that Visual FoxPro easily provides.
It would seem that these are perfectly good reasons to jump on the Visual FoxPro bandwagon, but alas, there's still a large part of the FoxPro community who hasn't. In fact, a large part of the Fox world is still using FoxPro for DOS. Why? The most common reason I heard had to do with the steep learning curve that Visual FoxPro presents to the FoxPro 2.x developer. The new event model seems to stump plenty of folks. Many others have cited object-oriented programming as the biggest hurdle, followed by new data features thatappear to convert data to some new Visual FoxPro-only format. This brings to light the biggest fear that FoxPro 2.x developers have of Visual FoxPro. Many believe that all of their current code must be thrown into the bit-bucket and ask, "What good is this Visual FoxPro thing if I can't reuse all this code I spent years writing under FoxPro 2.x!?"
Many people believe the only way to move a FoxPro 2.x application to Visual FoxPro is to start from scratch. That means re-engineering the entire application. For some, this isn't such a bad idea, since you may need to redefine business processes and want to redesign the interface. Unfortunately, writing from scratch implies using the FoxPro 2.x application only as a reference. So much for leveraging the current investment in code!
Maybe you've heard all this before and are wondering where I'm going with it. Well, the developers and educators here at MEI spent time coming up with an incremental conversion methodology that does what every migrating FoxPro 2.x developer needs--reuses a large amount of your current code, while giving you a chance to learn about Visual FoxPro during
the conversion.
This article shows how your current FoxPro 2.x code can run under Visual FoxPro and how to approach a migration process.
Step one: Learn Visual FoxPro
This may be something you don't want to hear, but the more you know about Visual FoxPro, the easier the migration process can be. Now, before you start barraging me with e-mails that threaten my life, let me explain.
The "scary" Visual FoxPro features I mentioned earlier are of the utmost importance for a conversion project. For example, if you ignore the object-oriented programming features, you're basically allowing a FoxPro 2.x application to run under Visual FoxPro. You're thinking, "Is that so bad?" The answer is, "Yes, it is!"
While your application will be functionally correct, you'll be losing one of the greatest benefits for easier maintenance of your application--inheritance. You can simulate inheritance with the way Fox looks for files, but there's nothing more powerful and timesaving than an intelligent, object-oriented design that effectively uses inheritance.
Object-oriented programming is an important Visual FoxPro feature, but it isn't the only one you should learn. There are new data handling features and a significant number of language enhancements that can have a dramatic effect on your current FoxPro 2.x code.
Here's the real issue: Visual FoxPro probably seems a huge mountain to climb. So don't try to climb it in one day! Instead, focus on those features that are critical to opening the doors to the entire product. No matter what, to reach the top of the mountain, you have to put yourself through some training (whether self-study, a video, or hands-on training) and gain experience by working with the product. (Also, see "Learn-ing VFP -- The Top 10 List" in the December 1997 issue of FoxPro Advisor.)
Conversion steps
Once you've gained sufficient Visual FoxPro expertise, you can follow a simple formula that leads to a successful migration:
- Resolve code problems.
- Create directories.
- Perform a "source conversion."
- Convert a screen.
- Convert the code behind the screen.
- Repeat steps 4 and 5 until complete.
Sounds easy -- perhaps a little too easy, right? Well, it can be, depending on these variables that you need to ask yourself:
Do you need to have the FoxPro 2.x system and the new Visual FoxPro system running concurrently, possibly sharing the data and other files?
How complex is your FoxPro 2.x system? How many screens do you have?
How good is the code in the FoxPro 2.x system? Is it robust or fragile?
What's the framework for your application? Will it hold up under the "real" event-driven environment of Visual FoxPro?
Did you design the pieces of your application for easy replacement, or do your procedures try to do too much? In other words, how maintainable is the current code?
This isn't an exhaustive list, rather, it's meant to give you an idea of the number of variables that exist in a migration scenario. This article is intended to provide a set of guidelines you can follow to perform an efficient conversion from FoxPro 2.x to Visual FoxPro. Before showing you the details of this process, take a look at the advantages this incremental migration offers over a total rewrite scenario as shown in table 1.
Table 1: Advantages of incremental migration.
| Incremental Migration | Total Rewrite |
| Maintain one set of code for use under Visual FoxPro and FoxPro 2.x. | Maintain the FoxPro 2.x system that everyone is still using while you're trying to learn how to effectively develop with Visual FoxPro. |
| Migrate the pieces of your system one at a time. | Forced to get the entire system up and running before giving it to your users, you're typically under tight time constraints and pressure. |
| Learn Visual FoxPro while your users are getting their work done. | Get up to speed as soon as possible on Visual FoxPro while you're writing the entire system and maintaining the FoxPro 2.x system. |
| Keep a significant amount of your current code in the new to convert. | Throw away most of the old system, attempt to re-engineer everything, and system and convert only what's necessary or what you have map where FoxPro 2.x functionality exists in Visual FoxPro. |
Fix code problems
The first step is to resolve any code issues you encounter while running the FoxPro 2.x code under Visual FoxPro. You may be pleasantly surprised to discover that your FoxPro 2.x source code can run nearly unmodified under Visual FoxPro. But what does "nearly unmodified" really mean?
Visual FoxPro has two major differences that spell trouble for FoxPro 2.x code: FoxPro 2.x is a 16-bit application; Visual FoxPro is 32-bit. This means that if you're using any .FLLs or .PLBs with your FoxPro 2.x system, they must be replaced since Visual FoxPro can't use them.
The FoxPro 2.x API has been modified for Visual FoxPro. This could manifest itself as bugs or program crashes.
Libraries
If you're currently using third-party libraries (.FLLs or .PLBs) to augment FoxPro 2.x, you might be able to acquire a Visual FoxPro version of the library. However, be careful -- while the newer library may appear to be totally compatible, there may be subtle differences. Be sure to test thoroughly! If you're using a third-party library and the vendor doesn't have a Visual FoxPro version, you need to check the Visual FoxPro Help file to see if the functionality is included natively. Until you have the chance to do this, you can "stub" the library calls so your application runs without crashes. How do you do this? The SET LIBRARY TO command first looks for the named library file as an .FLL or .PLB. If this file is found, Visual FoxPro checks to see if it's a "good" library. If Visual FoxPro doesn't like the .FLL, it doesn't generate an error -- instead, it attempts to find a .PRG of the same name. You can take advantage of this behavior and create a temporary procedure file with stubs. These stubs should accept any necessary parameters and return required data, but not necessarily do anything useful -- you can do that later if desired.
An advantage to this method is that this modified code still runs correctly under FoxPro 2.x, an important feature if you must have your existing system and the new Visual FoxPro system co-exist. Just remember that you're attempting to get the system running under Visual FoxPro, which doesn't necessarily mean full functionality at this point.
Language differences
As far as any code differences go, there's a document (which was derived from the conversion seminar materials) on the Microsoft web site that can help. This document (found at http://www.microsoft.com/vfoxpro/mastering/) lists what's changed between FoxPro 2.x and Visual FoxPro. Once you've "fixed" your code to run under Visual FoxPro, you're ready to perform the next step.
Creating directories
Many people have developed their FoxPro 2.x applications using separate directories for programs, screens, menus, and other files. If you've followed this practice, these directories will help you, since a typical conversion requires separate subdirectories. This isn't so much for organizational purposes, but more for the separation of FoxPro 2.x files from Visual FoxPro files.
As you migrate your application, keep the original FoxPro 2.x files intact while your converted files are placed in a separate directory. This offers two benefits. First, it gets around the occasional migration problem of not being able to overwrite a file while it's in use. Second, it lets you continue to generate your FoxPro 2.x project, so you can reconstruct a screen's .SPR code, if necessary. If you modify your files in place, FoxPro 2.x stops building as soon as it hits an .SCX (or other meta-file) that it can't recognize (such as the "Not a Table/DBF" project error).
No matter how you've organized your files for FoxPro 2.x, you have new folders to create. First, you need to put all your screen files (.SCX, .SCT, and .SPR files) into a single directory. If you're one of the folks who put the screen builder source files (.SCX and .SCT) into a directory separate from the generated code (.SPR), you need to recombine these files into one folder. Typically, this folder is named SCREENS or something useful like that.
Then, you need to create a FORMS directory for your Visual FoxPro converted forms. This will house the new .SCX and .SPR files that are generated by the converters.
Once you've done this, you need to modify any SET PATH statements in your development and production code. You want the path under FoxPro 2.x to NOT point to the new FORMS directory, but only the SCREENS directory. However, Visual FoxPro should first refer to the FORMS folder, and then SCREENS. This ensures that when you build a project in either environment, each project looks for the correct files, and your projects will build without errors.
To set the path correctly in either case, put something like this in your main program:
IF "VISUAL" $ UPPER(VERSION())
SET PATH TO progs, menus, forms, screens, projs
ELSE
SET PATH TO progs, menus, screens, projs
ENDIF
This concept is only shown for screens and forms, but you can take it as far as necessary. Normally, you won't need separate directories for menus, programs, or other elements, since they typically won't be shared between FoxPro 2.x and Visual FoxPro.
Source conversion
You might be surprised to hear that you're now ready to distribute executables to a test group or your users. Of course, it's expected that you've worked out any code and library problems from the first step. Once things are running flawlessly under Visual FoxPro, you can build an executable and put it on your users' desktops.
What you must do to permit the building of an executable is create a new project for Visual FoxPro. You do NOT want to modify your current FoxPro 2.x project under Visual FoxPro. That would attempt to convert the project to Visual FoxPro format and also convert every file in the project to Visual FoxPro format as well! Converting every file automatically to Visual FoxPro format isn't exactly a manageable migration scenario.
Instead of performing this drastic multi-file conversion, you need to create a new, empty Visual FoxPro project and add the appropriate files. In other words, after you make the new project, add your main program, rebuild the project, and then add any other source code files that are not automatically pulled in. Note that you should only add code files, such as .PRGs and .SPRs. Don't add any meta-files to the project since they're all in FoxPro 2.x format. Adding these files makes it too easy to accidentally convert them to Visual FoxPro format. This process is what MEI calls a "source conversion" -- your FoxPro 2.x source code is unchanged, yet you have "converted" to Visual FoxPro.
(Incidentally, every version of Visual FoxPro 5.0 is the professional edition; therefore, unlike FoxPro 2.x, you don't need to purchase an additional distribution kit to ship executables to your users. )
Once you've built this Visual FoxPro project, you're ready to let your users have it. Keep in mind that your screens won't be as snappy as they were under FoxPro 2.x. This is because Visual FoxPro must use a READ-compatibility layer to run your FoxPro 2.x screens. There can be a significant amount of overhead in this layer; however, the performance problem is in the initial display of the form, not the operation of it.
The performance of your data-handling code should either stay the same or increase. Occasionally, this performance increase can be dramatic. This is due to many factors, but mostly it's the result of Visual FoxPro being a 32-bit application. Since it runs under 32-bit operating systems (Windows 95 or NT), it can take advantage of the speedy disk and file access these environments provide.
By creating this new Visual FoxPro project and giving your users the resultant executable, you're accomplishing a big task. This lets you ensure that the users' systems are configured properly for Visual FoxPro, and gives you the chance to work out any hardware and OS issues. Keep in mind, this is best served by first having a test group of users work on it to minimize the effects of any problems that may occur.
The hidden advantage to this step is the ability to still build and ship a FoxPro 2.x executable as well. Since you're simply running the source code (.PRGs, .SPRs, .MPRs, etc.) under Visual FoxPro, it isn't necessary to convert any .SCX or .MNX files. This will allow your FoxPro 2.x project to build without nasty show-stopper errors.
This is an important advantage to those folks who need users to run the "new" system, while others are still running the current FoxPro 2.x system. You don't want these users accessing different data, and you certainly don't want to maintain two separate yet similar systems!
Data issues
Assuming that many of you will need to share data between a current FoxPro 2.x system and a Visual FoxPro system, there are a few matters of confusion that should be cleared up. The most important is that you can share data between these two environments, but not without limiting what you can do with the data in Visual FoxPro.
Visual FoxPro would like to add some bytes to the header of your FoxPro 2.x tables, but only does so when two conditions are present: the FoxPro 2.x table is open exclusively, and you attempt to modify the structure of the FoxPro 2.x table under Visual FoxPro.
What's surprising to most FoxPro 2.x developers is that a FoxPro 2.x table can be PACKed or REINDEXed under Visual FoxPro without modifying the structure. However, you can't add fields, change their width, or otherwise modify the structure of a FoxPro 2.x table under Visual FoxPro without it being converted.
Therefore, you can, from either version, open tables, browse them, edit records, add new records, and the tables remain in their original format.
If you do happen to change a table that needs to work under FoxPro 2.x, you can use the FOX2X clause of the COPY TO command to make a 2.x version of the converted table. Keep in mind this creates a new copy of the table, so you'll need to remove the Visual FoxPro-version table once you've verified the success of the COPY command.
Convert a screen
Once you've resolved your code and data issues, you're ready to pick a screen and convert it to Visual FoxPro format. By converting it, you'll be able to modify the screen as a true Visual FoxPro form and start taking advantage of the features that only Visual FoxPro can provide.
Most likely, you want to reuse as much as possible from your current FoxPro 2.x screens. This includes the snippet and procedure code, as well as screen elements, such as labels, text boxes, and command buttons. Visual FoxPro supplies two converters, known as the Functional and Visual converters. These converters are meant to create Visual FoxPro forms from your FoxPro 2.x screens.
The Functional converter actually creates a functional form that requires little or no modifications. The Visual converter creates an interface similar to your FoxPro 2.x screen, using Visual FoxPro objects. However, with the Visual converter, the form is non-functional.
There's one major drawback common to both of the supplied converters: If you don't have an .SCX from which you generated your .SPR code, you're out of luck. These converters read the FoxPro 2.x .SCX file directly and create a new Visual FoxPro .SCX and .SPR, replacing the old versions. This means those of you with hand-coded screens are completely without a path to Visual FoxPro forms, and redesigning is your only option.
If you do have an .SCX, choosing which converter to use might seem a no-brainer since no one wants a non-functional form. However, the Functional converter doesn't create a true Visual FoxPro form. Instead, it creates a READ-compatible form that compromises the performance and usability of the form. On the other hand, the Visual converter creates a true Visual FoxPro form -- that doesn't work. Plus, it requires that you sufficiently understand Visual FoxPro to correctly place the code to make
it functional.
Once again, your options are limited, depending on your knowledge of Visual FoxPro. If you're comfortable with Visual FoxPro and its capabilities, use the Visual converter to create the "shell" of the form, then fill in the empty spaces with as much of your original FoxPro 2.x code as possible. Alternatively, you can use the Functional converter, then attempt to remove the FoxPro 2.x-compatible features.
The best solution here is one that most FoxPro 2.x developers won't be able to execute: Create your own tools to either perform the screen conversion or to augment the supplied converters. MEI has created its own tool that cleans up the junk the Functional converter leaves behind.
I'm sure that none of this appears as good news, since every option listed here requires proficiency in Visual FoxPro. However, that's precisely where the previous steps have helped you! Since you need to learn something about Visual FoxPro regardless, it might as well be after everyone is running it. Even though everyone is running mostly FoxPro 2.x code, all your users are using this "new" Visual FoxPro system.
Convert the screen code
Keep in mind that converting a screen actually takes two steps. The first step is creating the visual portion, where @...SAY statements are converted to Visual FoxPro label or text box objects, and @...GET statements are changed to Visual FoxPro command buttons, text boxes, list boxes, and so on. Both of the supplied converters can handle this step for you.
Once the appearance of the form is adequate, you must create the functional portion of the screen so the command buttons work, text boxes display the correct data, and so forth. What's easily forgotten in this step is that any data-handling code can stay as-is. The only exceptions to this rule should've been fixed in the first step, where you corrected any code incompatibilities with running the FoxPro 2.x code under Visual FoxPro.
The code that needs to change is the screen-handling code. For example, instead of using the SHOW GETS command to refresh the data in your controls, you now use the Refresh method of the form (ThisForm.Refresh). You need to change this because Visual FoxPro objects aren't GETS, and the READ command no longer exists.
As you might imagine, this part of the conversion process can take the longest amount of time, since you must learn how to code FoxPro 2.x statements in Visual FoxPro. However, once you convert your first screen, you can use this acquired knowledge to convert subsequent screens with greater efficiency.
Repeat as necessary
Once you've converted your first screen into a Visual FoxPro form, put it in front of your users, so they can break it. This lets you test whether your code is solid, and gives you a chance to make corrections. Another advantage is hidden here as well. Since you've only converted one screen, the entire system doesn't (shouldn't!) crash if there's a bug in the newly converted form. In other words, any bugs should be isolated to the freshly migrated form, giving you the chance to fix the problems while they're in their infancy.
Here's where knowledge of Visual FoxPro is of great assistance. Since Visual FoxPro is a true object-oriented programming language, you can create a set of classes upon which you base your converted screens. This lets you inherit any bug fixes you apply. Why should you care about this feature? Classes are easily compared to templates, but with better features. I like to use the word "blueprint" to describe what a class is. To get you up to speed, here's a quick lesson in classes, objects, and inheritance.
Imagine you want to build your dream house. To get an accurate representation of the house you wish to build, you must have someone draw up a blueprint of the house. This blueprint
defines where walls, windows, and doorways should go, as well as other aspects of the house. The problem is, you can't live in a blueprint! You need to have someone build a house
from the blueprint, so you take this house definition to some builders, and pay them lots of money to build the house.
If you can picture this scenario, you've just learned an analogy between classes and objects. The blueprint is analogous to a class, while the house you build from it is analogous to an object. But what does this have to do with programming, especially migrating a FoxPro application?
Imagine now that you've lived in the house for a few weeks and discovered a few flaws in the design. To correct these flaws, you have to draw up some new plans, and then find someone to execute the fixes defined in the plans.
In the world of object-oriented programming, it's a lot easier than this. When you find that you want to change how the object works, it's a simple matter of changing the class that the object derives from. In other words, you simply modify the blueprint, and all the houses that were built from that blueprint are automatically changed! This is the miracle of inheritance, a characteristic of object-oriented programming that can significantly reduce the amount of code maintenance.
Disadvantages
Now that you've read through this conversion process, it's time to show you the disadvantages of incremental migration in comparison to a total rewrite (table 2).
Table 2: Disadvantages of incremental migration.
| Total Rewrite | Incremental Migration |
| Chance to build a new foundation. | Basing a new system on a possibly fragile foundation. |
| The new features of Visual FoxPro are built in from FoxPro are built in from the start. | New features of Visual FoxPro are plugged in. |
| Any patches from the current system are eliminated. | Most patches from the current system will stay in place. |
| Entire system is based on your own classes your own classes. | Only the screens you convert are based on your own classes. |
Summary
The conversion of a FoxPro 2.x application to Visual FoxPro doesn't have to be a difficult process. With the right plan of attack, you can take your time to migrate the application on your own schedule. And while you're migrating, you can learn about those Visual FoxPro features that are most important to you and your project.
Chuck Urwiler is a Visual FoxPro developer, courseware developer, instructor, and conference speaker with the Training and Courseware Group at Micro Endeavors, Inc. (MEI). MEI is one of the nation's leading training firms, delivering quality training in Microsoft Visual development tools and BackOffice products to over 10,000 students. MEI is also a leading consulting and software development firm serving the development needs of government agencies and Fortune 100/500 clients. Visit MEI at http://www.microendeavors.com/. ARTICLE INFO
 FREE ACCESS
Keyword Tags: Database Development, Microsoft, Microsoft FoxPro, Microsoft Visual FoxPro, Microsoft Windows, Migration, Programming, Training
|
|