>>>>>I wander How do you call people who swayed by M$ marketing decided to rewrite their cash-cow / LOB apps to NET 1.1
>>>as early as 2003-2004 ?
>>>
>>>Actually I was one of those people: the NET code we wrote in 2002-2003 was quickly obsolete and unmaintainable by ?2008 because nobody was prepared to work on that old junk. Did you ever manage to achieve acceptable performance in terms of speed
>>
>>How about performance ? Was it win forms app or Web app ?
>>Is it possible to get Win Forms app to work somewhere close to speed we get in VFP ?
>>Some happy VFPapp users get their eyelashes twitch every time VFP form pops up {g}, so what was your impression on speeds in
>>NET with WinForms ? I saw few of those apps around here, but performance was very bad! Compared to VFP of course.
>>
>>I work on 'old junk' all the time (Love every minute of it! :) ) , but at least everything works fast and reliable.
>>BTW to answer originator of the thread, I was literally swamped with VFP work in the past two years, and have no other choice but to press 'NEW PROJECT' in VFP9. I am really dying to play with all that new NET stuff, but I have no time not so ever.
>>VFP is still what pays the bills.
>>
>>>
>>>What I find most interesting is the personalization and distraction whenever we try to discuss these important issues. When confronted with the risks in their own choices, some people who have bashed VFP for years prefer to continue the attack, targeting the messenger or introduce boring personalized nonsense rather than engaging the real issues, including the strong chance that both VFP and NET people may need to select a non-MS product if they want to be mainstream in the mobile arena. I'm not saying it's certain, I'm saying that automatically cleaving to MS may be a HABIT that doesn't reflect market movements at the moment.
>>
>>No comment ;)
>
>One thing many developers don't do (yet) or perhaps don't consider is to put code in place to track which pieces of their app is slugging along compared to others. There are some nice profiling tools out there now for those who don't want to code it on their own.
>
>Bad code is bad code. Inefficient code can sometimes be just as bad. Just as in VFP, there are 100 ways to skin a cat in .net. 99 of those ways may be slower than 1 of them. If you can identify the forms that load slow or close slow or other pieces of your app that are slow then you can look for more efficient coding options... (sometimes it really is the design pattern causing the issue and other times it has nothing to do with it and developers use the design pattern as an excuse for the delays in some areas of their app)
>
>One benefit .net has over VFP is multi-threading. (I'm not trying to start the discussion on multi-threading in VFP - I have some apps doing that). There are times it can be used to greatly improve the speed of an app and other times when it can be deadly. Sometimes multi-tasking is a better option. Writing benchmarks can be helpful....

Good post. Thks+++ Tracy :)