The main reason for that is the following: I guess to provide the same functionality they had in version 5 where you can define groupings and columns and their widths they had to resort to some wicked stuff in the code. I had to find this out the hard way when I tried to modify an existing standard report. When I looked closer into the select statement in the report I saw that this was a dummy statement that is nothing but a placeholder.

I assume, Deltek does the following: each standard report is bound to a specific options dialog in the custom properties of the report. This options dialog then creates a SQL statement on the fly, based on the report options you configure in VISION. It then replaces the statement in the report on runtime. Based on the named tables and columns then the dialog code goes through the report and applies any additional formatting just before the report is processed.

This has some major implications when you want to modify a report. I ran into the following issues:

1. You are not able to add additional columns to the select statement (except the invoice report) because the select statement is created on-the-fly.
2. You get a runtime error every time you add a custom column to a table that VISION tries to modify at runtime based on the formatting options.

Problem 1 is a tougher one. You actually have to create custom code in the report that connects back to the server and looks up additional data for each record of your report. I will have some details on that on my next blog entry

Problem 2 is easier to solve if the data is already supplied by the standard report and you just want to make the data visible. The trick here: you cannot modify the original table because you would run into that runtime error. So you do the following:

• Copy the original table and rename it
• Hide the original table (don’t delete it because VISION will still try to modify it)
• rename the copy and add or remove any column

What this does is the following: it connects to the same dataset as the original table so you can access the on-the-fly data select that VISION sent in. But because it will only try to alter the layout of the original table you don’t run into any errors. Biggest draw-back: any formatting you specify in the options dialog will have no effect to your table copy so you will have to do that manually and hard-coded.

After you did your modifications, you can upload the report either as custom report or simply replace the standard report. The beauty of uploading it as a custom report: you still reference the original options dialog. So when you start the report you get the same options dialog as the original – just with some different behaviour.

SQLDoc has no tool to copy the documentation from one DB to another.

And that’s the problem because SQLDoc (and other tools including SQL Management Console itself) put the documentation text into the extended properties of SQL Server 2000 and SQL Server 2005, so you cannot simply copy the documented tables, procedures or functions within the help file. And documenting on the master DB did not prove usefull for us.

So I checked the internals of the extended properties on SQL Server and found out that it uses the procedures sp_addextendedproperty and sp_dropextendedproperty and the internal, undocumented system table SYSPROPERTIES to save the documentation text onto the database. The SQL-Script below will extract your documentation and produce the needed procedure calls in the result window. Simply copy the text from the result window and execute it on the other database. The other database has to have the same schema of course! And because the existence of an extended property is not checked before you will receive some errors when executing the sp_drop… procedures, but this has no effect on the db.

Here’s the script:

 

DECLARE @name NVARCHAR(4000),          @value NVARCHAR(4000),          @level0type NVARCHAR(4000),          @level0name NVARCHAR(4000),          @level1type NVARCHAR(4000),          @level1name NVARCHAR(4000),          @level2type NVARCHAR(4000),          @level2name NVARCHAR(4000)         DECLARE @statement NVARCHAR(4000)DECLARE cloop CURSOR LOCAL for         SELECT   S.NAME AS NAME,                  REPLACE(CAST(S.VALUE AS NVARCHAR(4000)), ””, ”””) AS VALUE,                   ‘USER’ AS LEVEL0TYPE,                  ‘dbo’ AS LEVEL0NAME,                  CASE O.XTYPE                            WHEN ‘U’ THEN ‘TABLE’                           WHEN ‘P’ THEN ‘PROCEDURE’                           WHEN ‘FN’ THEN ‘FUNCTION’                           WHEN ‘TF’ THEN ‘FUNCTION’                           WHEN ‘IF’ THEN ‘FUNCTION’                           WHEN ‘V’ THEN ‘VIEW’ END                   AS LEVEL1TYPE,                 O.NAME AS LEVEL1NAME,                 CASE S.TYPE                           WHEN 4 THEN ‘COLUMN’                           ELSE ‘NULL’ END                   AS LEVEL2TYPE,                 CASE                           WHEN ISNULL(C.NAME, ”) = ” THEN ‘NULL’                           ELSE C.NAME END                   AS LEVEL2NAME         FROM     SYSPROPERTIES S                  JOIN SYSOBJECTS O ON S.ID = O.ID                  LEFT JOIN SYSCOLUMNS C ON S.ID = C.ID AND S.SMALLID = C.COLORDER                  –LEFT JOIN SYSINDEXES I ON S.ID = I.ID AND S.SMALLID = I.INDID         WHERE    S.NAME = ‘MS_Description’         ORDER BY 5,6,7,8         OPEN cloop

