How to filter out base classes properties from the PropertyGrid

I like to post some howtos or tips when the initial concern comes from a customer or visitor. One of them in the forums asked if it was possible to filter out properties while using SelectedObject and even if all properties from ancestor classes could be removed automatically. Well, yes, it’s feasible in Smart PropertyGrid. This is very quick. Here is how:

Let's say you have a class MyControl derived from the Control class.

You must first add a handler for the PropertyPreFilterOut event or simply override OnPropertyPreFilterOut in a PropertyGrid derived class:

protected override void OnPropertyPreFilterOut(PropertyPreFilterOutEventArgs e)
{
    // Write some code here
    base.OnPropertyPreFilterOut(e);
}

Now to remove all the properties coming from ancestor classes, we must pay attention to their PropertyDescriptor and target instance so that we keep all properties published by our MyControl derived class and all their descendants:

PropertyDescriptor pd = e.PropertyDescriptor;
if ((pd.ComponentType == typeof(MyControl)) || (e.TargetInstance.GetType() != typeof(MyControl)))
    e.FilterOut = PropertyPreFilterOutEventArgs.FilterModes.FilterDefault;
else
    e.FilterOut = PropertyPreFilterOutEventArgs.FilterModes.FilterOut;

Two screencasts to showcase the great support of SelectedObjects

The support for SelectedObjects in version 2.5 of Smart PropertyGrid.Net has been totally reworked. Previously it was rather limited, so I wanted to bring it equal to the Microsoft PropertyGrid and finally it appears it is now far better. It is now possible to select several target instances and to see and edit any common properties even for immutable properties, the ones whose TypeConverter returns true for CreateInstanceSupported(). Add the existing power of SPG, like the numerous editors, and you have a very powerful and flexible way to edit for e.g. the objects you have selected in your CAD/CAM client application.

A demonstration is better than a long explanation so I have created two screencasts (please, bear with me, this is the first time I'm doing it in english). The first one is based on a famous article at CodeProject and the second one uses the great Spread for Windows Forms from FarPoint.

The best way to attach a unit to a numerical value in the PropertyGrid

When you expect your end-user to enter a numerical value in a given unit, you usually want to make this information available near the editor. Entering a value in millimeter or centimeter makes a difference and it is mandatory to clear the ambiguity. In the Microsoft PropertyGrid or in SPG, it could be done like this:

• Write this information in the comments area at the bottom of the grid. But what if you don't want to display this area?
• Put it in the property label: "Frequency (in Hz)". Not very friendly since usually you like to read the unit after the value.
• Use a derived TypeConverter so that you can have the value and its unit in the textbox. But in this case you are obliged to write the converter and you make the user think he can edit the unit.

The next release of SPG simplifies all this by extending the FeelEditUnit inplace control. You just pass the unit to the second value of the property (yes, SPG handles multiple value types per property). It can be passed as a string or as a collection containing only a single element).

When the property is not selected, you see this:

When it is selected and edited, you see a nice readonly unit, still in the value column:

As usual, the unit can be targetted in an instance or added on the fly with a call to AddManagedValue.

Two values in a single DateTimePicker

To set two different dates in an application, e.g. a starting time and an ending time, you need two labels and two editors (as far as times are concerned) as showcased in this Outlook screenshot:

SFPE can reduce the space used inside a single editor and the result would look something like this:

Here is how it's done:

SFPE defines a new DateTimePicker class. But we won't use this one here. It is a convenient class that mimics the API of the Microsoft DateTimePicker so that you get all the benefits of SFPE in a class that won't require you to learn something new. As such, it allows and creates only one FieldPack and this is the FieldPack that holds the value. So we will rely on its base class, called FieldPackEditor. But still the job will be easy:

fieldPackEditor1.JumpToNextFieldOnEdition = true;

DateTimeFieldPack pack = new DateTimeFieldPack("'From 'HH:mm");
fieldPackEditor1.AddFieldPack(pack);
pack.SeparatorWidth = 6;
pack.Value = new DateTime(2007, 9, 12, 13, 30, 0);

