Visual Studio Data : WinForm

Writing Event Handler for controls in a DataRepeaterItem

John Chen — Wed, 09 Sep 2009 01:54:00 GMT

In the MSDN Visual Basic Power Packs forum, I had an embarrassing reply on a DataRepeater event handling question, in which the user asked why his event handling code did not work. Here is the original question:

“I want to be able to resize a textbox when a user clicks on a textbox within a datarepeater. So the textbox will start out as a single line, but would expand to be multiline to better allow the user to enter text. When the user's mouse leaves the textbox I want it to return to the original size. I tried changing the textbox.height, but nothing happens. Any help is appreciated.”

By looking at the question, I guessed that the user might forget to set the TextBox.MultiLine to true while trying to change the height. Without hesitation, I replied a sample code as below:

Private Sub TextBox1_MouseEnter(ByVal sender As Object, ByVal e As System.EventArgs) Handles TextBox1.MouseEnter

Me.TextBox1.Multiline = True

Me.TextBox1.Height = 50

End Sub

Private Sub TextBox1_MouseLeave(ByVal sender As Object, ByVal e As System.EventArgs) Handles TextBox1.MouseLeave

Me.TextBox1.Multiline = False

End Sub

Code Sample 1

The user then replied back that the Multiline was not the problem. My code did not work! What is happening?

The DataRepeater control is very intuitive to use and is close to the WYSIWYG experience. However, we need to remember that at run time, the repeater items are cloned using the repeater item template. At design time, we are working on the repeater item template. At run time, several sets of new controls are created to serve as the display of the visible repeater items. Public properties of a control are copied during the cloning process, so do the event handlers. If Button1 is a button in the data repeater item template, code sample 2 below works perfectly.

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click

MessageBox.Show("Hello")

End Sub

Code Sample 2

Now let’s take a look on code sample 1, the event handler is cloned and so the code will be called when the mouse enters or leaves the TextBox. However, the code does not work as expected because TextBox1 refers to the template version of the TextBox, which is hidden at run time. The underline TextBox that triggers the event is the cloned version of the TextBox and in the context it is the sender object. So I modified code sample 1 to code sample 3, accessing TextBox1 through the sender object. Tested and worked.

Private Sub TextBox1_MouseEnter(ByVal sender As Object, ByVal e As System.EventArgs) Handles TextBox1.MouseEnter

Dim txtBox As TextBox = TryCast(sender, TextBox)

If (txtBox IsNot Nothing) Then

txtBox.Multiline = True

txtBox.Height = 50

End If

End Sub

Private Sub TextBox1_MouseLeave(ByVal sender As Object, ByVal e As System.EventArgs) Handles TextBox1.MouseLeave

Dim txtBox As TextBox = TryCast(sender, TextBox)

If (txtBox IsNot Nothing) Then

txtBox.Multiline = False

End If

End Sub

Code Sample 3

I hope this example can help you better understand how the DataRepeater works. Keep in mind that the controls in the repeater item area we work on at design time are used for templates and we should not use them at run time unless you want to change the properties for all repeater items (please see Gavin’s blog: How to Change Appearance of all DataRepeater Items at Run Time). If you need to work on an individual control on a repeater item, use the sender object (as in code sample 1) and then get its parent and siblings if necessary. You can also get access to a DataRepeaterItem, which inherits from Panel control, and then you can access to all the controls in the control’s hierarchical structure. To illustrate this, I would like to change the original forum question to resize the TextBox whenever the current repeater item changes. Code sample 4 below is my solution.

Dim lastModifiedTxtBox As TextBox = Nothing