FETCH next FROM cloop INTO @name, @value, @level0type, @level0name, @level1type,

@level1name, @level2type, @level2name WHILE @@FETCH_STATUS = 0BEGIN         –drop property         SET @statement =                 ‘exec sp_dropextendedproperty N”’ + @name + ”’, ”’                   + @level0type +  ”’, ”’ + @level0name + ”’, ”’                  + @level1type +  ”’, ”’ + @level1name + ”’, ”’                  + @level2type +  ”’, ”’ + @level2name + ””                          SET @statement = REPLACE( @statement, ”’NULL”’, ‘NULL’)                  PRINT ‘/*’ + @level1type + ‘: ‘ + @level1name + ‘*/’                  PRINT @statement                  PRINT ‘GO’         –add property         SET @statement =                   ‘exec sp_addextendedproperty N”’ + @name + ”’, N”’ + @value + ”’, ”’                   + @level0type +  ”’, ”’ + @level0name + ”’, ”’                  + @level1type +  ”’, ”’ + @level1name + ”’, ”’                  + @level2type +  ”’, ”’ + @level2name + ””                          SET @statement = REPLACE( @statement, ”’NULL”’, ‘NULL’)                  –PRINT ‘/*’ + @level1type + ‘: ‘ + @level1name + ‘*/’                  PRINT @statement                  PRINT ‘GO’ 

                 FETCH next FROM cloop INTO @name, @value, @level0type, @level0name,

                       @level1type, @level1name, @level2type, @level2name         END         CLOSE cloop         DEALLOCATE cloop

Positive:

It runs on any OS that supports the .net-Framework; means it will run on non-XP Systems like Win95 and Win2000. That said, I must also tell you that the theme listener and the grouping and tiling of the XPListGroup won’t work without Win XP.
I didn’t have to write a lot of API-calls

Negative:

If Microsoft introduces a new theme or you download one from the internet, the controls will not support this one until it’s hardwired into the code.
As a workaround for the negative part I have exposed all properties of the theming formats to the IDE so you can define any combination of formats you want.
The collection of controls grew over time and include now balloon tips, cue banners, a textbox provider, panes, …
The newest addition are the Windows Forms Stylesheet (a separate project before) that will allow you change properties of your forms and controls at runtime, based on a xml definition file (similar to CSS in HTML).

Source Code

You can find the XPCC code and controls at http://www.codeplex.com/xpcc

When designing common Windows Forms Application, it always turns out to be a bit of a hassle to synchronize different UI elements like a MenuItem and a Toolbar Item that execute (or should execute) the same code or should be activated and deactivated at the same time.

Using Commands

One Solution to this problem is to delegate the work to a command class and then attach one or more UI elements to this class. The Command Class will then be in charge of executing commands, enable, disable, hide or show the attached elements.

In a future version I will provide a command extender that can be dragged onto a form and UI elements can then be attached to it. Meanwhile you will find some code that will allow you to use those command classes in code.

Using command classes in code has advantages too. You can create your very own application model with all the commands you need in your app as you will see in the demo app.

The Command Class

The Command Class itself contains a collection of attached components, some properties that will be explained shortly and some events that are used to inform the commands containing class of any changes in the command class.

Public Properties

