Perhaps there is a hidden rule about the System.Windows.Forms namespace that its classes ought to have as many properties as possible, as to come across as powerful and flexible. Probably not, but nonetheless, that’s what it feels like.
In the pre-OOP days, this may have been unavoidable: without inheritance, you essentially have all or nothing. But with .NET, Microsoft had the opportunity for a fresh start, and so this does not make much sense for me.
I was not alone in my expectations (nay, convictions) that it ought to have some property that sets the URL, and that clicking anywhere inside the label will open a browser window and load the resource the URL points to:
When I first used this control, I thought the control should have a link property where I would add the URL of my Web site and it will work. But no. It doesn’t work that way.
Instead, it appears a LinkLabel effectively works like an image map, where you can define areas inside the control that respond to different URLs. Sure, you could have one area that covers the entire control. Also, the page describes an easy workaround of defining an event handler for LinkClicked. But why in the world would you make such a control deceptively simple and in actuality complex? Who thought this was a good idea?
Reasonably, LinkLabel inherits Label. But to me, the complexity of being able to define multiple links with rectangle areas they respond to belongs in a separate control: a subclass of LinkLabel. (And even then, the potential confusion of “this control actually represents multiple links” still hits the user.)
I can only assume a lonely soul at Microsoft thought they were doing something really clever. That’s exactly what it seems to be at first, too: clever, convenient, cool.
The PropertyGrid control provides you with a highly flexible (if a little overengineered) interface to manipulate settings – or properties, if you will. Microsoft mostly appears to reserve its use for developer- and administrator-type applications rather than regular end user ones, and probably for good reason: the control is overwhelming, at least at first. It’s hardly impossible to understand how it works, but for every single thing it does, you cannot help but wonder if a more traditional approach may have been less confusing – at the expense of slightly more development time.
But it does suit our purposes, and once you hide its own toolbar (yes: by default, the control has its own toolbar – luckily, it can be turned off in code), it even becomes viable for a releasable application. Almost.
By default, the PropertyGrid control does not populate its contents in the traditional, active manner. You don’t, say, pass an array of categories, which in turn contain arrays of properties. Rather, you tell it what object is “selected”, and it fetches the properties from that using Reflection. This is where the clever part comes in: any object’s properties are automatically available to the PropertyGrid. It takes no effort on the developer’s part.
That is, until you realize that it really does. The properties of an object were defined by developers for developers, and not for end users, and the more you try to put finishing touches to whatever window you have a PropertyGrid in, the more you realize how much needlessly harder the simplest of things suddenly become.
The most obvious case is the naming of properties. Because properties are special kinds of variables and therefore symbols, there’s probably .NET-compatible language in the world that lets you use spaces in a property’s name. Now, some developers like CamelCase, or dromedarCase. Others use underscores_instead, and yet others may use different alternatives, such as dashes. Whatever they choose, nothing except for the space itself (which isn’t allowed) is what the end user should see. Have a property named ReadOnly? Sorry, but if you plan to ship that app, its property grid better show “Read-only”. Luckily, Microsoft provides a solution for this: the aptly-titled DisplayName attribute.
<DisplayName("Read-only")> _
Public Property ReadOnly() As Boolean
' Lots of code…
End Property
Theeeeere we go. But no, we’re not done here. As mentioned, the properties shown in the grid can have categories, and once you go beyond more than a handful, you will want to use those. Therefore:
<DisplayName("Read-only"), _
Category("Nifty Things")> _
Public Property ReadOnly() As Boolean
' Yet more code…
End Property
Better! And when in doubt, you can even provide a description:
<DisplayName("Read-only"), _
Category("Nifty Things"), _
Description("Prevents the user from editing the field, but still displays its current contents.")> _
Public Property ReadOnly() As Boolean
' Yet more code…
End Property
See, that wasn’t so bad, was it? Unfortunately, we’re not done yet. The above may be a fine solution if two things can be assumed:
- The application does not have to be multilingual.
- The properties can indeed be hardcoded into the object, and don’t change during runtime.
Yeah, good luck with that. Of course you’ll eventually have customers from abroad, and of course at some point properties can change not only based on the context of the object, but also within one and the same object. (No, you can’t use a function for localizing the DisplayName, Category or Description attributes: Visual Studio will immediately throw an error that they have to be constant.)
That’s not to say it’s impossible to localize the contents of a property grid, or impossible to have a dynamic list of displayed properties. But by the time you get there, you scratch your head and cannot imagine any more that this use of reflection made things easier. It didn’t save you any time because, instead of having to populate the properties by hand, you had to edit each and every property by hand. Moreover, it wasted you time because you had to learn a different way of doing things; reflection is normally rarely used, and I get the feeling this particular example of it isn’t a good one.
There are guides on localizing the DisplayName as well as the Category, and perhaps there’s even one for the Description. Likewise, you can find various articles on dynamic properties. There’s even hacks to pretend that the PropertyGrid handles Booleans as checkboxes, rather than as dropdown menus with “False” and “True” options (*shudder*!), although in my mind, they only make toggling a setting even more confusing.
But in my experience, nothing you can find on the vast resources of the Web will squash the gut instinct that all of these workarounds would have been necessary at all if the grid had simply been manually filled with properties at runtime.
It wouldn’t have been as clever. At the same time, it also would have been more useful.
Maybe Microsoft isn’t the worst offender in bizarre control class design decisions. Lately, that questionable honor seems to lie with Infragistics, whose controls are bought because they offer more flexibility. Still, the sheer amount worries me: ‘Why can I change the color of this side of the drop shadow of this particular menu item?’
Now, coming from mostly a Mac background, I assume I can populate a menu with items, and possibly with other controls, which should be avoided. I’d also assume submenus could be attached to items. Finally, between items, there could be separators.
With Infragistics, you don’t think in terms of menus at all. API-wise, menu items are actually “tools”, added to a “toolbar manager” as well as a “menu tool”, which in turn you have to set to display as a menu, if you so desire.
You also don’t add separators. Rather, you tell an item (a “tool”, remember?) that it’s the first within a group, and the API will then appropriately add a separator in front of that – or on top of it. What if you have dynamic items? No problem:
Dim menuHasOptionsGroupAlready As Boolean = False
If shouldAdd("SomeItem") Then
someMenuTool.Tools.Add(Me.UltraToolbarsManager1.Tools("SomeItem"))
If Not menuHasOptionsGroupAlready Then
someMenuTool.Tools(someMenuTool.Tools.Count - 1).InstanceProps.IsFirstInGroup = True
menuHasOptionsGroup = True
End If
End If
If shouldAdd("AnotherItem") Then
someMenuTool.Tools.Add(Me.UltraToolbarsManager1.Tools("AnotherItem"))
If Not menuHasOptionsGroupAlready Then
someMenuTool.Tools(someMenuTool.Tools.Count - 1).InstanceProps.IsFirstInGroup = True
menuHasOptionsGroupAlready = True
End If
End If
And so on. That’s how I solve it naïvely, anyway – I don’t think there is a better alternative.
Finally, you don’t just attach a menu to a “tool”. Rather, you replace the ButtonTool with a PopupMenuTool, which then must have a menu, which in turn consists of ButtonTools – unless, of course, you want submenus.
This is the first time I talk about everyday experiences at my job. As such, I feel I should state the following: The opinions expressed here are my own, and neither my employer nor any other party necessarily agrees with them.
Moreover, to everyone at Microsoft and Infragistics working hard on the .NET Framework / Visual Studio and NetAdvantage for Windows Forms, respectively, I ought to stress that, despite the occasional annoyances and weirdnesses, I obviously enjoy using the products more than enough, and while my above criticism is real, it only represents minor niggles.
