Conversion FPD to VFP?

[Freesoft]

I have an application written in FPD that consists solely of DBF's, related CDX's en PRG's. The application itself is still working correctly and no changes are requested by the users. It runs with compiled procedures. All the dialogs are handled by means of self-developed PRG's. Also the reports are self-developed PRG's. No builders and wizards are used and there is no projectfile.

Now we want to convert the application to VFP. My question is, is there documentation to be found for such a conversion? If not, can you tell me how such a conversion has to be handled and what considerations are to be taken in account?

Is it possible to maintain the currently technical structure of DBF, CDX and PRG? Or is it impossible to convert towards VFP without first creating separate Screen-dialog files and/or a projectfile?

And is there a desciption how to convert a dialog from FPD to VFP?

Thanks in advance!

 

[Nigel Gomm]

not tried with FPD but i converted fpw26 to vfp7/9 along the folowing lines.....


copy the prgs,sprs, dbfs and cdxs into a new folder
in vfp9 create a new project
add the prgs/sprs
build as an .exe

you'll be suprised how backward compatible it is.

look out for
set enginebehaviour
be careful of activate/deactivate code being triggered when a browse deactivates.
and disable themes - see sys(2700)


test thoroughly !


otherwise i'd start from scratch.

nigel

 

[TamarGranor]

I suspect your application will run as is, or nearly as is, in VFP 9. That said, it might be quite ugly, so you may want to start working toward switching from hand-coded windows to forms.

Tamar

 

[Freesoft]

Tamar, thanks for the advice, but is there a description or overview of how to switch from hand-code PRG's to forms? And what are the items/measures to take in account?

Freesoft

 

[Stella740pl]

You don't simply switch from manually coded DOS user interface to forms. You start them from scratch. (It shouldn't be that hard with all the visual technology.)

If you are lucky and your application has separate modules for business logic and for user interface, you may keep the business logic part and replace those interface programs with your new forms. If they are messed together, you will have much harder time separating them yourself.

Also, you may be able to keep your DBF and CDX files intact, most of the time they will work OK in VFP. Or you may create new identical structures under VFP and COPY TO your files into them; or SELECT from your files into new ones. Those new ones will be VFP tables.

 

[Freesoft]

Ok, thanks but is it also possible to maintain the handcoded sources and convert them to "new" handcoded sources in stead of creating forms for them? Sources that run in VFP and look like as if they are generated by means of the builders/wizards.

I am looking for a checklist/description how to handle such a conversion.

Luckely, the business logic and user-interface programs are located separately and are separate modules.

 

[Stella740pl]

You see, yes, you can handcode a form - but it is a completely different animal from handcoded DOS user interface, and they are not just magically transform into each other.

You can keep your hancoded DOS interface; it will work (you said it does, right?), but it will look and feel just what it is - DOS app.

Or you can create new forms with Form Designer (it is much easier than handcoding them), and then use them to call your business logic programs. (Even though your business logic code is outdated, too, it will work - if you are careful tying it into your new forms. For example, you might need to change all the table openings to use aliases or be very careful with numbered work areas when/if opening a table from a form.) You handcoded reports will likely work, so keep them as-is for now.

Or you can try to keep the original programs for now, make copies from it to different directories, and gradually work on the conversion on the side.

I don't have a checklist for the conversion, it was too long ago since I handled my last one (from FPD to FPW, then another one from FPW to VFP - which is not the same as converting directly from FPD to VFP). But I would start along the lines of what nigelgomm suggested.

Make copies into a separate folder(s) to use for the conversion. Sort/look through the programs to see if the business logic is separate from the interface.
Create a project file, and check your programs in it. Build an .exe and see if it works and how. You can convert tables to VFP as I mentioned above, if you wish. See nigelgomm's cautions as for SET ENGINEBEHAVIOR, etc., as some old SQL code may stop working in VFP9. Start with creating forms/menus one by one, and tying old code into them, and see how it goes.

 

[TamarGranor]

As Stella said, you can use hand-coded forms in VFP, but I strongly recommend against it. You'll spend much, much longer creating forms by hand than you will creating them with the Form Designer. This is one of those times when it makes sense to go with the flow and use the tool as it was designed to be used.

As for guidance, I recommend Whil Hentzen's book "The Fundamentals." It's no longer available in printed form, but you can buy the e-book at

http://www.hentzenwerke.com.

Tamar

 

[Imaginecorp]

Now we want to convert the application to VFP.

My deepest sympathies :} have done quite a few (DOS - VFP)

is there documentation to be found for such a conversion?

No.. at least not that I am aware of

Is it possible to maintain the currently technical structure of DBF, CDX and PRG...

Yes. (DBF & CDX) I would advise you to put them in a database container as this will add more functionality i.e. Views, Stored Procedures, Rules etc etc

Or is it impossible to convert towards VFP without first creating separate Screen-dialog files and/or a projectfile?

Nothing is impossible; you are only bound by your imagination. But like others have said, Without VFP Forms ("Screen-dialog"), your app will run but it will be "DOS in a window" Also by using Forms you will cut the code down by at least 60%. It would be silly to "hand code" forms as the code is a little more complicated i.e. Properties and Methods
A project file is just to "keep" everything in one place and easy to access...

can you tell me how such a conversion has to be handled and what considerations are to be taken in account?

Most Important Your Skill as a programmer.
You or whoever is doing the conversion should and must know the DOS app like the back of your hand (so you can reuse the DOS Code already written, in methods like Valid etc.
Second: You or whoever is doing the conversion has to be a "Pretty Good" VFP programmer. Again by using the "new" and innumerable functions, you can reduce the existing code and finish this conversion on time.

There are plenty of good people here to help and guide you once you get started Or better still hire somebody to do it for you...will be cheaper in the long run

 

[iolair]

We converted from FPD in 1993 to FPW 2.5. All our code ran without recompiling. We also converted from FPW in 2001 to VFP. Again, all the code ran without too much problem. I will say, that we have a same database though. Even now, the largest table has only 500,000 records. We've made changes as business requirements have demanded it, and we've also made some cosmetic changes, but a lot of the original DOS code is there and running just fine.

Iolair MacWalter
Network Engineer

 

[NasibKalsi]

To add a bit to the above:

a. Get the feel of it buy buying the vfp 9.0 sp2, you will be in a better position to make a decision after you view the new look and feel of the product.

b. In case you decide to compile the code in its current form, and want to switch back and forth between new and old versions, then put this line on top of your main program

set cpdialog off && read more in the help file

to keep the tables in their original form.