Ganasen, Boy, do I have bad news for you ... The bottom line is that rewriting is not a preferred way ..., it is the only way. The truth is that VFP and FPD are not the same language and under the circumstances, the best advise that can be conveyed to you by anybody who 'has been there' is that you have to face this simple truth and adapt your planning accordingly, including evaluating other languages. Do not get me wrong, (hey! I opted for VFP), VFP is the most probable alternative, but it is not the only one, depending on you application. I will try to answer some of your questions, assuming that you did, like most of us, remain faithful to the fox ... > > But in my circumstances time is a factor as these applications have been > written over eight years and are very modularised like an accounting > system > where the modules are interdependant. Changes in one module affect the > working of another module. The applications are very stable and are of a > very high standard in my opinion. To rewrite these applications will take > more than year aside from passing the VFP learning hurdle. > > The other factor is that ongoing development and maintaince is very high > in > the current fpd26 meaning that changes in the FPD26 must also be done to > the new devlopment as well. Keeping two versions of this product is a sure > failure due to the high business changes in the applications as the > products keep changing. > Investigate the possibility of remaining in FPD, and start developing small (independent projects) in VFP, to enhance you knowledge of VFP. When one is ready, one knows, and when you are, rewrite. It’s like ‘divide and conquer’. <snip> > Once this is stable in VFP we can then stop DOS FPD26 development and > continue in VFP with a gradual migrating of apps towards the VFP way of > doings things, building on the VFP experience. > In time we will rewrite all new apps using object orientation with VFP > data > dictionery and SQL server. > I think, and with all due collegial respect, that your main error of appreciation lies here. You would be much better off continuing your development in FPD26, because this would be much easier, and increase your abilities in VFP in a parallel way, than to try to transform your programs, and continue your development in a VFP application. You risk much more criticism from your users, because they may blame you for not being able to fulfil the changes at the same rate that you used to be. And on the other hand you will be faced with tremendous technical problems, of which I think you already have had a taste. The trouble is not to have something working in VFP (that could be done fairly easily and from what I read, you already have), but what happens from there. You will be faced with unlivable inheritance problems because the basic architecture of what you develop in VFP is different from what it was in FPD26. Here VFP is not to blame, but the passage to Windows. And this is true even if (as is your case) you foresaw as much as you could in your DOS programs, what a program in Windows would be like. > Here's we we are coming from and would like to inherit as much as > possible. > > Our FPD26 applications, I think are fairly modularised with fairly high > standards inherited from the foxpro community of resources over the years > together with our inhouse experience. We have various utilities and > functions that make the system very consistant and robust and are busy > trying to optimise these in VFP. Examples: > > 1. A Report Writing function is called for all reporting with the user > having the option to. > > Modifying the report template > Create New templates > Selection a printer for output > To print to AScii file for Preview or RePrinting Later > Change order of report > Export Data > Change filter or for clause > Link in other tables, etc > In this area you will have the least amount of problems. But you do not seem to use the project manager. This is a must in VFP. > 2. All tables are opened via a function that looks up a special table for > a path. > There are not hardcoding of paths. The applications work with > an > hot key > to work on differnet data sets ( for different companies) > or test site. > We plan on using VFP data Dictionery the moment we stop using FPD26. > All paths to FRX, Temp Directorys etc are soft coded. > Bear in mind that if you use the VFP .DBC, you will not be able to read the data from FPD26 anymore. On the other hand, the .DBC is a very effective tool. > 3. All Enquiry/Update are developed using the scatter/gather concept with > two screens. > One for update and one for enquiry. These screens have a srandard > VCR > type buttons > for navigation, locating records, incremetal browse > searches, locating keys > Standard routines exist for saving records with file and record > locking > takeing care > of for multiuser environments with build in functions to > maintain intergrity checks when > deleting records in master tables, etc, etc Now there are > so > many new ways to do this in > VFP but what should I do without having to do much rewrite. > Is there a framework availble > for me to use? I need some samples. Here lies the hart of the problem. I do not think this can be done using a fast track. This is where the most research must be done, and the degree of understanding must be good (look at the UT, most of the questions relate to this). And face it, this is the most time consuming in a project (I mean in my projects, this can go up to 80 % of the development effort). > 4. We use standard error trapping proedure with error login. I have not markedly changed mine, so this should not be high in your to do list. > 5. A standard generic letter mail merge module exists for > customisation for any set of tables > to print customised letters and labels. In VFP we would > like to use WORD OLE. > but that requires us having a license for every > workstations? Is there other ways? > etc Can’t help you here. (Do I anywhere else ? :-)) > 6. Our apps work for multi users, multi sites, multi currency > and would like it to become multi objects with help from the multi foxpro > developers out there!!!! > OO is really the most important aspect. I hate to say this, and it took me some time to realize it, but with lots of help and some insulting of my friends on the UT even I got the message :). The best way to introduce OO, is ... to introduce OO. Slowly, and know that it won't be OK the first time, and not the second, ... HTH, not sure though :), Marc