Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Conversion from VFP 7 & * Applications to VFP9
Message
De
13/06/2005 01:08:39
 
 
À
10/06/2005 12:00:16
Information générale
Forum:
Visual FoxPro
Catégorie:
Codage, syntaxe et commandes
Divers
Thread ID:
01022184
Message ID:
01022672
Vues:
21
Gaylen,
Your posting is refreshing for me, as I just happen to be in exactly the same stage as you. I have been working last week and a half converting a 100.000 lines VFP7 application to VFP9. Except for "SQL group by", I'm done, and very happy I did.

Issues that took most of the time (as far as I remeber):
- I use XFRX too and I have to rewrite report generation to take advantage of the new capabilities. The preview window now is slower, but more capable. PDF generation is both faster and more accurate (I had previously some problems with some reports, all of them gone). The progress bar took some time, as I use a custom progress bar across my application, even with XFRX and Stonefield; I had to subclass updateListener from FFC to include my custom bar. The down side is htat It added almost 400 KB to the final EXE, and I still have to translate some parts of report Preview as they don't render is Spanish.
- Reviewing all the reports, as GDI+ needs more space to render figures, and some fields in the reports will show ***** if you use the new rendering engine (you can still use REPORTBEHAVIOR 80).
- Anchor: I used a custom implementation for anchoring, so I had to get rid of it, and go through every control in the 150 SCX. I wrote a program to make most of the work, but i took more than half a day.
- Grid memberClass, and column memberHeader: I had to hack every each form with grids on them to be able to use custom columns and headers, plus rewrite some forms that used myGrid.column(1).header1.caption to set the caption of the headers. I wrote a function independent of header name.
- Put Session classes into visual libraries. I rather work with VCX than PRG for clases.
- Building a new project in InstallShield and testing it in different operating systems and configurations.
- For sure the SQL rewrite will take 2 or 3 days.

What have I won in just a week:
- Reporting is far more flexible, and I will benefit from it further in the future.
- Anchoring works better when there are 2 grids in the same form.
- Using a combination of allowCellSelection and a few changes my grids are able to trap doubleClick in every situation, and I can simulate better a disabled grid without really disabling it. Trapping doubleClick in grids allows me to build a better and more modern interface.
- I got rid of a garbage collect C5 error that randomly happend in some operating systems.
- I can use Excel automation with Armadillo protection in windows98 machines (before VFP9 it worked only in win2000 and winXP).
- Many improvements in user interface (like image positioning in command buttons, better preview, auto-complet textBoxes, ...)
- Using FLUSH FORCE has solved some issues in machines that had write-cache enabled for the hard drives. I had to be carfeul to use FLUSH IN () FORCE to only flush the skip and child tables (if you don't the it can take long to FLUSH over the network).

This is only the beginning, I have done only the initial work. Now it's time to get advantage of bindEvent(), new reporting capabilities, cursorAdapters, and many things I have been waiting for. I think it is a great upgrade, and worth the effort.

>Just complete conversion of three application to VFP 9. One was a VFP7 and the other two large applications were written in VFP8.
>
>Conversion was very sucessful and now all are running as VFP 9 applications.
>
>Some gotcha's
>
>In the VFP7 application I had to adjust the group by clause to include all non agggregate field in the query into the group by clause.
>
>In the VFP8 application I had to adjust reading the _tally results in the case where the query returns only an aggregate on a query without a group by clause.
>
>Using the Code reference option available since VFP8, it was fairly easy to make these changes.
>
>The thing that bit me the hardest was printing reports and labels when you use the SET PRINTER TO command to select the printer. Even though they ran fine in the other versions of VFP, in VFP 9 the reports and labels printed defaulted to the default window's printer. I had to go in and make sure all printer specific commands in the report table was removed for tag1,tag2 and
>expr field. In one of the labels I left several blank spaces in the tag field and it continued to select the default printer and when I final removed the two blank spaces did it work correctly. I use the print command to select printer for the Dymo label makers used in printing labels and using the FAXPRESS printer drivers to automate the faxing process. Both FAXPRESS and DYMO printer worked without a problem.
>
>With the exceptions of the above, everything is working fine. I use a lot of automation to Excel and Word and it presented no problems. I switched to the latest version of Stonefield Database, Common Control Library by Alex Grigorjev, and XFRX and all ran without a hitch in VFP9.
>
>The two largest applications have from 10-30 users actively accessing the data dealing in hundreds of thousand of records.
>
>If you are considering converting over, I would suggest do it now so you can start using some of the neat stuff in VFP9. I was reluctant to do it at first, but now that it is over, I am extremely happy that I did. The whole process took about two week to make the changes and test before I went live.
>
>AS Nike would say "JUST DO IT"
>
>Gaylen
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform