Jelle Druyts

Sean and Scott give a great roundup of what's coming in the next versions of .NET, SQL Server and Windows. Currently, most of this information is still under NDA until the PDC but it has been assembled from all bits that have "leaked" onto the internet. Nice

I just remembered a discussion I had a few months ago about the xml encoding attribute, which got me thinking on the subject again. My original question was: "What's the use of the encoding attribute in an xml declaration?"

Let me explain briefly... If you have an declaration at the top of an xml document, this will basically tell your xml parser that the document it's reading is stored in UTF-8 encoding. The encoding is the way a document (not limited to xml documents, this goes for any text document) is actually stored or streamed, which means it defines how the ones and zeroes should make up a readable text document. There are lots of possible encodings and you can read books the size of a small building about the subject but that doesn't really matter now. UTF-8 and UTF-16 are the defaults for xml documents by the way, so if you omit the attribute, the parser should check the Byte Order Mark (BOM) at the beginning of the file to determine which of the two the file will be encoded in. This implies that every xml parser on the planet (and beyond, if SETI@home finds anything my guess is that it'll be an alien xml document) should at least understand UTF-8 and UTF-16 encoding.

Anyway, my point was: at the time the parser encounters the encoding attribute in the xml declaration, it's already reading the file so it should already be assuming some kind of encoding. To me this sounds like saying "This sentence is written in English" or shouting to people that they need ears to understand you (well unless they can lipread of course). Or to quote Blackadder III: "It's the most pointless book since 'How to Learn French' was translated into French." What I understood from my discussion on the subject is that this shouldn't be a problem because of two possible reasons:

1. All the characters in an xml declaration as the one above are very basic (i.e. they're all plain ASCII) and will be the same bytes for all the different encodings out there. I find this hard to believe (what about little and big endian differences?) but it shouldn't be too hard to check though.
2. Special bytes (such as the BOM) at the beginning of a file already indicate the used encoding. But in this case the encoding attribute doesn't seem to have any value at all anymore.

Another use could be that you could switch to a different encoding after the declaration, indicating in the encoding attribute how the rest of the document will be encoded. But why would you want to do that? I can understand that you would like to set a different encoding for some element in an xml document but what's the point of having the entire document after the xml declaration in another encoding than the declaration itself?

Even the xml 1.0 specification admits that autodetecting the encoding is a hopeless situation, also providing some hints as to what a parser should do to determine the right encoding.

So still, I don't see the real use of the encoding attribute directly embedded into the document. Especially since changing the encoding means changing the document content - which in my mind are two very unrelated things which shouldn't be affecting each other. The encoding says something about the document and therefore it is metadata. Some ("internal") metadata certainly belongs with the document itself (e.g. the date and time a picture was taken gets nicely baked into a jpeg file), while other ("external") metadata is very context-sensitive (e.g. a document's encoding). You can store an xml document on disk as Unicode, but choose to send it ASCII encoded over a wire to reduce bandwith. That doesn't change the semantics of the xml document.

I guess this is just another example of what Joel Spolsky means by "leaky abstractions". We should hide the way a file is physically stored from upstream layers but still the parser somehow needs to know how to read the bytes...

To a certain extent, filesystems already allow this type of metadata but it is very limited. For example, you can tag a file as readonly in most filesystems but you cannot define your own tags. Maybe this system should be extended to provide some generic options to associate metadata with files. If the rumors about Windows "Longhorn" are true that the new WinFS filesystem will be using a SQL Server "Yukon" as a backend, it should be a breeze to allow more generic attributes at the file or directory level. On a wire-level, the TCP/IP protocols define headers which provide out-of-band metadata but these headers are also fixed. Layers that build upon this stack, such as HTTP, will define their own headers but the borderline between inline and outline headers seems to become quite unclear.

Metadata is ubiquitous, but it has its set of problems. Maybe it's time somebody pins down the way we should be handling "external" metadata from now on - taking the context into account. For example, encoding makes sense when storing bytes to disk or transmitting them over the wire but generally not when manipulating the data semantically from within a programming language. A readonly flag has a use for a file on disk but not when it's attached to an email. Windows Access Control Lists (ACL's) defining which user has access to which files and directories make no sense when the file has left the supervision of the domain controller. If I look at Attributes in .NET I see this sort of metadata standardisation has been done beautifully within a programming environment - why not expand this to other computing domains?

Ingo Rammer points at a nice IQ test by Emode which gives you a score as well as an Intellectual Type. Apparently, I'm a Visual Mathematician with an IQ of 135:

This means you are gifted at spotting patterns — both in pictures and in numbers. These talents combined with your overall high intelligence make you good at understanding the big picture, which is why people trust your instincts and turn to you for direction — especially in the workplace.

So that's why everybody keeps bothering me all day

Update (27/08/2003):

I just noticed they even have a picture for my intellectual type:



Ok now I'm really flattered And notice how they totally personalised the image to mention my E = m c² project!

Brilliant article by Chris Sells on CodeProject: a Clickable Button Control! Absolutely amazing...

Web Services so rock: I'm teaching a .NET Framework course this week and in the Web Services module I thought I'd give a live demo of the wsdl.exe tool that generates proxy classes for Web Services. Normally live demos are not a good idea but hey sometimes you can really get something cool out of them so I figured I'd give it a go.

So I point my brower at xmethods.org to look up an interesting Web Service and I stumbled upon one called InstantMessageAlert that claims it can send instant messages to any of the four major IM services: MSN, AIM, ICQ and Yahoo! Messenger.

So I sign in to Yahoo, take the wsdl, generate a proxy class, call the SendYahoo method and BANG! Nothing happens Ok so that was a setback. Then I popped up MSN Messenger and called the SendMSN method - et voila: an instant message appears from out of the blue telling me how Web Services rule. And thereby giving me extra credit for my evaluation later on

The Devil's Dictionary defines "Blogosphere":

blogosphere, noun:
An poisonous environment of methane, self-satisfaction and other hot gasses.
“The only creatures that can survive in the blogosphere are low-order molds, able to feed off the waste of others.”

Nice

Cool Dictionary.com Word of the Day: "cognoscente" - a person with special knowledge of a subject; a connoisseur.

Sentence of the Day: "However, I thought it well to acquaint myself with the latest scientific thinking programming paradigms, so as not to write a tale code that would embarrass me among the cognoscenti". Freely after Ronald Wright, but applicable in any situation really - with only minor adjustments

Outlook has a really nice feature that automatically completes email addresses as you type them - unfortunately it keeps a record of all addresses, even if you typed them only once in your lifetime. This behaviour can vary from annoying to dangerous when the system is still suggesting an address that the person doesn't use anymore. Luckily I found an article that shows it's easy to clean outdated addresses from Outlook's AutoComplete. In short, you can highlight the wrong entry in the dropdown list you get and just press delete (which will remove just that one entry) - or you can go the hard way and delete the whole address cache that is stored in a .nick or .nk2 file in your profile. Cool!

If you have a custom control with a custom property, you can specify a default value for it by using the DefaultValueAttribute. For example: <DefaultValue("")>. This will tell Visual Studio.NET not to serialize the value to the container's code when it is equal to the default value (an empty string in this case). However, if the type of your property is an Enum, you can't just specify the default enum value. You must use an overload to specify the type of the enum and the default value as a string. So use

<DefaultValue(GetType(MyEnum), "MyEnumValue")>

in stead of

<DefaultValue(MyEnum.MyEnumValue)>

Note that both methods work in C#, but only the first one works in VB.NET.

I just noticed a cool .NET feature when launching Chris Sells' .NET FormatDesigner directly from the browser. Apparently when you run an application from the internet in .NET 1.1 it shows a balloon stating the program is running in a partially trusted context. Furthermore, the window caption is changed to mention that the application was downloaded from the internet (well I guess it just shows the trust zone it's running in) and it holds the url where it came from. 

 

Pretty nice, I guess this will help non-developers at least somewhat when this no-touch deployment thing really starts happening. It's not that much yet but it sure is a lot better than the exception dialog that I got when running the simplest .NET 1.0 form from a browser

In this article on sealed controls, Ingo looks into the details of the ImageList and the reason this class (and other controls) are sealed.

His conclusion:
"Don't cry foul whenever you encounter sealed in some framework. The designers might have had their reasons for using it, and the implications of NOT using sealed might be bigger than you can imagine at first glance. In the case of the ImageList it would have meant to rewrite ALL windows forms controls in purely managed code instead of just wrapping the underlying Win32 controls."

Well that about sums it up, now I guess we'll just have to wait until they do rewrite all controls in .NET before we can actually start extending them. Or we can just use alternatives such as Magic or Genghis.

I liked Ingo's idea to insert a proxy for the ImageList by the way - but I wouldn't expect any less from a remoting addict

Another source of getting the wrong version of your code (see my post on Various Caches) can be because your references (real ones, not Project References) in Visual Studio are wrong, so make sure they point to the correct location of the dll. Even if you have set them right before, Visual Studio can still make them go wrong sometimes. And even then, I have noticed that the compiler may use another location than the one you are referencing. Needless to say this can be very frustrating and I haven't found a solution for this yet, sadly. The biggest problem with references is the "copy local" flag (in the reference's properties), which makes a copy of the referenced dll in the bin folder of your project. This makes it easy to run your project because you don't need to register your dll's in the GAC or place them in your DEVPATH. Of course, the drawback is that if they aren’t correctly updated to match the current version (that is, if your reference is wrong), you will be working with an older copy.

If it's in any way possible - and logical within your project - use Project References. I've never seen them go bad.

Your dll's are cached in a few places: you have the GAC's Download Cache if you use downloaded assemblies (that cache can be cleared by running "gacutil /cdl"), the Visual Studio WebCache (can be cleared by closing all instances of Visual Studio and deleting the VSWebCache folder in your windows user profile) and even the Internet Explorer cache (can be cleared by deleting the cache files in the Options screen). If something goes wrong in any of these places (and trust me, it does sometimes), you could be working with a wrong version of your code and you may spend hours looking for a bug you already solved. So when in doubt, delete the caches!

Pop quiz: what do you think would be the output of the following code?

Dim i As Integer
For i = 0 To 4
    Dim s As String
    s = s & "X"
    Console.WriteLine(s)
Next

Quite possibly, you would expect to see 5 lines each containing a single X, since the variable is restricted to its scope: the For block. Since it cannot be used outside the block, you would expect it to be reinitialized each time the block is executed. Unfortunately, what we actually get is

X
XX
XXX
XXXX
XXXXX

This is because although the scope of the variable s is limited to the For block (which means it cannot be used outside it), the variable actually starts to exist at the start of the method. It's only initialized to its default value once, upon entry into the method. See Local Variables and Local Declaration Statements in the Visual Basic .NET Language Specification for more information on this.

This means you have to explicitly initialize the variable to Nothing (or to your own default value):

Dim i As Integer
For i = 0 To 4
    Dim s As String = Nothing
    s = s & "X"
    Console.WriteLine(s)
Next

If you would try something similar in C#, the compiler will stop with an error (not a warning): "Use of unassigned local variable 's'" which makes it impossible to make mistakes about this.

A lot of ASP.NET WebControls use a url, such as the NavigateUrl property of the HyperLink control or the ImageUrl for an Image. If you set such a url to a relative path, you might experience some unexpected behaviour in some more advanced scenarios - unfortunately without a clean workaround.

Internally these url's are rendered to html using the Control.ResolveUrl method. The first thing this does is deciding whether or not it's a relative url. If it's not, then the url is just returned so absolute url's remain untouched. If it is a relative url, then it is prefixed with the control's TemplateSourceDirectory - and there's the tricky part. The Control.TemplateSourceDirectory property is "the virtual directory of the page or user control that contains the server control". This means that a relative url is always relative to the containing control's directory, not to where you're setting it from. If you remember my post on ASP.NET Path Discovery, this will sound familiar. More on that later.

Now imagine a scenario where you have a breadcrumb-style header control (Header.ascx) with some navigational hyperlinks on it that need to be added depending on the page hosting the control. This means the hyperlink controls are contained in Header.ascx, and their url's will always be relative to this control's directory. If you use the header control from various places in various directories then you need to step away from the idea that setting these url's will be relative to the page you're working in. In stead you should always think on how to get from the header control to the current page's directory which is a pretty heavy burden. And as I mentioned in my post on ASP.NET Path Discovery there is no clean out-of-the-box way to discover this 'current path'.

As for a workaround: there is no property on a hyperlink or any other control that allows you to modify this behaviour and take the url you gave it as such without modifying the path. The only thing you can do is to manually set the href attribute in stead of using the NavigateUrl property as such: myHyperLink.Attributes["href"] = myUrl. I probably don't need to mention that this isn't my idea of clean code but sometimes you just need to get your work done too