Another thing I discovered...

Defining a relation/contraint between two tables in the DataSet designer does not always create the DataRelation in the resulting DataSet object.

I use strongly-typed datasets. I like the intellisense and it IsXXXNull methods. And I bind them to data grids. Everything is good.

When acting on a datagrid in ItemCreated or ItemCommand, it is common to access the underlying data. This is acheived via e.Item.DataItem. When a grid is bound to a DataSet or DataTable, this property returns a DataRowView. My lovely, strongly-typed object is gone. :(

I needed to build a page that displayed hierarchical data. So, instead of binding my grid to a DataTable, I was binding to a GetChildRows method, which is a DataRow(). My strongly-typed DataRow is back!!!

To get the strongly-type datarow without a relation, bind to dataSet.dataTable.Rows.

Mr. Vasters is the author of the dasBlog blogging engine that powers this site. If you use dasBlog, provide your feedback here.

New page from Microsoft: SharePoint Portal Server Technical Library

A while ago, I upgraded my dasBlog installation to version 1.6.  I finally got around to looking at the new features, and found the drawArchiveMonths macro. This is now included, on the left below the categories.

Interestingly, it was one year ago when I vanished from the blogosphere (I don't like that word!). I'm determined to prevent that from happening again!

I need to bind a dropdown list control to some data from an XML document. Initially, I tried to specify the DataSource as a node list and the DataText & DataValue properties to “@attribute_name”. No luck.

Thanks to the internet, I found the ASP.NET DropDownList XML Binder Class from the XML for ASP.Net site. This class is written to read an XML file from the specified path and create the ListItems that are added to the control.  It's not databinding in the same sense as ASP.Net, but it works!

The class uses an XMLTextReader. Since I already have a document, I can use the XMLNodeReader and I'm done. 

I was in the middle of answering a question on the message board at SharePointU and I thought it would make a good blog entry.

The WSS framework provides a mechanism (called tokens) to uniquely identify the HTML DOM elements of each part. When writing client-side script in a web part, you can use the token _WPQ_ to refer to the current web part. The poster in the forums is using the token to reference the WebPartCaption element:

            var wpc = WebPartCaption_WPQ_;

However, this is not working because the _WPQ_ token has been changed by WSS. Looking at the page source in IE will show WPQ1, WPQ2, etc. To get the script to work, we need to use the ReplaceTokens method of the WebPart object.

ReplaceTokens takes a string as input and returns the same string with all of the WebPart tokens converted in to their appropriate values. A list of the available tokens is included in the SDK page on ReplaceTokens().

I also posted a sample.

If you're not bringing new ideas to the table, You're signing your own pink slip.

Tom Yager, InfoWorld, 04.19.04

We are live with our WSS site. The cut-over actually happened Thursday of last week. On Friday, the network team worked on the latest patches, so having multiple machines was very nice.

On the to-do list now is migrating legacy content into the WSS lists. The ultimate goal is to have our content in the search results, but keep our existing user interface. I've written a console program to syncronize a list (and other list activities like viewing the schema and contents). I'll try to post the concepts later this week.