Serializing nullable XML attributes...

Well, again this may be obvious to a lot of people, but I thought it was worth a post here.

The other day I was working on a project where some data needed to be serialized into XML using the XmlSerializer.
Some of the classes that needed to be serialized had some GUID's for identifiers, which intuitively becomes a XML attribute in my world, as with all identifiers.
However, some of the identifiers could in some cases be null, which normally wouldn't be possible in .NET 1.1 (you could of course use Guid.Empty but it's not very neat), but in 2.0 there is the Nullable class, which in this situation came quite in handy.

Now, take a look at the following:

private Guid? sysId;
private Guid? traceId;


[XmlAttribute()]
public Guid? SysId
{
   get{ return this.sysId; }
   set{ this.sysId = value; }
}


[XmlAttribute()]
public Guid? TraceId
{
   get{ return this.traceId; }
   set{ this.traceId = value; }
}

Trying to serialize the code above will throw one of those completely useless XML serialization exceptions, which you can use hours trying to debug.
But the question is why?
Well, the reason is quite simple. Serializing a nullable valuetype into XML results in the following:

<FooBar xsi:nil="true" />

The above does not exactly adhere to a wellformed XML attribute, and the result would look something like this:

<XmlElement attribute1="foo" FooBar xsi:nil="true" />

So there it is.
The way the .NET Framework serializes it's nullable types does not work well with XML attributes, so either you have to live with it and let the property be an XML element, or you have to make up your own serialization mechanisms taking care of the nullable types in a custom way.

The height of the tabs...

Well, someone might call me too much of a pixel-perfectionist, but sometimes those small differences just annoys the heck out of me.

I was comparing two dialogboxes, when I suddenly noticed that the height of the tabs was different.
I looked into it and compared margins, paddings and, well, you name it, but they were completely identical in sizes - they just rendered differently.
I then noticed that one of the tab-controls had an imagelist set for it (by accident I believe), but there were no icons on the tabs, so it "should" make no difference, but it did.
If a tabcontrol has an imagelist set, the tabs automatically resize to fit the size of the images in the imagelist.

It might not be a problem, but I found it a bit strange - but ofcourse when I come to think about it, it is quite obvious :)

Microsoft Visual Studio is cannot shut down as a modal dialog is active

I have encountered this error message several times when working with Reporting Services designer.

"Microsoft Visual Studio is cannot shut down as a modal dialog is active"

All of the sudden the IDE doesn't seem to respond to keyboard inputs anymore, and when you try to shut down Visual Studio, you recieve the error message above.
The error states that a modal dialog is active, but it is, however, nowhere to be found.

I found this feedback post at MSDN and apparently it is an active error (16-8-2006), which unfortunately also means that no hotfix is available at this time.

Googling the error returns multiple results, so I guess it's a widespread bug.

Anyway, the taskmanager seems to do the trick of closing down VS, even though it's not a nice solution.

The ScrollableControl.AutoScroll (1st post)

Well, my application has a split panel control, in which panel 1 is fixed. My problem it that I am using user controls in the panel 2 pane, and the auto scroll property of panel 2 didn't work. I tried to look up the problem, but no go.

I then found out that my user control's content was set to autosize and docked to fill (tablelayout control) and the user control itself also was set to autosize.
When working with the user control, there doesn't seem to be any problem - the control resizes nicely.
The problem was when I added the usercontrols to the panel 2 of the split panel control - I docked them to fill also (!). Since I added the controls programatically, I didn't really have any knowledge about the problem until runtime.

The solution was quite simple: remove Dock.Fill inside the panel 2 pane. That way the panel knows about the minimum size of the added controls, and can set scrollbars as necessary. The controls still have their minimum size (set when designing the user control it self).

Now of course this might have been obvious for a lot of people, and when I come to think about it - it is so for me too ;)