There are three Properties (PropagateEnabled, PropagateVisible, PropagateText) that will allow one attached component to change the command’s Enabled, Visible or Text Property which will in turn propagate those changes to all other attached components. Setting the Visible and Enabled Property directly on the command object will always result in the propagation of the property value to all attached components.

The standard behaviour of the Text property is to NOT PROPAGATE to all attached components because this could end in some „funny“ scenarios because you could also attach textboxes to the command class. On the other hand, propagating the Text can be useful if the menu item or button should display certain states and be constant over all attached components.

Dim WithEvents MyCommand as New Command

MyCommand.PropagateEnabled = True

MyCommand.Add( menuItem1 )

MyCommand.Add( toolbarItem1 )

…

‘this will disable menuItem1 AND toolbaritem1

menuItem1.Enabled = False

Public Methods

The Add- and Remove-Method allow you to attach any Control or ToolStripItem to a command. Because most controls support an Enabled or Visible property, attaching textboxes, buttons and/or menu items to one command you can design highly interactive UI that could disable or hide a wide range or elements by simply setting one command property.

Calling the Clear method will remove all attached components at once.

The Execute Method will invoke the Click handler which can be intercepted in the parent class and the apropriate code can be executed for this command.

Using the Command Classes

The code includes a very simple editor application that will allow you to open, save and edit a text file. The editor’s behaviour is not programmed into the form. The project has a shared class called EditorApplication that includes all methods and commands that can be executed from the editor. It also supports some events that the editor can use to show changes.

The EditorApplicationClass

As mentioned before, all the behaviour is in this class. All methods and events are declared shared so that the class must not be instantiated but can be used immediately in the main form. The class has a child class called Commands where all available commands for this application are defined. The class also includes the event handling of each command which in return calls a method of the EditorApplication.

Public Class EditorApplication

Public Class Commands

Public Shared WithEvents OpenFile As New Command

Public Shared WithEvents SaveFile As New Command

Public Shared WithEvents CloseFile As New Command

Public Shared WithEvents NewFile As New Command

Public Shared WithEvents ChangeFont As New Command

Public Shared WithEvents SaveFileAs As New Command

Private Shared Sub ChangeFont_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles ChangeFont.Click

EditorApplication.ChangeFont()

End Sub

Private Shared Sub CloseFile_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles CloseFile.Click

EditorApplication.CloseFile()

End Sub

…

End Class

Public Shared Sub CloseFile()

If Not CheckFile() Then Exit Sub

CurrentFile = “”

Content = “”

IsDirty = False

IsNew = False

Commands.SaveFile.Enabled = False

Commands.SaveFileAs.Enabled = False

Commands.CloseFile.Enabled = False

End Sub

…

End Class

The EditorApplication keeps track of the current file, the current content and any status changes and raises events or changes commands accordingly.

The Editor Form

The editor form itself is very simple. You can define all UI elements by dragging them from the toolbox. In a next step you go to the Load event of the form and attach every UI elemtent to the related command object of the application class. You then hook up any EditorApplication Event you’re interested in and then you’re ready to go.

Private Sub AttachCommands()

EditorApplication.Commands.ChangeFont.Add(ChangeFontToolStripMenuItem)

EditorApplication.Commands.ChangeFont.Add(tsChangeFont)

EditorApplication.Commands.CloseFile.Add(CloseToolStripMenuItem)

EditorApplication.Commands.NewFile.Add(NewToolStripMenuItem)

EditorApplication.Commands.NewFile.Add(tsNew)

EditorApplication.Commands.OpenFile.Add(OpenToolStripMenuItem)

EditorApplication.Commands.OpenFile.Add(tsOpen)

EditorApplication.Commands.SaveFile.Add(SaveToolStripMenuItem)

EditorApplication.Commands.SaveFile.Add(tsSave)

EditorApplication.Commands.SaveFileAs.Add(SaveAsToolStripMenuItem)

End Sub

Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load

AttachCommands()

AddHandler EditorApplication.FileChanged, AddressOf OnFileChanged

