For those VFPer sitting on the .NET fence, I just discovered this guy's blog and thought I'd share it here. I'm not trying to stir up any trouble, but, its interesting stuff and some of what he says had me laughing out loud.
Check it out http://dotbloat.blogspot.com/ Hi, Mike,
Someone mentioned this thread, so I read the blog post. I haven't read all the UT replies (yet)
By the way, when the blog author said the following:
Even the Visual Studio Cheerleaders will try to spin this extra work as a positive, below is an excerpt from code magazine…
“...Subclassing the base .NET Windows Forms controls is different from VFP because developers must write code to do so. You cannot subclass visually, but the process will provide good exposure to the language and the .NET Framework.” He's actually quoting me (when I read the quote, I thought, "geez, that sounds rather cleverly stated...I wonder who wrote that? Oh wait,
I wrote that!").
That quote was part of my article on moving from VFP to .NET, in a CodeFocus article that ran in early 2007. (Though I'm sure many others have uttered the same or similar words) The article was reprinted on the VFP Conversion site a little while later:
http://new.vfpconversion.com/Article.aspx?quickid=0703092As far as I'm concerned, if someone is comfortable in Fox, and doesn't have to switch, more power to them. But to position Visual Studio/.NET as inefficient, simply because you have to subclass controls via code, is a non-argument. You do it once or twice, and maybe you go back and tweak every now and then - but of all the arguments I've never encountered about .NET, it's the silliest.
And believe me, MANY developers, even those who have come from Fox, don't have an issue with gaining some exposure to the framework by writing some code. Certainly not all, but enough that these types of conclusions haven't achieved any type of consensus.
Believe me, I'm not in love with everything that Visual Studio does - and after training on SSIS/SSAS/SSRS for over a year (where you use BI project templates inside of Visual Studio), there's a long list of items that I wish would work differently in the IDE. But at the risk of sounding arrogant, the "real" issues in the IDE are a bit less superficial than the items raise in the blog.
