Mark Shields: "A compiler writer's guide to C#". A complete yet amazingly terse 89 pages covering the entire C# language. [Peter Drayton's Radio Weblog]

Wow, that's good stuff™.

So as I just mentioned, I'm making some changes to system macros. I'm not positive, but my hunch is that the next time I update my Radio.root file I'm going to lose these changes huh? What's that common practice to avoid losing one's changes? The only solution I can think of is to copy the entire macro to my own root file (aka guest database) and call those routines from my templates instead. It doesn't seem that bad, but I'm just wondering if there's a better way.

So I'm setting up my blogroll, as you can see on the right (hopefully). I noticed the rendering was a little... well, how should I put this, poopy. :) That's ok though, that's kinda the power of Radio. You're supposed to pretty things up yourself, including the system macros. So I traced the rendering down to the html.data.standardMacros.opmlToBlogRoll macro, opened it up, disected it and ulitmately made it do what I wanted it to do. Essentially I wanted it to indent each sublevel that it was rendering, so I started by augmenting the signature of the addItem routine, like so:

<codeSnippet language="UserTalk">
 on addItem(text, url, xmlurl, indentLevel=0, indentPixelAmount=10)
</codeSnippet>

Next I added a local to addItem which calculates the actual pixels based on depth:

<codeSnippet language="UserTalk">
 local(indexPixels = (indentPixelAmount * indentLevel))
</codeSnippet>

Then I found where the <div>s were being rendered and added an extra style to each one, for example:

<codeSnippet language="UserTalk">
 add("<div class=\"" + cssPrefix + "Text" style="margin-left:" +  
     indexPixels + "px;\">" + xmllinks + text + "</div>")
</codeSnippet>

Finally, I just made sure to pass the indent level to addItem where it was being called in renderOneLevel:

<codeSnippet language="UserTalk">
 addItem(text, url, xmlurl, indentLevel)
</codeSnippet>

Simple really and the interesting part is Userland was already calculating the indentlevel in their renderOneLevel routine, but they were only using it to indent the HTML source not the actual HTML content itself.

Welcome, Drew. RSS-subscribed. [Peter Drayton's Radio Weblog]

Hello Peter!  Peter's is yet another .NET blog that I frequent and, likewise, am subscribed to. Hmm... that reminds me, time to get to work on getting a blog roll together.

I, too, believe that the COM Interop is broken because it doesn't leverage IDisposable. I have to think this is one hand not knowing what the other hand is doing, given that IDisposable was really only put it because of the intense pressure by the .NET Beta community (mostly Chris Sells).

I wonder how much effort it would be to have someone else make a new COM interop tool that could grok a typelibrary, and generate the same goo, but with IDisposable tacked in for good measure. Has anybody approached this? [The .NET Guy]

Brad is in the same boat with Sam, but... I think I'm in there too. ;) The only difference that I see between their point of view and mine is that I don't consider it "broken", beause there is a way to deterministically scope the lifetime of the COM object reference (i.e. use Marshal::ReleaseComObject).  In the end you will always need to do some extra work in your component to make sure that the reference is cleaned up, regardless of whether or not they implement IDisposable::Dispose. It's just a matter of what you need to type. C# is the only language that has special semantics for IDisposable (i.e. the using statement) which is definitely nice, but what about other languages? Take VB.NET for example, those developers will still have to type out the Try/Finally and at that point the only difference is what they type in the finally block: Marshal.ReleaseComObject(myComVariable) OR myComVariable.Dispose(). Now that's not to say that VB.NET and other language won't eventually gain a shorthand statement for the IDisposable pattern like C#'s "using", but it's not there today in any other CLR based language that I'm aware of.

So to sum up, the only point I'm trying to make is regardless of the semantics of releasing the underlying COM object reference, you will always need to do some extra thinking/typing in your program to make sure the reference gets released exactly when you want it to.

I just joined NYC Bloggers. I'm off the 8th street stop on the N/R line. Speaking of which, time to venture outdoors to enjoy some of this fine city. I just bought a new pair of Salomon TR blades at the Blades shop down the street, so I'm psyched to try them out!

I've posted a response to Sam's "Is Com Interop Fundamentally Flawed?" article. Hopefully this provides a unique look at the problem that not many other developers have supplied.

This results in a response message containing the value 5, a result which isn't valid according to the schema generated for the WSDL. Perhaps it should generate an array of values ? [Simon Fell]

As Simon already found out, applying the FlagsAttribute fixes the problem, but I also had somewhat of an Enum revalation while discussing it with him. Here was my latest response to Simon on the subject:

Forget about the SOAP serialization for a second, but this actually seems more like a CLR problem to me. The runtime allowed the value 5 to be stored in a fooEnum value type. Heck, I just changed the method to do this:

return (fooEnum)5;

and it worked too. Looks like the testing the integral value upon cast for validity within the Enum is not there. So in the end I suppose they could add extra checks at the serialization layer, but it looks like the CLR is at fault for even allowing this assignment to take place. Then again, enums are just an abstract concept intended for compile time type checking. So if you do naughty things like this, maybe the compiler ought to be warning you?

I was just looking around the .NET community blogs and noticed Sam Gentile has also extended a greeting. Hi Sam and thank you for the kind introduction! ;) I also noticed Sam pulled some of his community contributions together and wonders what I think of one of them in specific. Well Sam, I've just read it and have got a great response which I think you'll find comes from quite a unique perspective. I will take the time to write up something nice tomorrow, but for now... here's a hint.

And now I'm off to my local pub (Puck Fair) to toss back a few drinks/shots and shoot the breeze about tonight's fight.