Current version

v1.10.4 (stable)


Main page
Archived news
Plugin SDK
Knowledge base
Contact info
Other projects



01 Dec - 31 Dec 2013
01 Oct - 31 Oct 2013
01 Aug - 31 Aug 2013
01 May - 31 May 2013
01 Mar - 31 Mar 2013
01 Feb - 29 Feb 2013
01 Dec - 31 Dec 2012
01 Nov - 30 Nov 2012
01 Oct - 31 Oct 2012
01 Sep - 30 Sep 2012
01 Aug - 31 Aug 2012
01 June - 30 June 2012
01 May - 31 May 2012
01 Apr - 30 Apr 2012
01 Dec - 31 Dec 2011
01 Nov - 30 Nov 2011
01 Oct - 31 Oct 2011
01 Sep - 30 Sep 2011
01 Aug - 31 Aug 2011
01 Jul - 31 Jul 2011
01 June - 30 June 2011
01 May - 31 May 2011
01 Apr - 30 Apr 2011
01 Mar - 31 Mar 2011
01 Feb - 29 Feb 2011
01 Jan - 31 Jan 2011
01 Dec - 31 Dec 2010
01 Nov - 30 Nov 2010
01 Oct - 31 Oct 2010
01 Sep - 30 Sep 2010
01 Aug - 31 Aug 2010
01 Jul - 31 Jul 2010
01 June - 30 June 2010
01 May - 31 May 2010
01 Apr - 30 Apr 2010
01 Mar - 31 Mar 2010
01 Feb - 29 Feb 2010
01 Jan - 31 Jan 2010
01 Dec - 31 Dec 2009
01 Nov - 30 Nov 2009
01 Oct - 31 Oct 2009
01 Sep - 30 Sep 2009
01 Aug - 31 Aug 2009
01 Jul - 31 Jul 2009
01 June - 30 June 2009
01 May - 31 May 2009
01 Apr - 30 Apr 2009
01 Mar - 31 Mar 2009
01 Feb - 29 Feb 2009
01 Jan - 31 Jan 2009
01 Dec - 31 Dec 2008
01 Nov - 30 Nov 2008
01 Oct - 31 Oct 2008
01 Sep - 30 Sep 2008
01 Aug - 31 Aug 2008
01 Jul - 31 Jul 2008
01 June - 30 June 2008
01 May - 31 May 2008
01 Apr - 30 Apr 2008
01 Mar - 31 Mar 2008
01 Feb - 29 Feb 2008
01 Jan - 31 Jan 2008
01 Dec - 31 Dec 2007
01 Nov - 30 Nov 2007
01 Oct - 31 Oct 2007
01 Sep - 30 Sep 2007
01 Aug - 31 Aug 2007
01 Jul - 31 Jul 2007
01 June - 30 June 2007
01 May - 31 May 2007
01 Apr - 30 Apr 2007
01 Mar - 31 Mar 2007
01 Feb - 29 Feb 2007
01 Jan - 31 Jan 2007
01 Dec - 31 Dec 2006
01 Nov - 30 Nov 2006
01 Oct - 31 Oct 2006
01 Sep - 30 Sep 2006
01 Aug - 31 Aug 2006
01 Jul - 31 Jul 2006
01 June - 30 June 2006
01 May - 31 May 2006
01 Apr - 30 Apr 2006
01 Mar - 31 Mar 2006
01 Feb - 29 Feb 2006
01 Jan - 31 Jan 2006
01 Dec - 31 Dec 2005
01 Nov - 30 Nov 2005
01 Oct - 31 Oct 2005
01 Sep - 30 Sep 2005
01 Aug - 31 Aug 2005
01 Jul - 31 Jul 2005
01 June - 30 June 2005
01 May - 31 May 2005
01 Apr - 30 Apr 2005
01 Mar - 31 Mar 2005
01 Feb - 29 Feb 2005
01 Jan - 31 Jan 2005
01 Dec - 31 Dec 2004
01 Nov - 30 Nov 2004
01 Oct - 31 Oct 2004
01 Sep - 30 Sep 2004
01 Aug - 31 Aug 2004


Powered by Pivot  
XML: RSS feed 
XML: Atom feed 

§ Property grids

I don't write very fancy UIs; those of you who use my program probably already know this. The main reason for this is that I tend not to put a whole lot of time into making them fancy, because for me it has a low return for the amount of time I have to invest in it. Also, I'm not interested in spending a whole lot of CPU power on one either why slow down a capture or a render with a UI that takes a lot of clock cycles to redraw? I do have one rule about UIs, though, and that's to use combo boxes very sparingly. Preferably not at all in new UI. Combo boxes take too many clicks, since you have to either waste a click for the drop-down or drag awkwardly X11-style, and I find that listboxes or lists of options look better and are easier to use. That's why in most of VirtualDub's more recent dialog, you see a lot of option sets instead.

