"We had just exhausted the capabilities of the standard Microsoft PropertyGrid and had started writing our own extensions when we found SmartPropertyGrid. SPG negated the need for custom extensions whilst greatly simplifying and accelerating our product development.
We recently commissioned one of our expert users to do some Alpha testing and here is a direct quote from his first report:
"I'd say the model build takes around 70-80% of the time required using the existing interface, and with more experience with the new interface could reduce the time a bit further still - it really is that good!"
He is referring to the process of building transportation models using the new version of the product versus the previous version - which was based on individual object editor dialogs.
I can say in all honesty that a large part of the credit for this goes to SPG."
Did you know that the Microsoft PropertyGrid is not able to let the user set a common value for collections coming from multiple target instances? Take a list or an array, this is the same story. The CollectionEditor will popup, you will alter the displayed collection and when you hit OK, nothing happens. Well, up to last week, this was the same in SPG. But with the new build, you can now edit collections when you target multiple instances with SelectedObjects. Here is a screencast to see it live:
When I decided to fix the behavior of the grid regarding multiple target instances, I though it would be difficult and that after a lot of efforts it would produce a release perceived as minor (something that should be version 2.2.6) because this feature should have worked from the beginning or at least from version 2.0. So I gathered my courage and began investigating. I still learned a lot during the process and I realized that I could do better than what the Microsoft PropertyGrid does when it targets several instances.
The Microsoft grid is lost as soon as you target two instances that have common properties but whose values differ. From my point of view, this is not logical so I did my best to fix this behavior and I succeeded (there are some screencasts about this subject). The result is a release that you can consider major, and therefore labelled 2.5. Moreover I took the chance to add some very demanded features. Here are the more important points of the changelog:
SelectedObjects has been reworked and SPG now behaves correctly regarding multiple instances. It even allows comparisons of immutable properties (the one whose TypeConverter's CreateInstanceSupported returns true) having different values.
Displayed values (set by PropertyValue.ResetDisplayedValues or by the PropertyValueDisplayedAsAttribute) are more flexible. Before you could only set them as strings. You can now supply objects or pairs
Trackbars now accept to target integer, float, double and decimal property types.
Ctrl+Enter in a multiline textbox inserts a new line.
By default, a listbox uses the same visuals (font, fore and back colors) than the property value. It is now possible to break this synchronization and let the listbox use the normal colors used by the grid. This is done by using the DropDownListboxVisuals attribute.
The List feel can use a cache for properties showing a costly content that should not be recreated each time the listbox is displayed. To configure a property in such a way, mark it with UseFeelCacheAttribute. The cache can be emptied by setting PropertyValue.FeelCache to null.
The Unit inplace control now takes into consideration a unit with a single value (a collection with a unique possible value or a simple string). In this case, no dropdown is shown and the value is just displayed as a static information.
For list feels, the resize box can be removed by setting the PropInPlaceList.PreventResizable to true (from the InPlaceCtrlVisible event handler).
I hope you will like this this verson as much as I worked on it. If you have any question, if you are not sure what SPG can do for you or if it does a particular thing, don't hesitate: contact me.
This was a long time requested feature: being able to attach a trackbar feel to any type of numerical value. As a last minute surprise in SPG 2.5 (which is in beta), I implemented it for integers, floats, doubles and decimals (it’s ready for more but let’s see what you actually need in the future). The feel still needs a PropertyValidator attached to it so that it can have the minimum and maximum values. There is also a new attribute (TrackBarSettings) to set the Resolution (new notion for floating point numbers) the SmallChange and LargeChange properties.
Since at the same time, a customer had troubles with a property of type PointF and its associated TypeConverter, I updated the sample with such a property showing the new trackbar for the X and Y child properties. Here is a screenshot of this nice arrangement:
If you need the PointF TypeConverter, feel free to download it. It is simply based on its counterpart for the Point structure.
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
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:
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.
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.
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");
pack.SeparatorWidth = 6;
pack.Value = new DateTime(2007, 9, 12, 13, 30, 0);
pack = new DateTimeFieldPack("'to 'HH:mm");
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.
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:
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.
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.
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.
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.
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.