"Partial classes" is on of the new features of v2 that, while I totally get why Microsoft wanted to add it, I didn't really see any use of them beyond the vstudio code gen world.
"Nested classes" was one of the features of v1 that, while I completely understood the theoretical point of them, I had a HECK of a time coming up with any possible senario where it would actually be useful and the Right Decision.

And now, within the last week, I've ran across 2 instances where the combination of both of these features made the project better and more managable.

I'll only talk about one of them because only one is my code :)

I'm working on a control on v2 to get a feel for various new technologies we get to play with, like callbacks and new designer possibilities. One such new designer feature is the Smart Tags that pop open next to controls which give you quick access to various actions on the control. I'm using the smart tag to let you show or hide areas of the control, so you can see them as you set the various styles.

Implementing these smart tag actions isn't quite as simple as it could be for the simple cases, but I can see that it's quite powerful. So, getting back on topic, the implementation requires a custom Designer for the control, an ActionList class which handles the selection of the smart tag actions, and a TypeConverter class that supplies the list of actions shown in the smart tag. Neither the ActionList nor the TypeConverter class are useful outside of the Designer and the ActionList needs to access members of the Designer which really should be private. Therefore, they are both prime candidates for being nested classes.

However, having three classes in one code file can get tedioius with the scrolling and such. And that is where partial classes come in. Before partial classes I would have just set them as internal to avoid the problem, but that is more exposure than they require. So with partial classes, I put each nested class in its own file, with the parents' "partial class" declaration becoming an extended namespace of sorts.

So with the combination of these two features, I now have the classes having the least amount of exposure they require while still getting all the file management features I would normally have with seperate internal classes.

So ya, call me a convert.

As you can tell by the sheer size of the c# formatting options area in vstudio 2005, different companies and people love their own personal code formatting style. However, that can present a pretty serious problem to those of use who bounce around various clients, because they almost invariably all have their own style documented in some holy document.

For a while, i would just go through the settings dialogs to change to the current project i was working on. That got tedious very quickly. Then I started exporting/importing vssettings files through the wizard. But even that 10 click game gets old. So one night, after dealing with 3 different projects or 3 different clients, I got sufficiently annoyed and decided to get lazy about the whole thing.

So now I have a vstudio 2005 macro that makes it easy to add a simple macro command to my Tools menu for this. Open a project, click a menu item. yay for easiness. The only thing easier would be if it were automatic, which is something i'm working on in the background.

After building that, I just had another idea about importing settings that, while I'm not going to use myself right now, I thought would be an interesting little side project. So I also created a macro project for automaticly importing from a vssettings file over the web. Uploading the file is up to you for now, but vstudio will, upon open, download and import those settings. The idea here is to make it a bit easier to keep 2 locations ( home and work? ) in sync as far as options go.

So if these toys interest you, download and give them a try.

The cat's out of the bag about Atlas. AJAX may actually get productive soon. Not to dismiss the other frameworks in place at all. ( AJAX.net has some great ideas there ) It's just easier to incorporate a library into custom controls when it's already baked into the system.

Boy, I would _kill_ to be on the team working on that.

I took a little time last nite and today to put together something that i've been wanting since msn messenger 7 came out with its What I'm Listening To feature. See, I don't run any local-machine music players anymore since I got my Windows Media Center box from HP, so this neat little feature was fairly useless.

But since it's all player-plugin based, I figured it'd be completely possible to write some code and get that info zipping across the lan. So looking into it a bit, it turns out that Messenger does it with good ol' SendMessage, and I downloaded a nice little vb.net module that does all that win32 gunk for me.

So then the question becomes, "how do I send that info across the network?". I decided to have a little fun and use Remoting. I ended up with a local-machine Service ( that runs as System but can interact with the desktop so I can use FindWindow and SendMessage ) that exposes my VB module thru a named remoting uri. And so on the MCE box, I have a Service that gets media-state events from MCE and remotes them to my local machine.

Unfortunately, it doesn't quite completely work yet. :) So far, I've only been successfull with a normal windows app running on the MCE. When I put the same code into a service, I get nothing, but I haven't been able to figure out how to properly debug the bugger. But hey, with the media center shell running fullscreen, it's not like i can see my remoting app anyway... So it might just stay the way it is for a little while.

At any rate, Yay @ fun little projects. :)

In one of the most infsightfull-tho-slightly-bitter posts i've seen in a while...

Chuck Bryan brings together the seemingly seperate worlds of software development and childhood pool games.

Teemu brought up the current event declaration behavior today, and even pointed to a bug report about it.

I'm going to take the opposite stance. putting the onclick="whatever" attribute on the tag is the best solution to a complicated problem. Now, if the problem were limited to the points that Teemu addresses, then yes, it looks like it should changable based on the current dev model. However, the thing that makes this problem more complicated is that not every control is at the top level of your page. Asp.net uses a hierarchal declaration system with containers and child controls. One by-product of this system is that not all design-time-selectable controls on your page have references at the page level, or even refer to a single instance of a control ( in the case of a databound template declaration ).

So, if you drag a button onto your form, and double click it to add a hook to the Click event, there are 2 or 3 basic choices ( depending on language ( VB has the Handles thing going on ))... add the glue to the tag, or add it in some initialization code block. Some want to use the code block because they don't like their UI declration to know the name of the handler function of the event.