And then, in the .NET Framework WinForms library, there is... the property grid.

A property grid is a generic UI widget that displays lists of properties, which can have values of type text, boolean (true/false), or even custom ones like colors. Properties can be separated into groups, and there are buttons to allow the user to sort the list of properties. There is also a pane at the bottom that holds help text for the property.

After using several .NET WinForms-based programs that use property grids, I've now come to a conclusion: I hate property grids. I hate them enough that I think they deserve a Joel Spolsky level rant and should be abolished from production UI.

Now, you might think... why does he hate property grids so much? Well, as an example, take the Visual Studio 2005 resource editor....

[VS2005 resource editor property grid]

This is how options for a button are displayed. VS2005's resource editor, like the older VS2002/2003 resource editor, uses property grids for changing the appearance and behavior of controls in a Win32 dialog. Why does this UI suck so much?

Now, here's the equivalent button editing dialog from Visual C++ 6.0's resource editor:

[VC6 resource editor button dialog]

Smaller. Leaner. Visually heterogenerous no chance of confusing the Visible checkbox with the Caption text edit, even at a glance. Stuff that always has to be tweaked on first tab, stuff that sometimes has to be tweaked on other tabs. And has support for keyboard navigation.

Now, you might think this is just the fault of the Visual Studio 2005 resource editor. But no, the C++ Project Properties panel was similarly changed from a dialog to an annoying property grid. And I see property grids pop up in lots of UI in other .NET WinForms-based programs, with all the same sorts of usability problems: hard to read, hard to use, wasteful of screen space, mixed-heap-o-mostly-useful-and-mostly-useless options. I cannot think of a case where a UI that uses a property grid couldn't be improved in usability by replacing it with a panel of regular UI widgets, tabbed if necessary. And my hatred of property grids has nothing to do with it effectively making every property into a combo box.

Having written a little bit of C# code, I also know why the property grid is used as much as it is: it's easy. You just create a set of properties in a class with suitable attributes, and then attach an instance of the class to the property grid, and you magically have an interface. Change the class, and the property grid changes along with it. Unfortunately, I think the amount of time saved coding is not nearly justified by the horrible user experience. (I also wonder how you localize it.)

Appendix: Not about property grids, but while I'm talking about the resource editor....

In VC6, double-clicking a control brings up its options dialog. In VS2005, it brings up the Add Class dialog, defaulted to the CLR category and adding a WinForm-based class. Because attaching a .NET WinForms-based class to a Win32 button in an .rc file in an native project is so much more useful than displaying button properties....

VS2003 had a serious bug with randomly corrupting symbolic IDs to hardcoded numbers in .rc files. Supposedly that's fixed in VS2005; it was going to be postponed until post-ship, but the suggested workaround was bogus and the fix seemed to go in pretty quickly after the votes on the bug on the MSDN Product Feedback Center shot up past 15 in a short time....

String tables and menus are places where the VS2003/VS2005 resource editor experience is actually better than in VC6, because you can type in the strings in-place rather than having to bring up a dialog for each one.

Between VS2003 and VS2005, the C# project settings were moved from a property grid in a dialog to a document page with tabs and regular style checkbox/edit/combo widgets. That it's a document is weird, and the spacing is goofy enough that it looks like a goofy web page instead of a dialog (maybe it is a web page?), but it's a step in the right direction. Unfortunately, the C++ project settings didn't make a similar move.


Comments posted:

Yes! Property grids are an abomination. I think another possible factor for their usage is that Visual Studio uses them, most Windows developers use Visual Studio, and they either start picking up Visual Studio's horrible UI practices, or they use Visual Studio as a model for justification. (On the other hand, for some it could have the opposite effect: I hated them completely within five minutes of using Visual Studio.)

stickboy - 20 03 06 - 05:15

Preaching to choir. Amen. Use of Property grids is just plain slack, thoughtless and rude.

ianb - 20 03 06 - 08:10

Property grids can be useful for looking at all the options but gets annoying when I have to use so much of them.

john - 20 03 06 - 12:10 least you can sort them alphabetically.
This feature is missing in the german version of vba. If you try to change properties in an access-report you have to search for the german name, but if you change them within vba-code you have to addresses them with their english name - that's weird.

Murmel - 20 03 06 - 12:53

I can understand why they do this. Using property grids is less resource hungry and is much easier to extend than a proper dialog (from a coding state of view).

