Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
VMP News
Message
De
18/05/2001 10:47:14
 
 
Information générale
Forum:
Visual FoxPro
Catégorie:
Produits tierce partie
Titre:
Divers
Thread ID:
00505616
Message ID:
00508721
Vues:
21
Larry,

Just wondering..

Do you know whether or not these new features could be added to the product in such a fashion (separate VCXs?) that it (VMP6) could be sold that both VFP6 & VFP7 could use it, only the VFP6 folks wouldn't be able to instantiate the additional classes?

Maybe put a check for the FoxPro version in the Init or something?




>Doug,
>SET OPINION ON
>One of the reasons for this is the new feature set in VMP. After talking to Drew, these are my impressions/recollections of what was said.
>
>The new feature set for the next release of VMP (version 6), at least the initial release, will almost exclusively be component/business object oriented. The current feature set won't be touched in great detail.
>
>Developers building components will want to migrate to VFP 7. The COM enhancements (Interface inheritance, EVENTHANDLER(),etc.) will be extremely valuable in this area.
>
>So if a developer should upgrade to VFP 7 for component development and a developer needs to upgrade to VMP 6 for the same thing, it makes some sense to marry the two.
>
>Also, Drew has expressed some interest in developing some Voodoo versions of certain VMP classes. Voodoo is exclusively VFP 7 domain. I talked to Travis Vandersypen of EPS and the reason for this is the use of strong typing for the COM+ integration.
>
>So if you go 7 for somethings, you should go all the way, IMO. It becomes somewhat of a problem to maintain for multiple platforms within the same codebase. Sometimes there are too many workarounds.
>
>SET OPINION OFF
>
>>>One thing that Drew may consider is restricting VMP6 to VFP7. Obviously this would need a lot of thought and probably user input before they seriously consider such a move. I for one think it will make the product more powerful if it can use pure VFP7 code.
>>
>>
>>Why on earth would they consider this? If they did, my perception is that it would unnecessarily flatten the curve in the sales/use of the product.
>>
>>Of course there are a number of VFP developers who are itching to get into VFP7, (me included) but you must keep things in perspective. For instance, a very small percentage of VFP developers are able to attend conferences such as Orlando. and not every VFP user will Immediately order the upgrade when VFP does ship. Many of us will get it as a part of oour MSDN subscription, but that is not the sole marketing outlet for the product. Remember, also, that there are still a large number of developers still originating and maintaining code in FPW 2.6, and even the DOS version as well. Not every VFP developer is an independant consultant, and must depend on old fashioned justification/budget in order to upgrade any software. FPW 2.6 and VFP 6.0 will still be around for quite a while yet, I believe. It is man-hour and dollar intensive to migrate reasonably complicated applications (lots of forms) originally developed in FPW to a visual version and we all know the migration
>utilities
>>leave a lot to be desired, when the original developer used unique or 'different' conventions and methodology when building the original application. Finally, it would be a limiting factor if VMP would only work with VFP7 when VFP7 contains a great deal of legacy compatibility.
Best,


DD

A man is no fool who gives up that which he cannot keep for that which he cannot lose.
Everything I don't understand must be easy!
The difficulty of any task is measured by the capacity of the agent performing the work.
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform