>Unfortunately I just arrived on the scene last week, and the decisions have already been made. I was brought in to assist with the maintenance of the existing product until the re-engineering has been completed, which is scheduled for first quarter of next year. I've stuck a few plugs in (and will continue to do so) for VFP and even mentioned that VFP 7 will be available within the next few weeks packed with new features, XML and web services support, etc. It would be tough to change minds with so many have been driven away with the anti-Fox hype.
>
>The way things are right now is that the existing product was in FoxPro 2.x & VFP 3, and almost all of the code is still in that format, just being maintained with VFP 6. None of the real features or advantages of VFP or OOP are being utilizied at all. In all fairness to the history of the product as I've heard so far, it's understandable. Unfortuately the decisions to do away with VFP were made before I arrived and from the sounds of it, management fell prey to the "bad rap" that FoxPro seems to have. Appearently several of the managers and IT people on the client side cringed when they heard "FoxPro". So the re-engineering effort was not only in the hopes of enhancing the product, but also to get it a warmer reception.
>
>Yes, I know this getting way off my original question. I honestly had to think hard about becoming involved with the project, because I really hate helping people hunting the Fox. But, as we all know, the bills must be paid...
>
>
>- Brian
>
>
>>>Correct. And much to my (and the other VFP developers) disappointment, VFP is totally being dropped...
>>
>>*sigh* That's a damned shame. What, if anything, do you think could have been done to avoid that? If you care to share it...I'm just curious.
>>
>>So, what is the other recommendation? That .NET be selected as the platform? I don't know that I'd disagree with that, depending on what the app is and what the timeline is for development.

Brian;

From what you have described the present project is a can of worms. Trying to maintain something like that or add new features is not easy. If the project was done in VFP correctly I would think management would see an improvement in overall performance and maintainability. It is understandable why a new tool will be used under such conditions.

By the way I have worked for two companies that patched FP 2.X code into spr’s and ran VFP to get 32 bit performance. No OOP, etc. just hell to work with. Talk about spaghetti code!

Tom