I also have to disagree with you with regards to doing a proper UI. It doesn't take more CPU to do a proper UI, it really depends on how you implement the UI. In my own program, which has skinning elements and a flexible UI (scriptable), the UI takes nearly zero CPU (pretty much the same CPU as a normal windows app when not doing window resizes).

Blight - 22 03 06 - 16:06

I didn't say proper UI, I said a fancy UI -- creating a usable UI indeed doesn't mean an expensive one.

I would have to disagree with you in general on skinning (disregarding that I don't consider skinning to be essential to a proper UI). If skinning is done correctly and with a lightweight, well-designed skin, then it too need not have any significant impact. However, there are very few applications that do skinning well. Most are bloated and use a lot of image-based and owner-drawn controls. When competition for the CPU is very high or the UI is being rendered over a slow remote connection (remote desktop), the overhead for such an interface is considerable. Generally, the first thing I do when I find that an application is skinned is to look for a way to turn the skinning off or to switch to a "classic" option.

This is, by the way, a major reason I dislike .NET's System.Drawing: it uses GDI+ and thus forces a lot of expensive, non-accelerated rendering.

Phaeron - 23 03 06 - 04:17

haha! I thought I was the only one that hates the property page. One of the things I find very annoying is the Control ID, besides being at the end of the list, it's also affected by the scroll wheel. After I change the ID, I like to scroll up with the mouse wheel to change other properties. But every time I do that, the ID is changed to some other ID. AH!

meanie - 26 03 06 - 23:59

The goofy behavior of the control ID field acting as a list has been bugged already:

I can't think of any good reason whatsoever for the existing behavior. VirtualDub isn't that big of a program, and it probably has thousands of symbolic resource IDs. Navigating that by a one-line field would be ridiculous.

A further problem I've run into is that the dialog editor is nearly unusable without opening and pinning the property pane, but the dialog editor doesn't have its own UI mode like in VC6, so then when I switch to code the property grid sticks around and wastes space. This is really annoying when I'm trying to implement a dialog and have to flip back and forth to copy the control IDs.

I really have to wonder if anyone on the Visual Studio team is actually using this editor. You would think all they would have to do is bring in an MFC developer and watch him working for an hour to see the usability problems.

Phaeron - 27 03 06 - 02:17

If you haven't applied for the VS2003 Service Pack 1 Beta, you might want to do so and add your feedback there ( For VS2005 I think you have to stick with the MSDN Lab for feedback since there is no SP Beta yet.

Derek - 05 04 06 - 05:44

I think what would make the property grid 1000x more usable (especially in VS) is the ability to filter the list on some text. Type "Right" and it will only show those options with the property (or description) containing "Right".

This would help incredibly when changing the same property on multiple controls.

rein - 29 01 09 - 13:34

In Expression Blend there is a filter feature since WPF has so many properties, this increases usability quite a lot. I'm currently building a Visual Studio add-in to just display the most common properties and to add a Blend like filter feature. It'll work only for WinForms however.

Many applications lack usability due to missing search and filter features, ever tried to change key shortcuts in MPC a lot, I have much respect for Gabest's filter development but his UIs are amateurish.

The PropertyGrid, the design time evironment and reflection are valuable tools when used appropriatly, it's just many people abuse it. In most cases when the property grid is used there aren't just real properties in a class, there are several classes, interfaces, attributes etc. to add and remove/filter properties dynamically. Take a look at TypeDescriptor, TypeConverter, TypeDescriptionProvider, ICustomTypeDescriptor, PropertyDescriptor for instance, this stuff can safe a hell of code and work and provide incredible power and flexibility.

stax - 13 03 09 - 15:25

Filtering is not a good way to resolve the usability issues of the property grid. It would make it slightly less painful, but you're still talking about a lot more work for the user to do than just selecting a control from a well-sorted category. It also requires combining the keyboard and the mouse, which I also consider a poor idea.

Phaeron - 13 03 09 - 23:29

You are right of course about the usability issues, there are custom property grid's that support option boxes btw. This one for instance:

Here is a WPF Blend like with Search/Filter feature and the caption is right aligned which also might improve usability:

Generic or dynamic solutions like the property grid or the options tree view in VirtualDubMod or StaxRip lack always usability wise but it can save a lot work and code and enable features only possible with a dynamic solution, the saved time can than be spent on things more important.

In StaxRip I tried my best to build a nice x264 dialog with sliders etc. since many users like x264, I've completely changed the x264 dialog 3 times just to ensure it don't suck. For H.264 DivX I didn't want to spent more than a hour work and a couple of lines code building a dialog so I decides to make a quick and dirty dialog using a option tree view which is a single line code for every option only. Saved time can be spent to enjoy the nice weather for instance :)

stax - 14 03 09 - 09:56

Comment form