Delusional Ramblings of an Angry Coder
Take a look at Mark: Ramblings from a programmer, if you dare. Whilst some of the points he makes are good, for example that Visual Studio doesn't inherently encourage programming best practice, i.e. the separation of presentation, business and data layers, a lot of his other posts are purely rants about the fact that VB6 and VFP (Visual Basic 6 and Visual FoxPro for those who tire of acronym soup!) are no longer being produced. Ironically, VB6 does little or nothing to encourage the separation of presentation, business and data layers, so any bleating about the "good old days" do fall on deaf ears somewhat.
Having taken a mooch through his blog, I came across a post surrounding designing custom controls. Or at least, his opinions regarding VS's shortcomings. I thought it'd be worthwhile to go through each point in turn and analyse/debunk them:
Property Attribute Example
Just to highlight why the attribute based default value for a property is better, consider the following code:
With the first example property, any Visual Designer (or indeed parser, decompiler, etc) can immediately determine what value to show in a property grid, but with the second (albeit contrived) example, all bets are off. For describing the attributes of something, attributes are definately the way to go.
Having taken a mooch through his blog, I came across a post surrounding designing custom controls. Or at least, his opinions regarding VS's shortcomings. I thought it'd be worthwhile to go through each point in turn and analyse/debunk them:
- Sub-classing a control doesn't cause the new control to inherit any design-time attributes, specifically Toolbox icon.
- Altering a property in the child class causes the property value to show in bold in the property page for the control when it's placed on a form. Oh, and the fact that changing the value of a property in the class thusly doesn't propogate through to any derived application.
- Why's this a bad thing? This might just be down to a matter of opinion, but surely the name, icon and other odds and ends should be down to the developer. How about if you inherit from System.Windows.Forms.Control,... what icon should be used then? Or one of the abstract base clases like S.W.F.ListControl?
As a Control developer, get off your arse and choose an icon, rather than expecting Visual Studio to do everything for you. - Altering a property in a way that causes the property value to show in bold means that you've done it the wrong way. The author even goes as far as mentioning the System.ComponentModel.DefaultValueAttribute and then whines that using this is a "work around" to a "bug" in Visual Studio.
Consider for a moment if the Visual Studio designer determined what the default property value was based on the return value for the property get routine, this routine could go off and query the Registry / contact a web service / choose the Nth font installed based on the number of elapsed seconds in this specific minute, in short - the return value could be entirely nondeterministic and even long running. By decorating the property with an Attribute, any Designer tool can determine immediately and deterministically what the default value for the property is. This also results in NO code being generated within the application using the control and thus any change to the default value being propogated upon recompilation of the Control.
Property Attribute Example
Just to highlight why the attribute based default value for a property is better, consider the following code:
public class ControlWithProperties : Control { private Font _font; [DefaultValue("Segoe UI")] public override Font Font { get { return _font; } set { _font = value; } } public Font OtherFont { get { if (_font == null) { if (DateTime.Now.Second < 30) { _font = new Font("Century Gothic", 20); } else { _font = new Font("Comic Sans MS", 20); } } return _font; } set { _font = value; } } }
With the first example property, any Visual Designer (or indeed parser, decompiler, etc) can immediately determine what value to show in a property grid, but with the second (albeit contrived) example, all bets are off. For describing the attributes of something, attributes are definately the way to go.
Hey Robert,
One question for you have you ever used Visual Basic or Visual FoxPro? My thought is you haven't otherwise you would have been aware VB and ASP can consume VFP middle tier DDL files therefore providing a far more robust N-TIER implementation with complete seperation between the UI, Middle Tier Code and either SQL Server or FoxPro Database files. We can also go the other way create a reusable activex control in VB and consume it in the VFP UI layer.
Something else really cool that VFP has and VS doesn't is a true data centric language with native data access which means it is doestn't suck at building middle tier components that follows N-TEIR standards which not even linq can do right. The only disadvantage is DLL hell syndrome which is more an operating system issue addressed completely with installshield.
The current production release of VS is nowhere near able to pull this off as cleanly as the above stated implementation maybe when/if MVC is ever released that might be close have to wait and see as currently MVC is in a state of disarray.
Moveover if my assumption is correct how do you know VS is better then VB or VFP? Curious if you read about it on GU'S blog and just following blind faith ?
With all due respect, I alway mention VB with VFP together when talking N-TIER design patterns. The rest of your post about my older is blog is equally inaccurate and probably will make little sense unless you thoroughly understand the C++ or VFP inheritance models therefore you were reduced to grasping at toolbox icons as being my issues therefore missing my entire point. Perhaps in the future do your research before flaming other developers and get your facts straight.
Best Regards,
Mark Gordon
Mark,
I've not used VFP, however I have used VB and before that QuickBasic 4.5 which was its spiritual, if not actual, ancestor. I've worked on systems that used separate, and physically distributed data access, business and presentation layers written in VB6. It was a pig to work with. I'll repeat, it was a pig to work with. Component Services and all the things that can go wrong with it is something spawned from one of the lower levels of hell. If you're familiar with it, I'm sure you'll know what I mean there.
Note that I didn't direct any of my comments against VFP. That's because I've never used it. Nor am I likely to. However, I *know* VS is better than VB6; as an IDE, a platform (the .net side of things) and as a tool for developing N-Tier systems because I've used both.
I have complaints with Visual Studio 2002/2003/2005/2008 but, certainly from 2005 onwards, it beats VB6 hands down. Not to mention that VB.net as a language makes far more sense than VB6. (Yes, I said it! VB6 can't help it, it has a very long family tree)
With due respect, do you know that VS 2005 onwards has several bugs for VC++, which Microsoft are trying "hard to fix". This is the response I have received from Microsoft Visual Studio IDE team lead ... did you hear that IDE team lead .. not the product one.. do they have any now, after the exit of Jeff Prosise and Mike Blaszczak .
For example CWnd derived virtual functions are not shown in the designer.
I never worked on VB , so should not comment on that ; but they have killed Visual C++, or at least trying to.
@Mark - I think we'll have to agree to disagree on this one. You think I'm wrong. I think you're a bit mad. End of :)
@Sujay - to be frank, I don't give a damn about C++, so I'm not going to comment on it :)