Filter objects

In a more complex case you would have to test which phase of the filter was active in the method but in this case we can assume it is the BeforeDraw phase:

bool Infragistics.Win.IUIElementDrawFilter.
   DrawElement(Infragistics.Win.DrawPhase 
    drawPhase, ref Infragistics.Win.
        UIElementDrawParams drawParams)
{
 MessageBox.Show("Button Draw");
 return true;
}

Returning true aborts the phase that has been filtered and so in this case the button will not draw itself.

To put the filter into action all we have to do is create an instance:

MyDraw MyDrawObject = new MyDraw();

and set the control to make use of the filter:

ultraButton1.DrawFilter = MyDrawObject;

Now when the button is about to draw itself the filter DrawElement method is called and the MessageBox appears and the button isn't drawn.

All of the filters work in the same way and you can share filter objects between different controls and a single filter object can deal with multiple phases. It is very simple and very powerful. With the button's BeforeDraw filter installed you are free to draw the button in its entirety yourself.

Appearance objects

What else do we get from the PLF?

Appearance objects are another simple but neat idea. You customise controls by setting their properties but often properties need to be set in blocks to create a style say. The lowest level the PLF offers for you to do this is via an Appearance object. An Appearance object has all of the properties that a control has and you can set them in the usual way. Once you have a customised Appearance object you can set any control's Appearance property to it. Each of the Appearance object's properties that have been defined are then use to set the properties of the control. You should be able to see that one Appearance object can now be used to style any number of controls as a style group.

Appearance properties

Not only this but controls also have other Appearance properties that set what they look like in different situations. For example, the HotTrackAppearance property sets what it looks like when the mouse is over it, the PressedAppearance controls what the button looks like in the pressed state and so on. So you can now create multiple Appearance objects and use them to set the way a control looks in different states.

For example, place a button on a form and create an Appearance object suitably customised with a background gradient fill:

Infragistics.Win.Appearance app1 = 
     new Infragistics.Win.Appearance(); 
app1.BackColor = Color.AliceBlue;
app1.BackColor2 = Color.Black;
app1.BackGradientStyle = 
Infragistics.Win.GradientStyle.Elliptical;

Once you have this object you can use it to change the style of any control. For example:

ultraButton1.Appearance = app1;

There is one small complication. All of the controls also so support OS Themes. You can think of these as Appearance objects that are set by the currently user selected OS Theme. The OS Theme takes precedence over many of the properties that you can set. So to make the previous Appearance object take control of the background of the button you also have to add:

ultraButton1.UseOsThemes = 
 Infragistics.Win.DefaultableBoolean.False;

to turn off the OS Theme support.

Other architectural features

These are what I consider highlights of the way that that Forms architecture has been extended but there are some others.

For example, KeyActionMappings provide a table-driven way of controlling what happens when a user hits a particular key.

Many but not all controls have an event manager which allows you to switch off events in a single operation.

Complex controls with many child elements also use a property change notification system to update just the child elements that are associated with a value change and propagate them up any hierarchy to ensure consistency - without having to refresh the entire control.

What is also interesting is that a logical organisation like this provides other opportunities to improve the use of the controls. For example, in the latest version a set of embeddable  editors that can be used to render or edit values from within another component's UIElements. These make it much easier for the user to edit the contents of controls.

Even more interesting is the way that the use of the Application object can be extended into an Application Styling Framework (ASF).  A standalone AppStylist can be used outside of Visual Studio to allow a designer to manipulate the way controls look. There is also a runtime version which can be launched to allow runtime changes to be made using the same general interface. Notice that these don't allow the UI of your application to be modified. They simply display the way all of the standard controls look in the particular style. That is if the style is set to show a red button then all of the buttons in you UI will be red.

You can guess how these facilities work - they simply generate custom Appearance objects that can then be used with the project. Simple and efficient. To go beyond this we also have the idea of a style library - an XML description that can be loaded and applied before the application is displayed. The style editors create the style library which you simply load before the first graphical element is displayed. Who needs Expression Blend?

.NET Advantage for Windows Forms may not go as far as WPF but there are many who think that WPF goes too far. If you want to stick with Forms this is worth thinking about.

Download a free trial evaluation from the Infragistics site.