pack = new DateTimeFieldPack("'to 'HH:mm");
fieldPackEditor1.AddFieldPack(pack);
pack.Value = new DateTime(2007, 9, 12, 15, 0, 0);

I first configure the editor so that the editing is minimal. "JumpToNextFieldOnEdition" moves the focus cue to the next editable field when the user is done with the current field. Then I create a first DateTimeFieldPack instance that will hold our first time. The pack is added to the editor and a nice margin is set. At last I create the second pack that will hold the second time value. This is all it takes to get what you see in the screenshot.

Smart FieldPackEditor.Net prices explained

SFPE.Net is due out very soon, so I'm just giving the final touches like preparing the web site, building installation packages and creating license files. I have also finalized the price plan and I wanted to share with you why it looks like this:

I want to emphasize several important points:

1. Some of you will want to replace the old MS DateTimePicker and that's it. The option starting at 49$ is for you. It is very affordable and not too low (some people think that too low means "no value"). At this price, replacing all your DateTime pickers should be seen as a bargain since you get what you needed (at last you get rid of the MS DTP) + a complete framework the day you want to go a step further.
2. Let's take now the most popular option "source code with a one year subscription" which costs 99$ for one developer. I chose this price carefully. It is typical of this kind of full featured component and won't scare your company to buy one or more. If you already know the quality of the support I give you, then you realize how much value is packed in this product.
3. The discounts applied for the volume purchases is also far more aggressive than for SPG.Net. The site license is calculated on a 70% discount basis! My wish here is to make this option so affordable that medium to big companies won't wonder very long if they should purchase the library for their department A but not for department B. By getting the site license at this price you win the peace of mind by being sure that any of your developers can include the component in any of your applications.

Performance hit under Vista ... solved!

Some customers reported the following problem under Windows Vista: when positionning the mouse over the PropertyGrid, the cpu was raising at 100% and as a consequence the grid was experiencing redrawing problems when expanding nodes, checking radiobuttons, etc. I worked this week on this issue and discovered the culprit: VisualTips.

This wonderful component from Skybound was indirectly sending a ton of MouseMove events to the grid (and to any control on the form). The cause of this behaviour has not been found precisely but the people there fixed the bug related to another 100% cpu symptom. If you are using VisualTips and your product also targets Windows Vista, you have to get their update.

VisualHint’s web site has been reviewed by Bob Walsh from 47hats.com

As a customer or visitor of this web site, this is maybe not the post you wish to read. It won’t talk about PropertyGrids, DateTimePickers or other editors but about the design and the life of this web site. As a micro independant software vendor (aka mISV) and specialist of software development it is sometimes difficult to create a good website, attract customers with perfect descriptions and screenshots of products as well as interesting and relevant informations. On the other hand it’s very easy to loose the focus on all of these while writing C# code to enhance or create products. That’s why some time ago I asked Bob at 47hats to include VisualHint in his weekly review of mISVs web sites.

Bob owns a "mISV type" company and he even wrote a book about it. He is now considered an authority in this domain and launches a consulting firm to help independant workers like me. Last week, he informed me that the review for VisualHint was in the work and here is the result: review at 47hats.com.

From this review, I keep the following criticisms:

• SPG.Net is not correctly introduced.
• Its important features, your benefits, are listed too deeply in verbose text.
• My english may be suitable to talk to you in a blog must not for the business part of the web site.
• Where is the testimonials page?

Of course I also read positive elements which confirm the qualities of VisualHint:

• The web site is very pleasant to read.
• My second product, Smart FieldPackEditor.Net has been introduced correctly, especially with the help of screencasts.
• The support given to customers, as it appears on the site, is excellent (it is also excellent when I actually give support).
• This is honest to introduce VisualHint on the about page the way it is really: driven by a passionate developer.

From there, I have to plan the changes that I will bring to the site (the testimonials page has already been added). This will mainly concern the spg.net product and the level of written english. If you have your own view on what is missing or badly shown, don't hesitate to add it in the comments.

A true IP address control for windows forms

