Having been through the "exercise", I can tell you how
I approached it (Note: "APPROACHED" ~= "solved"
.
The app was actually done originally in a UNIX based Basic language and 'converted to VB 1.0. I was given the task of conversion to VB 6. The basic app consisted of ~~ 50 forms and 0ver 100 standard modules. Additional requirements included that the data portion mirror the data portion of a companion product which was also being updated (from vb 4 to vb 6). Discussing the 'companion product' I was imnformed that the db was AND WOULD REMAIN BTrieve flat file tables.
I could was able to at least see the forms and revivew the functionallity of the app in the executable . I reviewed the existing 'code' (after finding a third party who was able to actually find and provide a copy of VB 1.0). The 'strategy" I developed was to build a large parseing engine to simply read the source of each object in the VB 1.0 format, replace the obsolete objects with propperly formatted VB 6. objects and write the revised objects to a new 'directory'. After a conversion or (several) to at least be able to get through the porcess, I 'built' a VB 6 project based on the objects which weere in the converted directory.
Of course, one MIGHT guess that the process then became somewhat less clear. Obviously, in attempting to even load the 'new' obj3ects into the new projects, there were some 'new' issues to address, so these needed to be resolved - which meant another cycle therough the parseing engine to replace invalid constructs with their (hopefully valid) equivalents. While I do not have any actual dates, memory sugggests that this phase lasted a few months, until (sigh - AT LAST!!!!!) there was a project which would load and compile w/o errors.
This, was expected, was simply a minor waypoint in the trail. VB 1. was generally used in a time frame where screens were 40 lines by 80 characters, providing VERY limited display space, so a LOT of the code was simply to change the position and/or visibility of the controls. These were all required to be 'sorted out' and either re-arranged to suit on a single display or grouped onto Tabs of a tab strip and then remove the code to change hte position and visibility. This required another 'parseing' exercise, and additional month or so.
Further exercises included the addition of error handlers to many of the routines, development and implementation of class modules to handle the db transactions, removal of redundant procedures to common maodules, additions of extensive verification and validation code for data entry/edit of database values (In the 'original' data sets, I noted ~~ 10% of the records had at least one field where the data was invalid).
I believe there was a 'testable' version available at the end of ~~ 5 months (again, going on somewhat faulty memory). Placing the APP into alpha testing revealed some issues but was largely 'successful' however the tester was not the as aggressive as I would have liked, and had 'other responsibilities' which were his priority, and the formal testing seemed to not find as many issues as I discovering in my own informal 'playing' with some dummy data.
Not so long after the start of hte ALPHA tests, the company suffered a disasterous financial event (a customer wet bankrupt - costing the company well over a years worth of profit. I was retainied -in the vain hope of recovery- but reassigned to other efforts, and -while 'complete', the product never made it out of alpha testing.
In the grand glare of 20-20 hindsight, there is little that I would have done differently -IF I were to have accepted the task. I would have perhaps emphasized the parse-replace cycle a bit more, and attempted to extend that cycle further, looking into additional functions which could be 'replaced' programatically and perhaps attempting to identify redundant and unused procedures at an earlier stage. Another possability would be to explicitly identify each reserved word in VB 1.0 and check that the syntax and arguments matched EXACTLY between VB 1.0 and VB 6, and specifically identify any which were / are different as tarrgets of the parse / replace processes.
Finally, I would advise others to consider the size of the overall effort. It may easily be easier to 'build' an entirely new app based on requirements analysis and / or technical specs. This was a non option for me, as the reqiuirements and specs were co-resident in the single statement "make it work like that one".
MichaelRed
m.red@att.net
Searching for employment in all the wrong places
