At work I’m building a simple tool to populate a FogBugz wiki page with build information. One of the things this tool needs to do is pull the XHTML contents of a wiki page, parse it (as XML), and take action on the resulting document tree. Initially I expected this to be stupid-easy, as XHTML is just XML, right?

Au contrare!

Problem 1: XHTML is NOT just XML

The first problem is XHTML documents likely contain entity references like   and whatnot. These entity references aren’t XML entities, they’re XHTML entities, so you must load the XHTML DTD in order to resolve them. Trouble is, this means there must be a proper XHTML DOCTYPE directive in your XHTML (which there isn’t in my case since I’m using fragments).

Once a valid DOCTYPE directive is added to the XHTML, now .NET will download the full DTD from W3 just to parse a little XHTML fragment. Not acceptable.

I just read Scott Guthrie’s announcement that, starting with Visual Studio 2008, the full, commented source code to the major assemblies in the .NET framework will be available for debugging and analysis, both as a source tarball and on-demand via the public symbol server.

Earlier I lamented my fate as a GUI developer with DevExpress GUI widgets. After a few hours of repeated head/wall interfacing, I found the problem, and it’s so maddening I must now vent.

Most of my business objects are displayed in the GUI using WinForms and DevExpress data binding. If I have a list of objects to display in a grid or list or, in this case, a calendar, I use lists derived from System.ComponentModel.BindingList<T>, which implements all the plumbing, like IBindingList, plus general-purpose typed container stuff.

Using one of these lists as the DataSource for WinForms or DevExpress controls Just Works. However, as mentioned before, the scheduler control doesn’t switch to the UI thread when handling ListChanged events, so when I load my list in a background thread it crashes the app.

Lately I’ve been stuck doing GUI development at work. If you’re not a systems programmer, it’s probably hard for you to understand how degrading UI work is for me, but it’s roughly equivalent to a lawyer cleaning toilets, or a doctor doing TPS reports.

To make this process suck minimally, my company licensed the Developer Express DXperience toolkit. The toolkit includes WinForms, ASP.NET, and ActiveX components, but we’re only using WinForms.

In my tenure at BearingPoint I’d used a heavily customized earlier version of DevExpress’s XtraGrid control, but they’ve come along way since then, and I’m using more controls now.

I’ve recently run into a situation in which I need to use .NET file I/O APIs like File.Exists and File.OpenRead using a filename of the form:

\\?\Volume{guid}\foo.txt

Where guid is a GUID in the standard registry format. Assuming the path refers to a currently available volume (as reported by, for example, mountvol), this is a fully valid path.

There’s something badly broken about Windows Presentation Foundation focus. I’ve read that WPF implements its own concept of focus, and at the high level a WPF element tree is just a single HWND, and the WPF elements are rendered therein.

Here’s an experiment for you to try on your own: Create a simple XAML Window. Populate it with user controls. Now, try to get the first user control in the window to receive focus (keyboard and logical) when you’re window starts up. The FocusSample does it with a Button, which seems to work OK, but with a UserControl you’re out of luck. Even after setting Focusable to true, it doesn’t work. Yet, you can Tab through the focusable controls without problem.

I’ve spent most of the day playing around with the .NET Framework 3.0 RC1 bits. I’m primarily interested in the Windows Presentation Foundation (WPF) stuff, which deals with UI construction for both desktop and web apps under Vista/IE7 and beyond (though it works on XP and 2k3 Server too).

(As an aside, the new Windows x Foundation marketing idiom is among the more stupid in recent memory. That they’re bundled together into the .NET Framework 3.0, which has no obvious textual resemblance to the Windows somethingotherother Foundation template makes it all the more awkward. I liked WinFX better.)

The RC1 of the .NET Framework 3.0 recently became available for download, along with the RC1 version of the Platform SDK—erm, I mean—Windows SDK for Vista. Apart from the usual incessant Microsoft rebranding, there are in fact some major technical differences since 2.0 as well, hence my interest.

However, I cannot get the lightweight, downloads-what-it-needs-on-the-fly version of the installer to work. It fails consistently, early in the setup process. The dd_dotnetfx3error.txt file in Local Settings\Temp has this to say:

I’m working on an entry for TopCoder’s third Intel MultiThreading challenge. Unlike all the winners of past contests, I’m using C#, despite the considerable performance disadvantage it suffers relative to C++, particularly on the Cygwin-based C# compiler used by TopCoder.

Nonetheless, the objective isn’t the win the paltry prize money; I’d like to see how close to the winning solution a C# implementation can get, and at the same time keep me on my intellectual toes while I languish here in Iraq.

At any rate, apart from correctness, the challenge is to solve a computationally-intensive string processing problem in as little time as possible. To start with, I coded a naive implementation and submitted it for a correctness test, but it failed the more complex tests because the code failed to complete in the 60 seconds alloted time.

Today one of my Iraqi devs, E, was trying to display some search results from a MySQL database in an ASP.NET GridView control. He simply set the DataSource property to the DataReader attached to the results, and called DataBind() on the grid control.

All was well, except the dates; they displayed in the short date/time format, even though the times are not used in this application (and thus were all 12AM). I showed him the beauty of the DataFormatString on the BoundField which displayed the date, but to my surprise, setting it to {0:d} didn’t change the output at all.

I scratched my head for a while, then came across MSDN Labs Bug ID FDBK35199, which describes the logic behind this intentional behavior. The reasoning? To prevent script injection attacks, the DataFormatString property is applied AFTER the value is HTML encoded, so it’s no longer a DateTime by the time it is formatted.