The amount of help you can find on the web about binding a datasource to a datagrid is astounding. Once you bound your datagrid and populated it, the user of course wants to see it.

They may optionally want to update, delete or insert data into your nicely bound datagridview.

All of the above is well documented on the web and easy to pull off. So now what?

Let's suppose you want to "Do" something with the data, say.... save it back to a source?

Well if you were using an unbound datasource and populated it on the fly, AND thought you could persist some data in hidden columns, you are sadly mistaken.

The data in hidden columns is never bound on the databind(). That’s right, a predefined column with the datafield attribute set and the visible attribute set false will not bind to the datasource datafield.

The trick is to define all columns of data you wish to persist to visible columns and then after you call the databind(), hide the columns you don't want to show the user. The data will now persist.

CAUTION! If you rebind (update the datagrid datasource) after you've hidden the columns, the data will be lost again. You must first make the columns visible again, then rebind the datagrid and then you may hide the columns once more.

Speeding up Vista with ReadyBoost USB RAM drive

I personally am not running any Vista PCs or notebooks (don't have the hardware base). But if anyone is experiencing the Vista hardware drain, Alec Saunders has blogged a bit on his experience with ReadyBoost included with Microsoft Windows Vista.

I'd love to know if anyone else has had positive results with it.

Speeing up Windows Vista http://saunderslog.com/2007/04/02/speeding-up-windows-vista/

InfoPath goes to XML Schemaville

OK, in XML schemaville, when you define an element (<xsd:element></xsd:element>) you define the the type of element it is and what type of children it will contain (text or other xml elements) if you want it to do both (contain text nodes and element nodes) you have to explicitly define it like that typically you define element nodes that contain child element nodes to not contain text nodes as well.

In InfoPath, elements that contain other child elements are called "groups". The IP schema tool does support defining mixed content nodes. So, since your target node is a "group" it is not allowed to contain text. You must either change it to an element (remove group & re-add element by same name) or do not write to it (add a child element to it to write to) .

Generate Xpath Statement

Ever want to work out what the Xpath statement would be for a current node of an XML document? Well here you go. This little tid bit will quickly work its way back up the parent-grandparent tree, up to the root node of the document. And when it's done, you'll be returned the Xpath statement.

Code: (generated for InfoPath C# managed code)

private string GenerateMatchPath(IXMLDOMNode sourceNode, string xPath)
{
IXMLDOMNode parentNode = sourceNode.parentNode;
while (parentNode != null && parentNode.nodeName != "#document")
{
xPath = parentNode.nodeName + "/" + xPath;
parentNode = parentNode.parentNode; } return "/" + xPath;
}//GenerateMatchPath

Now, why would this be useful?

Suppose you would like to compare the data of a pair of XML documents (docA and docB).

If you used an Xpath query (xmlDoc.selectNodes("//descendant-or-self::node()")) to generate a nodelist of all elements in docA, you could:

• loop through each node from docA
• get its value
• generate the xpath
• use the xpath to get the value from docB
• compare values
• take appropriate action (update docA? update docC?)

[Snippet to follow...]

Clearing Windows network passwords.

I have recently found problems with my Visual Source Safe 2005 (VSS) solution bindings breaking in Visual Studio .NET 2005 (VS2005). On two occassions in the last week I have encountered "Invalid Handle" errors when trying to check-in my solutions.

The invalid handle error is due to the VSS bindings. The solution has been to restablish the bindings, however, this was hampered by the root problem ;) Somehow a bad password was saved, and the connection to the VSS server could not be established. So, the corrupt credentials must be removed.

To do this, I found James Geurts' Blog on 'Clear saved windows networking passwords' where he supplies the following:

Start>Run>rundll32.exe keymgr.dll, KRShowKeyMgr

The same dialog can be opened via:

Start>Control Panel>User Accounts>Advanced Tab>Manage Passwords

I prefer the latter option as it is easier to remember and find again ;)

(James Geurts' Blog http://biasecurities.com/blogs/jim/archive/2005/12/20/3876.aspx)

Missing nodes from a webservice.

InfoPath is very particular about the type of document it processes - this due to its very stringent implementation of XSD Schemas. InfoPath will complain immediately if it encounters nodes that do not fit the schema design (nodes not defined in schema, nodes out of position, multiple nodes where not defined as repeating)

If a node is missing from the instance document and the schema dictates the optional presence of this node, InfoPath will accept the document as valid. However, if there are any controls being bound to the missing field, InfoPath will disable the field in the UI, as nothing can be written to a missing node.

This became painfully apparent in our early iterations of our InfoPath form. We noticed several fields being locked out in the form only to discover the fields were missing from the XML documents returned by our Webservice. We tracked this down to the Enterprise Library's Database Datatable to XML conversion.

Any null values in a recordset are not converted to empty fields in the resulting XML, but rather they are just omitted. Our solution was to use the schema to build ourselves an empty instance document and populate it with the data from the recordset. This way we are guaranteed to get all required nodes returned from a webservice

Since a schema document is simply another XML document, parse the XSD document and programmatically build the instance document starting from the root node element definition.. TBC

Extracting form files

1. Choose Extract Form Files from the File menu.
2. Select a location to save your extracted form files to, and then click OK.
3. Close InfoPath to release the lock it places on your form files.
4. Using a text editor, open your view .xsl file.

Friday, October 13, 2006

Breaking In A New Horse

One of the growing pains I encountered after migrating to Visual Studio 2005, was an issue I had trying to debug my InfoPath 2003 project. I would get an error message;
"In order to debug this project, add an executable project to this solution which references the library project. Set the executable project as the startup project."

While VS 2003 would launch the InfoPath form and Debug it with a fancy-free click of the 'Debu' button, VS 2005 requires you to have the solution selected before it will attempt to launch the form.

However that brought me to an issue I was not previously having. Without having changed any code, the form failed to load in preview or debug mode. Now I am getting the “The format of the file .dll is invalid” error. You would see this error on our dev-test VPCs that did not have the .NET 2.0 framework installed prior to launching the new form.

How is it possible that the DEV workstation compiling the formcode.cs in Visual Studio 2005 .NET 2.0 did not have .Net 2.0 installed?!?

After a quick reinstall of the framework and a restart, the form is debugging and previewing again.

So in recap; select the solution item in the Solution Explorer of Visual Studio 2005 BEFORE attempting to debug (F5).

Ciao for Niao