However, the hole there is that if you now move that button from the top level of the page's heirarchy, into a INamingContainer like a Repeater's ItemTemplate, then the instance referenced in the initialization-block doesn't exist. ( VB's Handles doodad breaks here too )

So how should the designer attach to events in child controls if there is no top level instance to code against, nor any guarentee that the child control will exist at any given initialization time ( or be instantiated at all during that request for that matter )? To me, it seems it can't ensure correctness with any way but declarative. Which follows to the next point... Should it really use two completely different hookup mechanisms for top-level and child controls? I assert that it shouldn't as that would lead to some nitemare maintainability problems. ( "I know that it's hooked up somewhere, where did that code block go now?" ) Therefore... the tag declaration is the correct place for the designer to hook up event handlers.

1) No OGG support. Come on Microsoft, you can do it. I know you can. You were even willing to ( apparently ) pony up the money to include high bitrate mp3 encoding. You can't hire a contract/temp developer for like a month to add support for completely free and open codecs? This is really a non-starter for me. If your player doesn't support 1/3 of my music, i'm not going to be using it.

2) The "web video" problem. Ok, this one is a bit more complicated. I'm the kinda guy that plays music 24x7. Regardless of what else i'm doing, I want my music playing. So, ok, here's the scenario... I'm surfing... I click a video link... Now, the old behavior was horrible. It used to just completely blow out your current playlist and play the video. For v10, they "solved" this problem in a half-assed way. Now, your current playlist is saved, the music is paused, and the video plays. Sure, this means you can go back to your music after the video is done, but that's not the behavior I want. What I want is for the music to CONTINUE PLAYING while the video plays. And more than just complain about it, I'll offer a solution too. It seems to me that the right way to solve this is to allow the user to "pin" an instance of wmp. A pinned instance won't be reused by other applications which open media. So I could open one instance of wmp, get my music going, and pin that instance. Then if I want to view a video clip those will be opened in a new window. Unfortunately, since something like v7 of wmp, multiple instances of wmp has not been possible. So while this is the right answer, I doubt it will ever happen.

So anyway, until BOTH of these issues are fixed, it's winamp for me.

Most databound controls are written from the perspective that they will be databound to something, but the control writer doesn’t know what that would be. It is assumed that the control’s container will set the datasource and databind it. Therefore the same container knows about and handles the datasource, databinding, viewstate usages, event handling, etc. This works great.

But then application developers come along and want self contained controls, like, say… A composite control which contains a DropDownList that always contains items databound from a database, and a button that performs magic on those items. The app developer of course calls on his local control guru to make him this control.

This gives us 3 different people with 3 very different perspectives. There is the app developer, the custom control developer, and the asp.net team control developer who made the DropDownList control. The asp.net team guy does the Right Thing in exposing a DataSource property which DataBind uses, and an EnableViewState property which says whether or not the items created should be serialized to ViewState. He’s thinking, “If a consumer of my control does want to use viewstate, they can just bind on every request.” This is a reasonable position. Then on the other end we have the app developer who is using the custom control. He had the custom control made exactly BECAUSE he doesn’t want to think about datasources and databinding and such. However, the trickiness presents itself because he does still want to be in control of ViewState usage. Maybe some specific page is hit so often that ViewState should be disabled to save on bandwidth. “My custom control should just get the data every hit, I can cache at the data-access level to make up for it.” This is also a reasonable position.

So now the custom control developer is in a bit of a pickle. The break in the chain is that the lower levels assume that one person would be both databinding and deciding on ViewState policy. That isn’t the case here.

Ignoring the ViewState issue for a second, the straightforward solution to this is that the composite control does a “if not postback then databind” thing during Load, and override its DataBind method to databind its child DropDownList to the database. But then what happens if the app developer sets EnableViewState to false? Obviously the control is broken. So the control dev needs to databind during load in both first-request and disabled-viewstate states. This mostly solves the problem; however there is one last problem that I just don’t see a good solution to. Think of the case where an app dev sets the EnableViewState property to false during PreRender. In this case the Load-time DataBind never runs on subsequent requests even though there won’t be ViewState to load and thus the control is broken. Now don’t think that I imagine this is a common scenario, but it’s unfortunate. The only thing I can think is that you’d have to push the responsibility of DataBind() onto the app dev in this case. It’s not something I particularly like, because I think the app dev shouldn’t have to worry about the datasources of controls contained by it’s composite control children. However, it’s the best I’ve come up with so far.

Any other ideas?

So one change in IE that came with sp2, that I haven't seen anybody comment on, is that about:mozilla is gone. Before I installed sp2, i had my homepage set to about:mozilla because it gave a nice colored window as the default. But now all it does it show the word "mozilla" on a white background. If you are annoyed that your nice default html is no longer around, there is a little trick that not many people know, which is that you can put any html you want in an about url, and IE will show it. So just write a simple html page that displays any color/design you want and set that text as your homepage.

Of all the features cut from asp.net v2, the only one that I'm really going to miss is the loss of DyanmicImage and the Image Generation Service.  Not so much because it's a little harder to do dynamic images in my app without them, but because it's much harder to do dynamic images in my 3rd party server controls without them. The fact that you will be able progmatticly register custom IHttpHandlers in web.config mitigates the situation a bit, but not enough.