There is a reason why those apps were done in FPW as opposed to VB. The issue is Data. If the app requires a lot of data manipulation, VFP is most likely the correct tool, because of its langauge. If it is a matter of data quanity and/or security, the combine VFP with SQL-Server or some other RDBMS.
Just because VBA is the langauge in Office is not a good reason to dump VFP in favor of VB. One question, if the powers at be really felt this way, then why did'nt they write the app in Office with VBA?
BTW, much of the VB code that is posted, is of rather suspect quality. Code postings are good for giving you a general idea of how to do things. But, I would never expect folks to incorporate the code as-is into thier apps. Even the code I post, I expect folks will/should tweak it for implementation they choose.
Let's face it, there are more VB developer's than VFP. This is a fact, one that cannot be refuted. That said, I say so what... The question is, "How quickly can you get your VFP answers solved?" Once again, converting VB code to VFP is not that big a deal.
Right here, right now, I personally put out the challenge to somebody to present me with VB code that I cannot duplicate in VFP...
It sounds like management is suffering from GartnerItis. This is an ailment contracted from reading, and believing too many Gartner Group Reports.
VFP will never achieve marketing parity with VB. That is a red herring IMHO. The issue is, can you get the job done quickly and effectively with VFP?
That should drive the decision.
Précédent
Suivant
Répondre
Voir le fil de ce thread
Voir le fil de ce thread à partir de ce message seulement
Voir tous les messages de ce thread
Voir tous les messages de ce thread à partir de ce message seulement