Ditto for VPM. We've gotten it to do everything (services with oApp, even hooked to a .Net app on IIS), but all the reasons you state for VFE are just as true for VPM.

I would make the case that the investment we have in code is actually an investment not in the letters and words of the code, but rather is an investment in being able to articulate the domain in software. That's why I suggested Lianja: he gets to keep the articulation of the domain in a software language he already knows. I think that's the best he can do.

Hank



>Hi Scott -
>
>I certainly understand where you a coming from on this. As you may know, I"m a framework guy. I taught Visual FoxExpress for F1 Technologies and created the 30 hours of video training materials for the product. Last year I finished a project rescue on a VFE / VFP project here at Dow Jones.
>
>I think it is fair to say I can make VFE do some pretty sophisticated things against a SQL Server back end ( the thing VFE excels at, IMO)
>
>All that said, I don't think a framework - at least VFE - is going to mean just "sprucing up" a existing 2.6 fpw app and make it look "modern"
>
>Usually a good framework is more interested in the plumbing - data access and business layer - that the UI and IMO VFP UI is never going to look "modern" because it isn't. The UI looks 1990's and just the pain of integrating Activex controls that didn't come from one fox friendly vendor - DBITech - was a lesson that the options were very limited without a *lot* of time invested.
>
>And to get the benefits of a framework ( and again I speak more of VFE as I have only limited knowledge of the others) you will probably need to do a great deal of refactoring of your business code. (again, without any knowledge of how your 2.6 business logic is structured, but having done and mentored a *lot* of conversions of 2.6 apps to VFP )
>
>Without knowing what kind of app your sell ( obviously accounting software has very different UI needs and customer base than some other categories ) I think before putting time and investment into a major product upgrade using - I assume - DBFs and VFP that you at least consider other approaches involving newer technologies.
>
>Thanks to Pluralsight and being able to google answers to just about anything now the learning curve can be a lot less in some ways than the limited resources available to teach and share experience of VFP or any VFP framework ( brilliant as my training stuff is <g> )
>
>As only one example, Code Magazine is giving away a very nice framework that lets you use WPF and and SOA approach against just about any back end. Markus has articles in the magazine talking about it and the reasons for adopting a flexible development strategy going forward.
>
>I have been doing Fox since the 1980s, made a lot of money with it, and can make it do pretty much everything it can do. I am probably one of the four top developers in VFE which I consider to be the most powerful framework for VFP.
>
>I would not even consider doing what you are proposing in VFP even with VFE knowing what I know in VFE And I think most of the people you and I saw as Fox gurus 10 or 15 years ago would say the same thing.
>
>Of course, as Dennis Miller says, "That's just my opinion - I could be wrong." <bg>
>
>You may very well be correct that you can get the UI benefits you need in your case by just sprucing it up. I would pick a path involving the least learning curve to the biggest UI reward. I don't know about the other frameworks but I would suspect my favorite, VFE, would not be a good choice.
>
>In any case, good luck with it.
>
>
>>FWIW, Pete Kane was off base only because he missed the point of my query which was not about re-writing or creating a new product.
>>
>>What I do not want to do is re-write 150,000+ lines of biz object code in order to make a 17 year old FPW2.6 application look modern. It's all about "how to get more life out of existing code."
>>
>>There was a time, before VFP6, when it looked like a re-write was necessary and VFP was low on the totem pole. But VFP6 made it possible to continue on with the same old UI while focusing on the biz object. I'm pretty sure I can spiff up the UI while retaining most of the BLL and that's what I'm aiming to do.