The last few articles have discussed what do you have, both in terms of resources as well as your current situation. the logical followup is, "Now that you know what you have, what do you want to do with it?" More specifically, what is your goal.
You have a variety of options, ranging from "do as little as possible" to "a complete upgrade". Yeah, I can see you cringing already.
Do as Little Work as Possible
At first glance, those six words look like the most attractive choice. The goal here is to save time and money, kind of like putting as little cash into your old clunker of a car, trying to get one more year out of it before having to buy a new car.
And i appreciate the intent; my middle child is headed off to college shortly, and he's only seen me drive one car his entire life. Nothing wrong with trying to eek out as many years from an investment as you can.
On the other hand, there's a trade-off. Every few years I need to throw several thousand dollars into the clunker, anywhere from new brake lines and replacement of all hoses and belts, to an engine overhaul. One of these years, the money I'll need to put into the beast will be more than it's worth, and it'll be time to look for a new set of wheels.
Same thing here; what's the least amount of patching can you do to your current application before it finally gives up the ghost and you need to replace it.
So your mission is to do as little work as possible to get your application to run in Visual FoxPro, thus giving it a few more years of life. Use as many workarounds as possible, assuming that maintenance will be minimal, and thus clever kludges will come back to bite you infrequently.
For example, in 2.x, an SPR created private variables that were then visible to the entire screen and the subroutines called by the various controls. The draconian among us would insist on converting every variable to a form property, and then rewriting all code to refer to those properties, with the resulting hijinks that ensued from scope issues. A quick and dirty workaround would be to write a wrapper that defined all variables as visible to the form being called.
Do a Minimal Conversion
A little bit further along the continuum is to refactor code as minimally necessary to be more "VFP-Like", to intentionally avoid workarounds, but not making changes solely for purists sake. For example, convert forms properly, working with form properties instead of global variables as a workaround.
On the other hand, suppose you had a routine that looks like this:
do while .not. eof()
store allt(title) to m.title
store allt(position) to m.position
do while .not. eof()
set rela to jobcode into emps
Why bother rewriting all that code into something more SOL-compliant? If it works as a black box, leave it alone.
Do a Complete Refactoring, but no Upgrade
Yet further along the line is the decision to do a complete refactoring of all code to use VFP's capabilities that are needed to replicate the existing 2.x application, making it 100% VFP. However, don't add new features, such as DBCs, auto-incrementing PKs, or Report Adapters.
The far end of the spectrum is to overhaul the entire application, as if it was being written from scratch, using every feature and capability that VFP has to offer.
In the next article, I'll start to get into the nuts and bolts of how to upgrade specific components of a 1/2.x application. Stay tuned!
Naturally, if you can't wait, or if you already know you want a hand with upgrading your application, anywhere from occasional mentoring to full scale development, please contact me directly at whil /at/ whilhentzen.com.
Want to be informed when the next article is ready? Sign up on our new mailing list here. You'll be asked to confirm your being added to the list and then you're all set.