AddHandler EditorApplication.ContentChanged, AddressOf OnContentChanged

AddHandler EditorApplication.FontChanged, AddressOf OnContentFontChanged

AddHandler EditorApplication.StatusChanged, AddressOf OnStatusChanged

rtfText.Enabled = False

EditorApplication.Commands.SaveFile.Enabled = False

EditorApplication.Commands.SaveFileAs.Enabled = False

EditorApplication.Commands.CloseFile.Enabled = False

EditorApplication.CurrentFont = Me.rtfText.Font

End Sub

…

Private Sub OnStatusChanged(ByVal sender As Object, ByVal e As EventArgs)

Me.Text = String.Format(”{0}{1}”, EditorApplication.CurrentFile, IIf(EditorApplication.IsDirty, “*”, “”))

If EditorApplication.CurrentFile = “” And EditorApplication.IsNew = False Then

rtfText.Enabled = False

End If

End Sub

Here’s mine: I created a procedure that takes the displayed fields, the table(s), the filter (or where clause), the grouping, the sorting clause, the page size (rows per page) and the requested page as parameters.

The procedure then creates a a sub-select that returns all rows from the first row to the [pagesize] * [requested page] row. Then the procedure creates a select that returns the bottom n rows (page size) by flipping the sort order and returning the TOP n rows of the subselect. In the last step the Resultset is sorted once more by the initial sorting clause to get the rows in the requested order.

You must provide at least one sorting criteria to make it work! After that you can run this procedure on any database you have. You can also join tables simply by adding the join statement into the table parameter, but DO NOT use the table identifier with the fields parameter (like ‘Suppliers.CompanyName’). It’s better to always use a defined View over your paged data..

Hope you like it:

– ************************************************************************
– delete any existing procedure
– ************************************************************************
if exists (select 1 from sysobjects where name = ’sp_genericPaging’ and xtype = ‘P’)
begin
drop procedure sp_genericPaging
end

GO

create procedure sp_genericPaging
@fields nvarchar(4000),
@table nvarchar(4000),
@filter nvarchar(4000) = ”,
@grouping nvarchar(4000) = ”,
@sort nvarchar(4000) = ”,
@pageSize int = 100,
@page int = 1
as

set nocount on
declare @statement nvarchar(4000)

– ****************************************************************************
– prepare a subselect for the last matches
– ****************************************************************************
set @statement =
‘(SELECT TOP ‘ + cast((@pageSize * (@page)) as varchar(100)) + ‘ ‘ + @fields +
‘ FROM ‘ + @table +
case when isnull(@filter,”) != ” then ‘ WHERE ‘ + @filter else ” end +
case when isnull(@grouping,”) != ” then ‘ GROUP BY ‘ + @filter else ” end +
case when isnull(@sort, ”) != ” then ‘ ORDER BY ‘ + @sort else ” end + ‘) SUBSEL’

– ****************************************************************************
– flip the sort clause
– ****************************************************************************
declare @pos int, @idx int, @len int, @substr nvarchar(250), @retsort nvarchar(400)

set @retsort = ”
set @pos = 1
set @idx = 1

