>Hi All.
>
>Advice sought. I have run into a situation where a faily complicated FPW2.6 application needs to be converted to VFP6. The original developer cannot be contacted. There are no design documents or analysis materials. The project contains 40+ screens and 100+ program files (most of which are one procedure wonders). The process owner does not want to invest any time in re-engineering the functions of the application....wants a straight port.
>
>In general, what approach would you all take? I'm looking at, maybe, a functional decomposition and then re-engineer the myriad little PRGs into functional custom classes. Maybe not, though.
>
>Any words of wisdom?

We have a Clipper-based app. in use that was just ported to VFP by the original programmer. He took the direct approach and tried to shoehorn all of his original code into VFP. About half the screens are still @ 10,2 SAY-based. The other half are Windows-type screens. All in all, it's pretty ugly. Both the code, and the visual aspects of it. I don't think it's usable at all, so we've (I've) decided not to update them to Windows just yet.

Since I'm not under any real time constrants, and pretty much have final say on how we proceed, I think the app will be a complete rewrite of the original application. There is just too much baggage associated with trying to support the original design. Hopefully that isn't the case with your app.

In the meantime, since I've been writing VFP code that uses the data produced by the Clipper app. I took the route of a functional analysis of the .PRG's to VFP classes. I ported some of the main routines only (since I'm not doing a full conversion). So far, this has worked out much better. The code is clear, I understand what is being done, I actually comment my code (unlike the original program which had very little commenting), and it's easy to use. I think this would be the route I'd take if I had to do a direct port.

Keep us updated on your progress. I'd be interested in hearing how it works out.