Some days ago, I was asked by a visitor if it is possible to edit an IP address in Smart PropertyGrid with a specialized editor. The short answer was no. But then I realized that the FieldPackEditor would make a wonderful IP address editor. So I derived a new editor from the base class, created special IpAddrSegmentFieldPack and IpAddrSegmentField classes and voila!

Like with other field pack editors, you can show updown buttons, handle a null value, have fixed-width fields or not, set the Text and Value properties and use all the usual keys to edit the address. I think this is the first time we have a so complete IP address editor for windows forms (let me know if there is some competition). You can now play with it in the updated sample and you will see it soon in the PropertyGrid too.

A new year begins for VisualHint

Yes, this is like a new year beginning here. I was in vacations in France during three weeks for a break from VisualHint, with family in Normandy by the sea not far from the american cemetery for those who know this place. This was very relaxing and the kids had a lot of fun with the beach activities (when one lives in Montreal at four years old, the sea is something new). Now that I'm back, this is time to take stock of the VisualHint's future. So how is it going here you will ask. Here is the short answer:

I highlighted May 2006 because at that time I posted a message titled Incredible month of May. You can now see the comparison with my last recorded month. This has almost doubled, so yes, I’m very happy about the evolution of Smart PropertyGrid.Net and its sales. Notice the two spikes, one downward from the mean curve and one upward. The first one is August 2006: activity was very low and I also took some vacations. The second one is November 2006: I can’t really explain it but it seems like a lot of companies wanted to do their shopping before the month of December and Christmas.

So now what? It took me up to today to almost clear all the cutomer requests received during my absence. Still a few ones and I will be done. All the fixes generated will be available very soon in a maintenance release, I guess sometime next week. Then I will come back on the new FieldPackEditor product to finalize it and take it out of beta. Once done, it will be time to define the major new features of SPG v.3. I think the summer break with its low activity will be a very good time to do that. For those who take their vacations, I wish a lot of fun and rest.

More about null values in a DateTimePicker

Before releasing version 1.0 of Smart FieldPackEditor.Net I must ensure that the support for null values is really complete. So what does this feature really involves?

First let’s remind in what contexts a DateTimePicker can operate:

1. It can be a standalone control and completely encapsulate a DateTime value.
2. You can manually bind one of your properties to the component’s Value property.
3. You can embed the component in a container like the DataGridView. In this case, the component will be automatically bound to a particular column of a database table via a DataSource.
4. You can embed the component in a container like the PropertyGrid. This will bind the component to a DateTime property somewhere in your code.

In the first case, the support for null values is straightforward. The component stores the DateTime value as an object so it can use anything for the object representing a null value.

We have to think a bit more for the other cases. What can be the type of your property in a target instance? Obviously this can be an object (not very common to store a date but still feasible), a nullable DateTime (aka “DateTime?”) or a DateTime. In the first case, there is again no difficulty: we can assign anything we want to represent a null value. In the second case we have less choices: it can be null or a particular DateTime value that is out of the bounds specified by the MinDate and MaxDate properties of the DateTimePicker (anything before 1753 will be fine). In the last case, with a DateTime type, there are no choices: you can only use a specific DateTime value like 01/01/0001 for example.

Now let’s relate the context of use with the data type you have in your client application:

In case 2, you can target any of the three data types we just saw. The value representing null will be chosen in accordance with the restrisctions seen above and setup in the editor. In case 3, the value representing null will usually be DBNull.Value. But for historical reasons you may have a specific DateTime value in your database that represents the null value. In both cases, again, the editor must be setup for that. In case 4, well, it’s like case 2.

Everything that has been mentioned so far implies that we need a set of properties to properly setup the DateTimePicker:

• NullValue: instructs the editor about what will represent a null value. It will typically be null, DBNull.Value or a specific DateTime value. But it could also be a string like “nothing”.
• NullText: the string displayed in the editor when Value == NullValue.
• HasValue: convenient property to test for nullity.

If you use the DateTimePicker in other very specific contexts and you need support for null value, please let me know.