if len(@sort) > 0
begin
while @idx > 0
begin
– find commas
set @idx = charindex(’,', @sort, @pos)
–check length
if @idx = 0
set @len = len(@sort) – @pos + 1
else
set @len = @idx – @pos
– cut out criteria
set @substr = substring(@sort, @pos, @len)
– reset positioning
set @pos = @pos + @len + 1
– change sorting
if charindex(’desc’, @substr) > 0
begin
set @substr = replace(@substr, ‘desc’, ‘asc’)
end
else if charindex(’asc’, @substr) > 0
begin
set @substr = replace(@substr, ‘asc’, ‘desc’)
end
else
begin
set @substr = @substr + ‘ desc’
end
– recreate flipped sorting
set @retsort = @retsort + case when len(@retsort) > 0 then ‘, ‘ else ” end + @substr
end
end
else
begin
set @retsort = ”
end

– ***************************************************************************
– add the paging select
– ***************************************************************************
set @statement =
‘(SELECT TOP ‘ + cast(@pageSize as varchar(100)) + ‘ ‘ + @fields +
‘ FROM ‘ + @statement +
case when isnull(@retsort, ”) != ” then ‘ ORDER BY ‘ + @retsort else ” end + ‘) PAGESEL’

– ***************************************************************************
– flip the sorting once more to get the correct sorting
– ***************************************************************************
set @statement =
‘SELECT ‘ + @fields +
‘ FROM ‘ + @statement +
case when isnull(@sort, ”) != ” then ‘ ORDER BY ‘ + @sort else ” end + ”

– ****************************************************************************
– execute the selection and return the resultset
– ****************************************************************************
exec(@statement)

GO

/*testselect*/

exec sp_genericPaging
‘ProductID, ProductName, CompanyName, UnitPrice’, –feldnamen
‘Products join Suppliers on Products.SupplierID = Suppliers.SupplierID’, –tabelle(n)
”, –filter (WHERE)
”, –grouping
‘ProductID’, –sort
20, –pagesize
3 –currentpage

With the advent of VB.net there seem to be 3 distinctive ways to accomplish this task. With the XPTextbox-control I tried them all and will explain them shortly and point out the advantages and disadvantages.

Inherit a Textbox

The most elegant way of enhancing the textbox would be inheritance of course. This will give you everything from the textbox plus all the things you add to your derived class.

This works great for any functionality (like input validation, … ) that does not impact the visual design of the textbox. Because of the distinctive way a textbox is incorporated into the OS (especially with WinXP), you do almost nothing to display a different border style, border color or other visual elements inside the textbox.

Because of these problems I had to skip this approach and try the next one

Incorporate a Textbox in a Usercontrol

The next thing I tried, was the same approach you’d take in VB6. I created a user-control that hosts a textbox and all the “skinning” and UI design takes place inside the user-control but outside the textbox itself.

This approach has some advantages like the capsulation of the control and the design-time interaction in VS.net. You only have to override the OnPaint-Method of the user-control and paint whatever you like into the user control.

It has one big disadvantage though: you don’t inherit the textbox, you just incorporate it. To give the developer the same properties, methods and events he is used to from the textbox control you have to wrap every single call or property of the textbox to the user control. This is a tedious task and also quite error prone.

I have done this to some extend with the XPTextBox control of the XPCommonControls suite. It draws a nice rounded border and a focus marker (an orange line like the tab control) when appropriate. But I did not wire up all the properties and methods and events from the text box to the user control. And a lot of mail came in requesting this or that property or method (Including databinding).

And since I don’t like to produce a lot of senseless source code I tried to find another solution to this problem

Using an ExtenderProvider

And while looking for a way of to give the themed controls of the XPCommonControls suite the ability to adapt automatically to any new theme in the OS I found the Skybound Website. Not only do they provide a .net wrapper for the uxTheme calls, they also extend the theming support of any .net Form.

They do so by using an ExtenderControl and then drawing the themes according to the control type.

I found this idea to be a very clever way of doing your custom painting. The approach has all the advantages and almost none of the disadvantages of the other approaches.

You write an extender control that hooks up to your form and then checks for any control type you’d like to owner-draw. You can even add a property that tells the extender if this instance of a control should be drawn or not.

You then override the OnPaint event of your parent form and draw any shape around the textboxes.

This way the developer has full control of any method/property of the textbox (since it’s still the original textbox type provided by Microsoft) but you can add any custom drawing to the form the textbox is attached to.

See the XPCommonControls XPTextBoxProvider class for an implementation of this approach.

Conclusion

As you can see, there are advantages and disadvantages to all approaches from above. But since the .net Framework offers us the possibility to write provider classes this will be my favorite way to add advanced behaviour to any standard control.

Having this kind of approach on any user-defined control would give the developer a powerful way of designing his application without forcing him to play around in the inner workings of the source.

So I decided to plunge into this topic and out came the little example you will see here.

(I’m also planning to recode most of the XPCommonControls to use this new Rendering approach)

How To

So I did some research on the topics of Renderers, RenderModes and other properties of the ToolStrip control and put together a little „recipe“ to cook up my own Rendering support for basically any user control.

Class Structure

If you want to support Rendering in your control you will have to build a lot of sattelite classes to get it working. In the following table I list all the classes I added for this little example (simply exchange the [Control] with your control’s name)

[Control]

Your UserControl that should be rendered.

You should split the control’s layout in multiple items so that the user must not alter the whole rendering but specific parts of it.

You will need a RenderMode property and a Renderer property of type [Control]Renderer that is set to the default rendering class (e.g. [Control]SystemRenderer.

You will then have to override the OnPaint method and call every Draw[Item] of the base renderer.

Protected Overrides Sub OnPaint( ByVal e As System.Windows.Forms.PaintEventArgs)
MyBase.OnPaint(e)
e.Graphics.SmoothingMode = Drawing2D.SmoothingMode.HighQuality
_renderer.DrawBackground( New BoxControlRenderEventArgs(e.Graphics, Me))
_renderer.DrawBorder( New BoxControlRenderEventArgs(e.Graphics, Me))
End Sub

[Control]RenderMode

An Enumeration with all Renderers your control will support „out of the box“. This should usually include „System“, „Professional“ and „Custom“, whereas the „Custom“ mode should not be set manually

[Control]Renderer

The base class for all Renderers of your control. You should set it to „MustInherit“ because it usually does not render anything. It does include all methods and events that are called from your Paint method and can be overwritten by inherited classes.

For each item of your control that should be rendered individually (like background, borders, texts, …) you will have to include the following methods and events:

Public Delegate Sub Render[Item]Handler( ByVal sender As Object, ByVal e As [Control]RenderEventArgs)
Public Event RenderBorder As RenderBorderHandler

Public Overridable Sub Draw[Item]( ByVal e As [Control]RenderEventArgs)
Call OnRender [Item] (e)
End Sub

Protected Overridable Sub OnRender[Item]( ByVal e As [Control]RenderEventArgs)
RaiseEvent Render[Item]( Me, e)
End Sub

By doing so, you or any other developer will be able to alter the rendering behaviour by simply overriding the Draw[Item] method.

[Control]SystemRenderer

This class inherits from the [Control]Renderer and overrides every Draw[Item] method to implement a XP-like rendering of the control.

[Control]ProfessionalRenderer

This class inherits from the [Control]Renderer and overrides every Draw[Item] method to implement a Office-like rendering of the control.

[Control]RenderEventArgs

This class holds all the information that the renderer classes need to render the control, most noteably the following properties:

AffectedBounds
a rectangle that defines the space where the renderer can draw into.

Graphics
the graphics reference from the controls OnPaint method

[Control]
a reference to the instance of the control itself

It is possible that you will have to implement multiple [Control]RenderEventArgs to cover all the specific needs of the rendering method of the item (e.g. a text to be drawn…)

An Example

I put together a simple example to show you how it can be done. I chose a simple rectangle control that has a border and a linear gradient as background.

It will support a system renderer that uses the new theming capacities of .net 2.0, a ProfessionalRenderer, that uses the Office style and a userdefined renderer, just to show how you can override the standard behaviour.

The BoxControlClass

This is the user control itself. A very simple control that displays a border and a background. Different to a regular approach, the BoxControlClass has no idea how this border and background will look like. This is the work of the Renderers.

The BoxControl has two items, the border and the background:

The BoxControlRenderMode Enumeration

This enumeration holds all the standard renderers that are provided with this control. Currently this is System and Professional. The Custom value is needed only for referring to a derived renderer class.

The BoxControlRenderer Class

This class is declared as MustInherit and is the base class for all renderers that can be attached to the BoxControl class. It implements the drawing methods for any part and its events. Here is an example of the background part declarations:

Public Delegate Sub RenderBackgroundHandler(ByVal sender As Object, ByVal e As BoxControlRenderEventArgs)
Public Event RenderBackground As RenderBackgroundHandler

”’ <summary>
”’ the entry point for the BoxControl painting calls.
”’ </summary>
”’ <param name=”e”>an EventArgs class that holds all the information
”’ needed for drawing the class</param>
”’ <remarks></remarks>
Public Overridable Sub DrawBackground(ByVal e As BoxControlRenderEventArgs)
Call OnRenderBackground(e)
End Sub

Protected Overridable Sub OnRenderBackground(ByVal e As BoxControlRenderEventArgs)
RaiseEvent RenderBackground(Me, e)
End Sub

The BoxControlSystemRenderer Class

This is the derived class of the standard renderer that provides system rendering services (it draws with the XP theming info). As you see, I did not overwrite the OnRenderBorder method because this renderer will not use any borders

Imports System.Windows.Forms.VisualStyles

Public Class BoxControlSystemRenderer
Inherits BoxControlRenderer

Private renderer As VisualStyleRenderer = Nothing
Private element As VisualStyleElement

”’ <summary>
”’ overriding this method to draw a custom background.
”’ </summary>
”’ <param name=”e”></param>
”’ <remarks></remarks>
Protected Overrides Sub OnRenderBackground(ByVal e As BoxControlRenderEventArgs)
MyBase.OnRenderBackground(e)

element = VisualStyleElement.Tab.Pane.Normal

If Application.RenderWithVisualStyles AndAlso _
VisualStyleRenderer.IsElementDefined(element) Then
renderer = New VisualStyleRenderer(element)
renderer.DrawBackground(e.Graphics, e.AffectedBounds)
Else
e.Graphics.FillRectangle(System.Drawing.SystemBrushes.Window, e.AffectedBounds)
End If

End Sub
End Class

The BoxControlProfessionalRenderer Class

This is the derived class of the standard renderer that provides professional rendering services (it tries to immitate the current MS Office styling). This class overrides both rendering methods to draw a custom background and a custom border

Imports System.Drawing
Imports System.Drawing.Drawing2D

Public Class BoxControlProfessionalRenderer
Inherits BoxControlRenderer

Private rect As Rectangle
Private bgBrush As LinearGradientBrush
Private linePen As Pen

”’ <summary>
”’ overriding the background rendering to draw a gradient filled rectangle
”’ </summary>
”’ <param name=”e”></param>
”’ <remarks></remarks>
Protected Overrides Sub OnRenderBackground(ByVal e As BoxControlRenderEventArgs)
MyBase.OnRenderBackground(e)

rect = e.AffectedBounds
rect.Inflate(-1, -1)
bgBrush = New LinearGradientBrush(rect, SystemColors.GradientInactiveCaption, SystemColors.InactiveCaption, LinearGradientMode.Vertical)
e.Graphics.FillRectangle(bgBrush, rect)

bgBrush.Dispose()
End Sub

”’ <summary>
”’ overriding the border rendering to draw a simple line
”’ </summary>
”’ <param name=”e”></param>
”’ <remarks></remarks>
Protected Overrides Sub OnRenderBorder(ByVal e As BoxControlRenderEventArgs)
MyBase.OnRenderBorder(e)

rect = e.AffectedBounds
rect.Inflate(-1, -1)
linePen = New Pen(SystemColors.ActiveCaption)
linePen.Width = 1
e.Graphics.DrawRectangle(linePen, rect)

linePen.Dispose()
End Sub
End Class

The BoxControlUserRenderer

This class also inherits from the baser BoxControlRenderer. But since it’s not included as a RenderMode you can only use it with setting the BoxControl’s Renderer property. This class hase some special features that allows you to set the background colors, border widths and so on at runtime to alter it’s rendering behavior.

Imports System.Drawing
Imports System.Drawing.Drawing2D

”’ <summary>
”’ this class provides a special rendering to the BoxControl
”’ where you can set colors and properties at runtime
”’ </summary>
”’ <remarks></remarks>
Public Class BoxControlUserRenderer
Inherits BoxControlRenderer

Private bgBrush As Brush = SystemBrushes.ControlLight
Private linePen As Pen = SystemPens.ControlLightLight
Private rndCorners As Corner = Corner.All
Private radius As Integer = 5
Private rect As Rectangle

”’ <summary>
”’ the background brush with which the renderer draws the background part
”’ you can set this property to a simple Brush or a gradient brush
”’ </summary>
”’ <value></value>
”’ <returns></returns>
”’ <remarks></remarks>
Public Property BackgroundBrush() As Brush
Get
Return bgBrush
End Get
Set(ByVal value As Brush)
bgBrush = value
End Set
End Property

”’ <summary>
”’ the pen with which the border around the control is drawn.
”’ Using a pen will allow you to set the border’s width, dotted lines
”’ and other properties
”’ </summary>
”’ <value></value>
”’ <returns></returns>
”’ <remarks></remarks>
Public Property BorderPen() As Pen
Get
Return linePen
End Get
Set(ByVal value As Pen)
linePen = value
End Set
End Property

”’ <summary>
”’ this property allows you to specify all or some corners that will be
”’ drawn with a rounded effect
”’ </summary>
”’ <value></value>
”’ <returns></returns>
”’ <remarks></remarks>
Public Property RoundedCorners() As Corner
Get
Return rndCorners
End Get
Set(ByVal value As Corner)
rndCorners = value
End Set
End Property

”’ <summary>
”’ the corner radius (in points) of the rounded edges.
”’ </summary>
”’ <value></value>
”’ <returns></returns>
”’ <remarks></remarks>
Public Property CornerRadius() As Integer
Get
Return radius
End Get
Set(ByVal value As Integer)
radius = value
End Set
End Property

Protected Overrides Sub OnRenderBackground(ByVal e As BoxControlRenderEventArgs)
MyBase.OnRenderBackground(e)
rect = e.AffectedBounds
rect.Inflate(linePen.Width * (-1), linePen.Width * (-1))
e.Graphics.FillPath(bgBrush, DrawingHelperClass.RoundedRect(rect, radius, rndCorners))

End Sub

Protected Overrides Sub OnRenderBorder(ByVal e As BoxControlRenderEventArgs)
MyBase.OnRenderBorder(e)

rect = e.AffectedBounds
rect.Inflate(linePen.Width * (-1), linePen.Width * (-1))
e.Graphics.DrawPath(linePen, DrawingHelperClass.RoundedRect(rect, radius, rndCorners))
End Sub
End Class

BoxControlRenderEventArgs

This class holds all the info needed for drawing the border and the background in the renderer classes. The EventArgs are pushed to the renderer in the OnPaint method of the BoxControl class

Public Class BoxControlRenderEventArgs
Inherits System.EventArgs

Private _affectedBounds As Rectangle
Private _graphics As Graphics
Private _box As BoxControl

Public Sub New(ByVal g As Graphics, ByVal box As BoxControl)
_graphics = g
_box = box
End Sub

Public ReadOnly Property AffectedBounds() As Rectangle
Get
Return New Rectangle(_box.Padding.Left, _
_box.Padding.Top, _
_box.Width – _box.Padding.Left – _box.Padding.Right, _
_box.Height – _box.Padding.Top – _box.Padding.Bottom)

End Get
End Property

Public ReadOnly Property Graphics() As Graphics
Get
Return _graphics
End Get
End Property
End Class

The Test Application

The Test Application allows you to apply multiple renderers to the BoxControl on the left. If you choose the Userdefined Renderer, you will be allowed to customize the rendering of the BoxControl further. Change the colors by double-clicking on the color-fields

Conclusion

The Renderer-Approach is a very nice but labour-intensive way of allowing your controls to be rendered by custom code. I will certainly implement this for most of the XPCommonControls.

Because I don’t want to break compatibility with the current release, I’m planning to create a new library with rendered controls only.