Private Sub DataRepeater1_CurrentItemIndexChanged(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles DataRepeater1.CurrentItemIndexChanged

' Get The TextBox1 from Me.DataRepeater1.CurrentItem

Dim txtBox As TextBox = Me.DataRepeater1.CurrentItem.Controls("TextBox1")

If (txtBox IsNot Nothing) Then

txtBox.Multiline = True

txtBox.Height = 50

End If

If (Not Object.ReferenceEquals(txtBox, lastModifiedTxtBox)) Then

If (lastModifiedTxtBox IsNot Nothing) Then

lastModifiedTxtBox.Multiline = False

End If

lastModifiedTxtBox = txtBox

End If

End Sub

Code Sample 4

In code sample 4, I use DataRepeater.CurrentItem property to get the current DataRepeaterItem and then I use Control.Controls property to return the cloned version of the TextBox1 in the current DataRepeaterItem. Notice that the cloned version of the TextBox is named as “TextBox1” as well, this is allowed at run time as long as it is named uniquely under the parent control (the DataRepeaterItem, in the context). Because there is no CurrentItemIndexChanging event, I use lastModifiedTextBox to remember the last modified TextBox and restore its state when necessary.

Lastly, I would like to point out again (as I have in my previous post) that the DataRepeater control applies a virtualization technique to display the data. So at run time, only a few DataRepeaterItems are created for display purpose. These DataRepeaterItems are reused by all data rows when they enter the visible range. So it is important that if you set a property on a control based on a data row. You may want to reset it appropriately when the data row is out of the visible range as the control will be reused by other data rows. Let me change the task again to only resize the TextBox1 for the first data row, and I will use DataRepeater.DrawItem event this time to get the DataRepeaterItem.

Private Sub DataRepeater1_DrawItem(ByVal sender As Object, ByVal e As Microsoft.VisualBasic.PowerPacks.DataRepeaterItemEventArgs) Handles DataRepeater1.DrawItem

Dim txtBox As TextBox = e.DataRepeaterItem.Controls("TextBox1")

If (txtBox IsNot Nothing) Then

If (e.DataRepeaterItem.ItemIndex = 0) Then

' Special treatment for the first data row

txtBox.Multiline = True

txtBox.Height = 50

Else

' Reset to its original state..

' Without this line, the result will be unexpected.

txtBox.Multiline = False

End If

End Sub

Code Sample 5

In code sample 5 above, if I omit the line to reset the txtBox.Multiline = False, you will see unexpected result after scrolling the data repeater up and down for a few times. See an illustration in picture 1 below.

Picture 1

In conclusion, writing event handler for a control in a DataRepeaterItem can be as straightforward as in a plain form like code sample 2. However, when individual control is needed, you need to make sure to get the correct run time control and remember to reset its property after the use.

How to Workaround Sorting Errors when Updating Self-Referencing DataSet Tables with Visual Studio 2008 SP1

Gavin Fu — Sat, 05 Sep 2009 07:14:00 GMT

Hierarchical update is an important feature of typed dataset that refers to the process of saving updated data back to a database while maintaining referential integrity rules. This feature is enhanced in Visual Studio 2008 by introducing a TableAdapterManger component to manage all TableApdaters in a typed dataset. When updating related tables, TableAdapterManager uses foreign-key relationships to determine the correct order to send Insert, Update, and Delete commands from a dataset to the database without violating the foreign-key constraints (referential integrity) in the database.

TableAdpaterManager is automatically generated when you create a typed-dataset in a project with Hierarchical Update enabled (For more information, see How to Enable and Disable Hierarchical Update), and it could greatly reduce the code to save data to multiple related tables. Users just need to call TableAdpaterManager.UpdateAll(DataSet). You could see how easy it is to use this class in “Sample Code Snippet to Update the Database” section of this article. However, when updating self-referencing tables, TableAdpaterManager has some defects in determining the correct order of affected rows, which could cause constraint violation errors when committing the changes to database. We have noticed this problem and are investigating how to resolve it. I’ll explain the idea of the solution and how to work around this issue with Visual Studio 2008 SP1.

What the Problem is

Sample Table

Suppose that you have a self-referencing table named Temp with three columns and a foreign-key relationship.

Table Definition:

Foreign-Key Relation:

Generated Typed-DataSet Code Snippet

Suppose you add a typed-dataset (say, dataset1) to your application, and drag-drop the Temp table from Server Explorer to the dataset designer, Visual Studio will generate code of the typed-dataset for you. Below is the code snippet that is related to this topic.

[C#]

public partial class TableAdapterManager : global::System.ComponentModel.Component {

public virtual int UpdateAll(DataSet1 dataSet) {

. . . . . .

this.UpdateInsertedRows(dataSet, allAddedRows));

. . . . . .

this.UpdateDeletedRows(dataSet, allChangedRows));

. . . . . .

}

private int UpdateInsertedRows(DataSet1 dataSet, global::System.Collections.Generic.List<global::System.Data.DataRow> allAddedRows) {

. . . . . .

this.SortSelfReferenceRows(addedRows, dataSet.Relations["FK_Temp_Temp"], false);

. . . . . .

}

private int UpdateDeletedRows(DataSet1 dataSet, global::System.Collections.Generic.List<global::System.Data.DataRow> allChangedRows) {

. . . . . .

this.SortSelfReferenceRows(addedRows, dataSet.Relations["FK_Temp_Temp"], true);

. . . . . .

}

protected virtual void SortSelfReferenceRows(global::System.Data.DataRow[] rows, global::System.Data.DataRelation relation, bool childFirst) {

global::System.Array.Sort<global::System.Data.DataRow>(rows, new SelfReferenceComparer(relation, childFirst));

}

private class SelfReferenceComparer : object, global::System.Collections.Generic.IComparer<global::System.Data.DataRow> {

private global::System.Data.DataRelation _relation;

private int _childFirst;

. . . . . .

public int Compare(global::System.Data.DataRow row1, global::System.Data.DataRow row2) {

if (object.ReferenceEquals(row1, row2)) {

return 0;

}

if ((row1 == null)) {

return -1;

}

if ((row2 == null)) {

return 1;

}

// Is row1 the child or grandchild of row2

if (this.IsChildAndParent(row1, row2)) {

return this._childFirst;

}

// Is row2 the child or grandchild of row1

if (this.IsChildAndParent(row2, row1)) {

return (-1 * this._childFirst);

}

return 0;

}

[VB]

Partial Public Class TableAdapterManager

Inherits Global.System.ComponentModel.Component

Public Overridable Function UpdateAll(ByVal dataSet As DataSet1) As Integer

. . . . . .

Me.UpdateInsertedRows(dataSet, allAddedRows)

. . . . . .

Me.UpdateDeletedRows(dataSet, allChangedRows)

. . . . . .

End Function

Private Function UpdateInsertedRows(ByVal dataSet As DataSet1, ByVal allAddedRows As Global.System.Collections.Generic.List(Of Global.System.Data.DataRow)) As Integer

. . . . . .

Me.SortSelfReferenceRows(addedRows, dataSet.Relations("FK_Temp_Temp"), False)

. . . . . .

End Function

Private Function UpdateDeletedRows(ByVal dataSet As DataSet1, ByVal allChangedRows As Global.System.Collections.Generic.List(Of Global.System.Data.DataRow)) As Integer

. . . . . .

Me.SortSelfReferenceRows(addedRows, dataSet.Relations("FK_Temp_Temp"), True)

. . . . . .

End Function

Protected Overridable Sub SortSelfReferenceRows(ByVal rows() As Global.System.Data.DataRow, ByVal relation As Global.System.Data.DataRelation, ByVal childFirst As Boolean)

Global.System.Array.Sort(Of Global.System.Data.DataRow)(rows, New SelfReferenceComparer(relation, childFirst))

End Sub

Private Class SelfReferenceComparer

Inherits Object

Implements Global.System.Collections.Generic.IComparer(Of Global.System.Data.DataRow)

Private _relation As Global.System.Data.DataRelation

Private _childFirst As Integer

. . . . . .

Public Function Compare(ByVal row1 As Global.System.Data.DataRow, ByVal row2 As Global.System.Data.DataRow) As Integer

Implements Global.System.Collections.Generic.IComparer(Of Global.System.Data.DataRow).Compare

If Object.ReferenceEquals(row1, row2) Then

Return 0

End If

If (row1 Is Nothing) Then

Return -1

End If

If (row2 Is Nothing) Then

Return 1

End If

'Is row1 the child or grandchild of row2

If Me.IsChildAndParent(row1, row2) Then

Return Me._childFirst

End If

' row2 the child or grandchild of row1

If Me.IsChildAndParent(row2, row1) Then

Return (-1 * Me._childFirst)

End If

Return 0

End Function

End Class

Sample Code Snippet to Update the Database

Then, you could update the table with the help of TableAdapterManager. Below is snippet of sample code to insert some rows to the self-referencing Temp table, and then delete them.

[C#]

DataSet1 ds = new DataSet1();

DataSet1.TempRow row1 = ds.Temp.AddTempRow(1, null, "Row 1");

DataSet1.TempRow row4 = ds.Temp.AddTempRow(4, null, "Row 4");

DataSet1.TempRow row2 = ds.Temp.AddTempRow(2, row1, "Row 2");

DataSet1.TempRow row3 = ds.Temp.AddTempRow(3, row4, "Row 3");

DataSet1TableAdapters.TableAdapterManager manager = new DataSet1TableAdapters.TableAdapterManager();

. . . . . .

manager.UpdateAll(ds); // Insert the rows

row1.Delete();

row2.Delete();

row3.Delete();

row4.Delete();

manager.UpdateAll(ds); // Delete the rows

[VB]

Dim ds As DataSet1 = New DataSet1

Dim row1 As DataSet1.TempRow = ds.Temp.AddTempRow(1, Nothing, "Row 1")

Dim row4 As DataSet1.TempRow = ds.Temp.AddTempRow(4, Nothing, "Row 4")

Dim row2 As DataSet1.TempRow = ds.Temp.AddTempRow(2, row1, "Row 2")

Dim row3 As DataSet1.TempRow = ds.Temp.AddTempRow(3, row4, "Row 3")

Dim manager As DataSet1TableAdapters.TableAdapterManager = New DataSet1TableAdapters.TableAdapterManager

manager.UpdateAll(ds) ' Insert the rows

row1.Delete()

row2.Delete()

row3.Delete()

row4.Delete()

manager.UpdateAll(ds) ' Delete the rows

What is the Problem and Why

From the code at the beginning of the post, we can see that TableAdapterManager uses System.Array.Sort<T>(T, IComparer<T>) to sort all rows before inserting them into or deleting them from database so that no violations to foreign-key constraints occur. The expected sorting result is: parent first for inserted rows, and child first for deleted rows. Take the sample code above for example, before calling SortSelfReferenceRows method, content of the array to insert is <R₁, R₄, R₂, R₃>. After calling the sorting method, R₁should come before R₂, and R₄ should come before R₃. Because R₁ is Parent of R₂, and R₄ is Parent of R₃. Sequence between two rows that do not have Parent-Child (or Grandparent-Grandchild, etc) relationships are undetermined, e.g., R₁ could come either before or after R₄.

For each pair <row1, row2> in the array to sort, SortSelfReferenceRows.Compare() will be called to determine their sequence in the output array. From the implementation of SortSelfReferenceRows.Compare, we could see that any two rows that do not have a Parent-Child (or Grandparent-Grandchild, etc) relationship are treated equal. This is OK if all possible row pairs are compared, e.g. < R₁, R₄>, < R₁, R₂>, < R₁, R₃>, < R₄, R₂>, < R₄, R₃>, < R₂, R₃> are all explicitly compared by passing them to SortSelfReferenceRows.Compare. However, System.Array.Sort is implemented using QuickSort, it does not compare every possible row pair. Instead, equation relationships of rows are treated transitive. For example, if < R₁, R₄>is compared and the result is R₁ == R₄, < R₄, R₂> is compared and the result is R₄ == R₂, then System.Array.Sort will indicate that R₁ == R₂, and does NOT compare < R₁, R₂> at all! Clearly, you could see that R₁ is Parent of R₂, < R₁, R₂> should be explicitly compared and the result should be R₁ < R₂.

The Idea of the Solution

So, how to sort the array so that no foreign-key constraints are violated? The idea is to treat the array as a forest, group all rows that have the same root into a tree, and compare the rows based on their root and their distance to the root. For example, suppose we have an array < R₁, R₂, …, R₁₄>, and the Parent-Child relationships among its elements are shown like picture below.

We still use System.Array.Sort<T>(T, ICompare<T>) to sort the array. That means we do not have direct control over the sorting algorithm, and we do not know what row pairs to be compared or the sequence of these comparisons. However, we do could impact the sorting process by controlling the comparison result of row pairs. That’s why we need to re-write the SelfReferenceComparer.Compare method.

The pseudo code of the new Compare method is (suppose Parent First):

int Compare (DataRow row1, DataRow row2)

DataRow root1 = row1’s root;

int distance1 = row1’s distance to root1

DataRow root2 = row2’s root;

int distance2 = row2’s distance to root2;

if (root1 == root2)

return distance1 – distance2;

else

return root1.RowIndex – root2.RowIndex;

end

How to Work-Around The Problem with Visual Studio 2008 SP1

With Visual Studio 2008 SP1, as a workaround, you could derive from the generated TableAdpaterManager and override its SortSelfReferenceRows method to implement this algorithm by yourself. Of course, you could put your code anywhere of your project, but it’s recommended to put them in the typed-dataset’s source code file. Right-click the typed-dataset (say, DataSet1.xsd), and choose “View Code”, Visual Studio will automatically create the source code file for you (DataSet1.cs in this case). It’s recommended you put your implementation code here.

Your code could be like this:

[C#]

// Derive from the generated TableAdapterManager and use it in your code instead

public class MyTableAdpaterManager : DataSet1TableAdapters.TableAdapterManager {

// Override this virtual method, and pass your own IComparer class

protected override void SortSelfReferenceRows(System.Data.DataRow[] rows, System.Data.DataRelation relation, bool childFirst) {

System.Array.Sort<System.Data.DataRow>(rows, new MySelfReferenceComparer(relation, childFirst));

}

private class MySelfReferenceComparer : object, global::System.Collections.Generic.IComparer<global::System.Data.DataRow> {

private global::System.Data.DataRelation _relation;

private int _childFirst;

internal MySelfReferenceComparer(global::System.Data.DataRelation relation, bool childFirst) {

this._relation = relation;

if (childFirst) {

this._childFirst = -1;

}

else {

this._childFirst = 1;

}

// Get the root of a row, and calculate its distance to the root

private global::System.Data.DataRow GetRoot(global::System.Data.DataRow row, out int distance) {

global::System.Diagnostics.Debug.Assert((row != null));

global::System.Data.DataRow root = row;

distance = 0;

// Save all traversed rows to avoid infinite loop

global::System.Collections.Generic.IDictionary<global::System.Data.DataRow, global::System.Data.DataRow> traversedRows = new global::System.Collections.Generic.Dictionary<global::System.Data.DataRow, global::System.Data.DataRow>();

traversedRows[row] = row;

global::System.Data.DataRow parent = row.GetParentRow(this._relation, global::System.Data.DataRowVersion.Default);

while ((parent != null) && !traversedRows.ContainsKey(parent)) {

distance++;

root = parent;

traversedRows[parent] = parent;

parent = parent.GetParentRow(this._relation, global::System.Data.DataRowVersion.Default);

}

// This is mainly for Deleted rows

if (distance == 0) {

traversedRows.Clear();

traversedRows[row] = row;

parent = row.GetParentRow(this._relation, global::System.Data.DataRowVersion.Original);

while ((parent != null) && !traversedRows.ContainsKey(parent)) {

distance++;

root = parent;

traversedRows[parent] = parent;

parent = parent.GetParentRow(this._relation, global::System.Data.DataRowVersion.Original);

}

return root;

}

public int Compare(global::System.Data.DataRow row1, global::System.Data.DataRow row2) {

if (object.ReferenceEquals(row1, row2)) {

return 0;

}

if ((row1 == null)) {

return -1;

}

if ((row2 == null)) {

return 1;

}

// Get root of row1 and calculate its distance to the root

int distance1 = 0;

global::System.Data.DataRow root1 = this.GetRoot(row1, out distance1);

// Get root of row2 and calculate its distance to the root

int distance2 = 0;

global::System.Data.DataRow root2 = this.GetRoot(row2, out distance2);

if (object.ReferenceEquals(root1, root2)) {

return this._childFirst * distance1.CompareTo(distance2);

}

else {

// Compare root1 and root2 with their row index to ensure the correct sort order

global::System.Diagnostics.Debug.Assert((root1.Table != null) && (root2.Table != null));

if (root1.Table.Rows.IndexOf(root1) < root2.Table.Rows.IndexOf(root2)) {

return -1;

}

else {

return 1;

}

[VB]

' Derive from the generated TableAdapterManager and use it in your code instead

Public Class MyTableAdapterManager

Inherits DataSet1TableAdapters.TableAdapterManager

' Override this virtual method, and pass your own IComparer class

Protected Overrides Sub SortSelfReferenceRows(ByVal rows() As System.Data.DataRow, ByVal relation As System.Data.DataRelation, ByVal childFirst As Boolean)

Global.System.Array.Sort(Of Global.System.Data.DataRow)(rows, New MySelfReferenceComparer(relation, childFirst))

End Sub

Private Class MySelfReferenceComparer

Inherits Object

Implements Global.System.Collections.Generic.IComparer(Of Global.System.Data.DataRow)

Private _relation As Global.System.Data.DataRelation

Private _childFirst As Integer

Friend Sub New(ByVal relation As Global.System.Data.DataRelation, ByVal childFirst As Boolean)

Me._relation = relation

If childFirst Then

Me._childFirst = -1

Else

Me._childFirst = 1

End If

End Sub

' Get root of a row, and calculate its distance to the root

Private Function GetRoot(ByVal row As Global.System.Data.DataRow, ByRef distance As Integer) As Global.System.Data.DataRow

Global.System.Diagnostics.Debug.Assert((Not (row) Is Nothing))

Dim root As Global.System.Data.DataRow = row

distance = 0

' Save all traversed rows to avoid infinite loop

Dim traversedRows As Global.System.Collections.Generic.IDictionary(Of Global.System.Data.DataRow, Global.System.Data.DataRow) = New Global.System.Collections.Generic.Dictionary(Of Global.System.Data.DataRow, Global.System.Data.DataRow)()

traversedRows(row) = row

Dim parent As Global.System.Data.DataRow = row.GetParentRow(Me._relation, Global.System.Data.DataRowVersion.[Default])

Do While ((Not (parent Is Nothing)) _

AndAlso (traversedRows.ContainsKey(parent) = False))

distance = distance + 1

root = parent

traversedRows(parent) = parent

parent = parent.GetParentRow(Me._relation, Global.System.Data.DataRowVersion.Default)

Loop

' This is mainly for Deleted rows

If (distance = 0) Then

parent = row.GetParentRow(Me._relation, Global.System.Data.DataRowVersion.Original)

Do While ((Not (parent Is Nothing)) _

AndAlso (traversedRows.ContainsKey(parent) = False))

distance = distance + 1

root = parent

traversedRows(parent) = parent

parent = parent.GetParentRow(Me._relation, Global.System.Data.DataRowVersion.Original)

Loop

End If

Return root

End Function

Public Function Compare(ByVal row1 As Global.System.Data.DataRow, ByVal row2 As Global.System.Data.DataRow) As Integer Implements Global.System.Collections.Generic.IComparer(Of Global.System.Data.DataRow).Compare

If Object.ReferenceEquals(row1, row2) Then

Return 0

End If

If (row1 Is Nothing) Then

Return -1

End If

If (row2 Is Nothing) Then

Return 1

End If

'Get root of row1 and calculate its distance to root

Dim distance1 As Integer = 0

Dim root1 As Global.System.Data.DataRow = Me.GetRoot(row1, distance1)

'Get root of row2 and calculate its distance to root

Dim distance2 As Integer = 0

Dim root2 As Global.System.Data.DataRow = Me.GetRoot(row2, distance2)

If Object.ReferenceEquals(root1, root2) Then

Return Me._childFirst * distance1.CompareTo(distance2)

Else

' Compare root1 and root2 with their row index to ensure the correct sort order

Global.System.Diagnostics.Debug.Assert((Not root1.Table Is Nothing) AndAlso (Not root2.Table Is Nothing))

If (root1.Table.Rows.IndexOf(root1) < root2.Table.Rows.IndexOf(root2)) Then

Return -1

Else

Return 1

End If

End Function

End Class

For the complete sample code, you could download it at Code Gallery. Cheers!

How to Change Appearance of all DataRepeater Items at Run Time

Gavin Fu — Thu, 27 Aug 2009 09:19:25 GMT

DataRepeater control is one of the most important controls in Visual Basic PowerPacks. John Chen has recently posted a great blog about this control’s background and usage. As a complement, I want to talk about how to customize DataRepeater item appearance here.

Generally speaking, you could change appearance of DataRepeater items in approaches below:

1. To set appearance of all items

a. At design time

Select DataRepeater’s ItemTemplate, and set its appearance-related properties in Property Window, like the snapshot below shows. These properties will be copied and applied to all items at run time.

b. At run time

At run time, you could reset properties of DataRepeater’s ItemTemplate. New properties will overwrite corresponding properties you set at design time, and apply to all items, no matter whether the item has been scrolled into view or not.

2. To set appearance of an individual item

a. At design time

Not surprisingly, there is no way to do this. Because all items are dynamically created from ItemTemplate at run time, they do not exist at design time at all.

b. At run time

You could handle DrawItem event to change appearance of an individual item when it is scrolled into view.

In this article, I want to talk about how to set appearance of all items at run time, because users tend to forget to put their ItemTemplate-modifying code block between BeginResetItemTemplate and EndResetItemTemplate methods, which causes the appearance of DataRepeater items unpredictable.

What the code should be like

Suppose you have a DataRepeater control named dataRepeater1, and you want to modify its ItemTemplate properties at run time, then the code should be like:

[VB]

Me.DataRepeater1.BeginResetItemTemplate()

' Code to change appearance properties of ItemTemplate and its child controls

Me.DataRepeater1.ItemTemplate.BackColor = Color.Blue

Me.DataRepeater1.ItemTemplate.Controls("textBox1").Visible = False

......

Me.DataRepeater1.EndResetItemTemplate()

[C#]

this.dataRepeater1.BeginResetItemTemplate();

// Code to change appearance properties of ItemTemplate and its child controls

this.dataRepeater1.ItemTemplate.BackColor = Color.Blue;

this.dataRepeater1.ItemTemplate.Controls["textBox"].Visible = false;

......

this.dataRepeater1.EndResetItemTemplate();

Why need to call BeginResetItemTemplate and EndResetItemTemplate method

About the reason, I want to talk a little about the underlying implementation of DataRepeater. The implementation I’m going to talk about is current design of DataRepeater (also simplified to make it more understandable), and is possible to change in the future.

For performance reasons, DataRepeater does NOT create one DataRepeaterItem UI object for each data item. Instead, it just creates a few DataRepeaterItem instances (by cloning ItemTemplate), re-uses them, and creates some new ones on demand. These instances are stored in two Queues, let’s call them DisplayItemsQueue and SpareItemsQueue. DisplayItemsQueue holds real DataRepeaterItem objects for all visible data items, i.e. items that are located within visible area of DataRepeater control. When a new data item is scrolled into view, DataRepeater tries to retrieve a DataRepeaterItem object from SpareItemsQueue, binds it to the data item, raises DrawItem event for it so that user has a chance to customize its appearance, puts it to DisplayItemQueue and displays it; when a data item is scrolled out of view, its DataRepeateritem object is revoked, and is put into SpareItemsQueue for future re-use. When DataRepeater tries to retrieve a DataRepeateritem object from SpareItemsQueue and if this Queue is empty, a new DataRepeateritem object will be created from ItemTemplate and directly returned.

So, what happens when you change ItemTemplate’s properties? Take the VB code for example.

1 Without calling BeginResetItemTemplate and EndResetItemTemplate:

// Before updating ItemTemplate properties, DataRepeater has already created some DataRepeaterItem objects for visible items. These DataRepeaterItem objects’ properties will NOT be affected by code below.

Me.DataRepeater1.ItemTemplate.BackColor = Color.Blue

Me.DataRepeater1.ItemTemplate.Controls("textBox1").Visible = False

;

......

// The updated properties only apply to new DataRepeaterItem objects that are created on demand later.

2 When calling BeginResetItemTemplate and EndResetItemTemplate:

// When calling BeginResetItemTemplate, all already-created DataRepeaterItem objects are removed from the Queue and discarded.

Me.DataRepeater1.BeginResetItemTemplate()

Me.DataRepeater1.ItemTemplate.BackColor = Color.Blue

Me.DataRepeater1.ItemTemplate.Controls("textBox1").Visible = False

......

Me.DataRepeater1.EndResetItemTemplate()

// After calling EndResetItemTemplate(), all DataRepeaterItem objects are re-created from the updated ItemTemplate and the updated changes will be applied.

DataRepeater Control for Windows Forms

John Chen — Wed, 12 Aug 2009 23:44:00 GMT

The DataRepeater control is available in the Visual Basic Power Packs.

As Yun Feng introduced in his post, the Visual Basic Power Packs is included in Visual Studio 2008 Service Pack 1 and will also be shipped in Visual Studio 2010.

The DataRepeater control is my favorite component in the Visual Basic Power Packs, which I proudly participated in from start to finish. Recently I monitored the Visual Basic Power Packs forum and I found that customers are saying nice things about the DataRepeater control as well. A lot of good questions have been asked in the forum. For example, how to print all the data in the DataRepeater, how to display unbound data, how to host a data bound ComboBox in the DataRepeater, etc… I feel motivated to write some posts to answer these non-obvious questions.

In this post, I will first present the unique features of the DataRepeater control from my perspective. Then I will show a simple walk through for using a DataRepeater control in a data binding application. At the end, I will list the resources available for reference.

First of all, I would like to point out that the DataRepeater control is a true .Net Windows Forms control. It can be used not only by Visual Basic but also for any other .Net language (e.g. C#). You may be curious why it is under the Visual Basic Power Packs “brand”. The project was initially designed to help VB6 customers migrating to the .Net world with familiar experience and environment. We started the project with the Visual Basic customers in mind as there was already a Data Repeater Control in Visual Basic 6 and unfortunately there was no corresponding control in Visual Studio.Net 2002 to 2008. After we created the control we realized that it would be good for all .NET customers and we decided to make it available to all of Visual Studio.

To differentiate the DataRepeater controls in VB6 and the one now in Visual Studio 2008 SP1, in this article I would call them VB6 DataRepeater and PowerPacks DataRepeater (or simply DataRepeater). The PowerPacks DataRepeater inherits the basic concept of the VB6 DataRepeater control to display repeated data in a scrollable container. Even more, the PowerPacks DataRepeater has significant improvements over the VB6 DataRepeater. The PowerPacks DataRepeater is modern (as I said, it is a .Net control can be used by all languages), more powerful, has more functions, and yet easier to use taking all the advantages of the .Net and Visual Studio Data Access tools and technologies.

For example, in VB6, you need to create an intermediate user control to host the VB6 DataRepeater and set up the data binding there, build it and then include the user control in the host form. With PowerPacks DataRepeater, the intermediate user control is no longer needed! You can now drag and drop the DataRepeater control onto the hosting form directly, and then drag and drop controls on its item template section. You will enjoy a truly WYSIWYG design experience.

Although both DataRepeater controls can host free style controls in the item template section, the PowerPacks DataRepeater allows you to have even more controls on the layout and the appearance of the repeating items. You can use the DrawItem event to customize the color or other appearances as you wish. The LayoutStyle property lets you specify orientation (vertical or horizontal) of the displayed items. The orientation feature is really attractive and I have seen some customers choose the DataRepeater over the DataGridView simply because the DataRepeter can show data in horizontal orientation.

Talking about the DataGridView, the PowerPacks DataRepeater control can be seen as an alternative control to the DataGridView. The PowerPacks DataRepeater follows the design of the DataGridView and you can find many properties (e.g. the Virtual Mode property) in DataRepeater control in parity with the DataGridView. This description from MSDN document best describes the role of the PowerPacks DataRepeater -- “It can be used as an alternative to the DataGridView control when you need more control over the layout of the data.”

The PowerPacks DataRepeater control applies a virtualization technique to display the data in a fashion that scrolling and navigation is fast while rich UI and visual effects are still retained. For example, all displayed controls on the display surface are real controls and you can interact with them without delay. Scrolling is smoothly simulated while VB6 DataRepeater does not have a scroll effect.

You can further improve performance by turning on the Virtual Mode when you want to display large quantities of tabular data in a PowerPacks DataRepeater control. The Virtual Mode allows you explicitly manage the control’s interaction with its data source. Therefore you can load the data rows only when necessary to reduce the initial loading time. You can also reduce the memory consumption by only loading part of the rows into memory at any given time. Notice that if you already have all data rows loaded into memory like a DataSet filled by the TableAdapter.Fill method, you will not have the performance gain with Virtual Mode.

To demonstrate the ease of use of the PowerPacks DataRepeater control, let me give you a walkthrough for building an application with the DataRepeater control.

First I would create a C# Windows Forms Application in Visual Studio 2008 SP1 or 2010 (yes, I purposely choose a C# project here to show that it is not only for VB, the steps in this demo have no difference between C# and VB).

And then I want to create a DataSet data source with the DataSource Configuration Wizard or DataSet Designer. I will assume you are familiar with this part and a DataSet with Employees table connecting to the sample Northwind database is ready to use. You will see that the Data Sources Window on the left hand side is populated with the Employees Datatable (see Picture 1 bellow).

Picture 1 – DataSet designer and Data Sources window.

Now, let’s open the Form and show the Toolbox. You can find the Power Packs tab (see picture 2, marker 1, shortened as Pic.2-1), expand it and you will find the DataRepeater toolbox item (Pic.2-2). Drag and drop the DataRepeater toolbox item to the form (Pic. 2-3), you will see two sections in the location of the DataRepeater1 control on the form. The outer section (Pic.2-4) is the total display area of the control and the inner section (Pic.2-5, a.k.s. the Item Template section) holds the repeating items. It also defines the size of the repeating items and the location of the first item. You can fine tune the look and feel of the outer and inner section of the DataRepeater control as you wish.

Picture 2. Drag and Drop DataRepeater to the Form

I select my DataRepeater by clicking on the outer section of the DataRepeater, the Property Brower should show as in Pic. 3-1. And I set the anchor as top-left-right (Pic.3-2) and the LayoutStyle as Horizontal (Pic. 3-3).

Picture 3. DataRepeater layout

Now, let’s fill the DataRepeater item template section with some data bound controls. I show the Data Sources Window (Pic. 4-1), change the employees table’s view to detail (Pic. 4-2), change the First and Last Name to label (Pic. 4-3), leave the Title as default TextBox (Pic. 4-4), and change the Photo to a PictureBox (Pic. 4-5). I then drag and drop these items to the DataRepeater item template section as indicated in the picture and remove the unnecessary extra labels. Note that it will also cause the auto creation of the navigator bar (Pic. 4-6), Dataset, BindingSource, TableAdapter, etc.(Pic. 4-7). The experience is exactly the same as when you drag and drop detail view items from the Data Sources window to a form or any container control. The difference is now the data bound items in the Item Template section will now be repeated at run time.

Picture 4. Drag and drop detail view items from Data Sources window to the item template section

Now I am happy with the setup and eager to see what is out there, I hit F5 to test my app, and I got this result, that is all I need. You can scroll the data by clicking on the scroll bar or the forward and backward button on the navigation bar. You can select an item, and modify the value on any editable control on the item like Title text box (Pic. 5-1). You can add new item (Pic. 5-2), delete an item (Pic. 5-3). And you can save all the changes (Add/Delete/Update) with the save button (Pic. 5-4).

Picture 5. Run time result

To summarize, creating a data binding application can be simply done with these 3 steps: 1) Create the data source; 2) Drag and drop a DataRepeater control to the form and adjust its look and feel; 3) Drag and drop detail view items from Data Sources Window to the item template section of the DataRepeater control.

Lastly, let me wrap up with some more information:

The sample projects (VB and C# 2008 SP1 version) in this post can be found in MSDN Code Gallery Power Packs Samples
For a detail instruction of a similar walk through, see MSDN article: How to: Display Bound Data in a DataRepeater Control (Visual Studio)
For a related video demonstration, see How Do I: Use the DataRepeater Control? presented by Beth Massi.
For MSDN DataRepeater introduction article: See Introduction to the DataRepeater Control (Visual Studio)
For DataRepeater class reference: See DataRepeater Class
For questions and feedback: See Visual Basic Power Packs forum
For VB6 reference, see Data Repeater Control in Visual Basic 6
For accessing data technologies in Visual Studio: See VS2010 Beta1 version or VS2008 version

As mentioned above, my colleagues and I will post more articles to answer some advanced or non-obvious How-Tos in the near future. Stay tuned!

----------------------------------------------------------------------------

Follow-up blogs:

8/27/09 Gavin Fu: How to Change Appearance of all DataRepeater Items at Run Time
9/8/09 John Chen Writing Event Handler for controls in a DataRepeaterItem

Customize format of DateTime string in WPF and WinForm data binding

Yang Cao — Tue, 07 Jul 2009 06:17:56 GMT

Drag-and-drop data binding helps you build business applications very easily, however sometimes you still need to customize the layout or format after data binding is set. For example, I built a simple application to display all the Customers, and for each Customer, the related Orders are loaded into a DataGrid control:

Of course the data in Birthday field is fake :) and of course I don’t want to show the time part 12:00:00 AM in the text. To customize the string format, first let’s go to the XAML file and locate the TextBlock which binds to Birthday:

<TextBlock Grid.Column="1" Grid.Row="3" Height="21" HorizontalAlignment="Left" Margin="3" Name="birthdayTextBlock" Text="{Binding Path=Birthday}" VerticalAlignment="Center" Width="120" />

You could write a converter to convert the string. Another simpler way is to insert a StringFormat property to the Text Binding and set it to only display the Date 1/1/2222:

Text="{Binding Path=Birthday, StringFormat=d}"

Similarly, if you set StringFormat to the “Order Date” and “Preferred Delivery Time” column:

…
<TextBlock Text="{Binding Path=OrderDate, StringFormat={}{0:dddd MMMM dd}}" />
…
<TextBlock Text="{Binding Path=DeliveryDate, StringFormat=t}" />
…

StringFormat={}{0:dddd MMMM dd} it will display the DateTime in your specified format; StringFormat=t will only display short time. Now the form looks like this:

Now you might ask, how about WinForms? It is just as easy.
On the left is the WinForm Designer surface. Set focus on the DateTimePicker control and find Format property in Properties window. Change the Format to Short so that Birthday TextBlock will only display the Date:

To set OrderDate column and PreferredDeliveryDate column to display in the format as in the WPF example above, click on the DataGridView control and click on the little smarttag button to open DataGridView Tasks:

Select Edit Columns to invoke Edit Columns dialog, and in Bound Column Properties, select DefaultCellStyle to launch CellStyle Builder:

There are some other customizations in this dialog, now let’s just focus on the Format. You could input Format like “dddd MM dd”, or launch Format String Dialog to set the string format. After setting format for both OrderDate column and PreferredDeliveryTime column, the final windows form is:

Well, isn’t it simple to change string format in data binding for both WPF and WinForm? To learn more about formatting (not only formatting DateTime string), please see: http://msdn.microsoft.com/en-us/library/fbxft59x.aspx

Cheers!