I’ll be in Frankfurt, Germany next week for BASTA!. I’m doing two sessions there and exhibiting for Developer Express. I’m looking forward to seeing you there, and please feel free to email me if you want to meet up outside the event.

I got myself a Sony Reader (Portable Reader System PRS-500 – is that a better name?) a few weeks ago. Great little device, and I’ve been reading a lot on it since I got it. In the beginning I also regularly had it hooked up to the computer to upload content, but now I’ve got nearly 50 books in it that need reading, so I didn’t hook it up for a while.

Since the device didn’t have any power supply connected, I’m checking out how long the battery actually works. Sony says it should be around 7500 page turns, and it seems to me that this is rather far from the truth… the power meter in the device is a bit jumpy – it has 4 parts, and every time it goes down one, it spends some time flipping back and forth. I got down from 3/4 to 2/4 one day, and the next day I was up to 3/4 again, stayed there for quite some time before going back down. Right now I’m on the brink of going down to 1/4, and while I haven’t counted the pages I’ve read meticulously, I’m guessing that I should be at about 3000 page turns now. Reaching 7500 before the battery needs recharging seems rather unlikely.

Do you have any experiences with this? Mind you, I’m not saying I have a problem with the battery. I’m sure it lasts long enough for anyone the way it is. I’m just wondering whether other people’s experience is similar to what I’m seeing.

I talked about this to Ian the other day: is the Vista Sidebar system really good or not? Of course there’s no simple answer to this, but I had some thoughts and they’re not all positive.

First, let me say that I really like the whole gadget idea. Somehow I was always a fan of that kind of thing – Linux was always strong in this regard, and I used to do a lot of work on Linux. The original announcement about the Vista Sidebar had me rather enthusiastic about it, and the great looks it promised to have were also appreciated. I do use the Sidebar today, and as far as it goes, I really like it.

So what’s the problem? Several things about the implementation:

• The Sidebar is just too damn small for many useful ideas. Simple thing. My laptop screen is 1050 pixels high, and the Sidebar takes up half of that space with four gadgets that actually reproduce standard system tray functionality in a nicer way – clock, calendar, CPU meter and battery monitor. Doesn’t leave a lot of space for all those new gadgets….
• Sure, the Sidebar has multiple pages. Well, that totally defeats the purpose for me… I don’t want to go hunt for those tiny buttons (top right, in case you’ve never noticed) to switch to another page. They could have done this much better – implement a “drawer” type gadget, for instance, that would extend out horizontally.
• There’s not even a way, as far as I know, for a gadget running on the second (or any other than the first) page of the Sidebar to say “hey, I’ve got something interesting here that I need the user to know about”. So unless you actively go and switch to the other pages, gadgets running on these are memory hogs, nothing more.
• You can undock gadgets, which is nice – also visually. But, have you ever tried finding an undocked gadget on your desktop? They get lost behind other windows, and they don’t come back to the foreground when you activate the Sidebar itself. They also don’t have buttons on the taskbar and they don’t appear when switching tasks using Alt/Win-Tab. So the only way to ever get an undocked gadget back is to close windows until you see it. Well.
• The Sidebar can only dock left and right. Not a problem on my laptop, but on my desktop system (which doesn’t run Vista so far) I have three monitors, two of which are vertical. So I’d want to dock the Sidebar on the top or bottom edge, right? Well, no way. This is actually something that I reported back when Sidebar was first announced, but I never got a reply on the issue.

In the end I still like the Sidebar for what it does. It’s just a real pity it doesn’t go a whole lot further… it would have been great to have a good platform for a unified plugin architecture, but I guess it won’t be long until 3rd party vendors will start creating their own again due to the problems in the standard Sidebar. And there goes – with some probability – the standard plugin architecture…

I was at NxtGenUG in Birmingham yesterday, doing a session about LINQ extensibility. I thought it was good, but ask the attendees if you want to be sure In any case I promised to make my samples and slides available, so here they are: Extensible LINQing.zip (145 KB)

In part 1 of this post, I have explained what the purpose of those wrapper classes is that I have created, and why the structure is how it is. I’m making the source code of the library available with this post – use it as you see fit, but please note that I have done no production testing of this code, so don’t blame me if it breaks.

The download is here: Sturm.CollectionWrapping.zip (6 KB)

Now how do you use that thing? Basically you use code like this:

BindingList<string> list = new BindingList<string>( );
BindingList<string> wrappedList = TypedListWrapper.CreateWrapper(list, propertyDescriptorCollection);

Now, depending on the type of list you wrap, the return value of the CreateWrapper method is actually of one of the following four types:

• TypedListWrapperBindingListT – this is used for BindingList<T> derived collections
• TypedListWrapperIBindingList – this is used for collections that implement IBindingList, but are not derived from BindingList<T>
• TypedListWrapperIListT – this is used for collections that implement IList<T>
• TypedListWrapperIList – for collections that implement IList

The selection is made in one of two ways. The first approach is based on method overloads that exist for the CreateWrapper method. So as long as the compiler can find out what type you’re using, you’ll get the correct wrapper type that way. The second approach uses an overload of the CreateWrapper method that uses “object” as the type of the collection. In this case, an algorithm runs that uses Reflection to find out in which category (of the above list) the given collection fits. This second approach seemed necessary as there are many situations when coding in .NET, where a collection type is obtained from some source that is not clearly typed (like a control’s DataSource property, to name one simple example).

Finally, the parameter “propertyDescriptorCollection” is of course just that – the collection of property descriptors that is returned by the ITypedList method GetItemProperties. There is a property called “PropertyDescriptorCollection” on the wrapped collection type, so you can change the collection after the fact. Most of the methods and constructors also have other overloads – read the source to find out more about them.

So, have fun with the library, I hope it’s useful. Let me know if you find any problems, if you have questions or suggestions for extensions.

Most of you are probably familiar with the ITypedList interface. This old post of mine shows a potential use case, and there are lots of other reasons to make use of this powerful way of influencing the mechanics of .NET data binding.

Implementing the interface is easy enough, but an interface implementation is really rather an inconvenient way of attaching a set of property descriptors to a collection – so it regularly happens that we have a collection instance at some point in our code, and we’d like to attach a certain set of property descriptors to it. The conventional way means that we have to create a derived collection type and implement ITypedList, modify existing code to make sure this derived type is returned, and finally we can benefit from the alternative property descriptor set.

To solve this problem, it would be good to have a class that readily implements ITypedList as well as (several of) the common list related interfaces, such as IList, IList<T> or IBindingList. Looks easy at a glance, but the devil is in the details. Basically, for different types of collections we need to have different wrappers. Why? Two major reasons:

1. Assuming I had a wrapper class that implements IList<T>, but my wrapped class has only IList. What do we do? Make a lot of assumptions and implement a type-safe version of the interface, which the original class didn’t even offer? That brings a lot of problems of its own and it’s really not the job of the wrapper.
2. The class BindingList<T> implements IBindingList, sure. But, although IBindingList requires only IList, not IList<T>, BindingList<T> derives from Collection<T>, which implements IList<T> as well. To make things more interesting, BindingList<T> also implements two additional interfaces, ICancelAddNew and IRaiseItemChangedEvents. So assuming we had a “generic” wrapper that could deal with IBindingList, this wrapper would not implement the other two interfaces, and probably also not IList<T>, thereby removing functionality from the class once it was wrapped. But we can’t just go and implement all the interfaces in the wrapper class – once an interface is implemented, callers will assume it can be used.

As the second point shows, it is not possible to just look at the type that we want to wrap and dynamically decide what to do – at least we can’t do that from within the wrapper class. We can modify the behaviour, but we can’t decide at runtime which interfaces our class implements or not.

Excursion: Theoretically it might be possible to do exactly what I just said we couldn’t do. We could emit IL for a dynamically created class that would implement exactly those interfaces that we need. Rather an elegant approach, but also pretty difficult to implement and maintain. I decided against going that way, as the number of required wrapper classes seems limited.

I have created a small class library that contains four different wrapper classes – one each for IList, IList<T> and IBindingList, and a special one for BindingList<T>. I will make the source code of that library available shortly, together with some usage instructions. Let me know if you have any questions or suggestions.

You thought DeveloperDeveloperDeveloper day was the least easily pronouncable name for a community event? Well, try this on: NxtGenUG is organizing NxtGenUG – Fest07 (actually I have the suspicion that it’s harder to type than to pronounce after all)! It’s a community event, I guess, being organized by a user group, but then it’s not the same type of free event we’ve seen in the past. As a non-member of NxtGenUG it costs money to attend – I’ll be interested to see whether that works out for them.

In any case they are putting the money they get to good use, and one purpose it’s being used for is a great speaker line-up. Rafal Lukawiecki is going to be there, and that alone should be a good reason for many people to come. I’m personally hoping to be speaking as well – we’ll see how that goes. “Into the future” is also a rather innovative idea for such an event, after all we get quite a lot of talks about current technologies from various sources already.

All in all, I’m sure it’s going to be a great event, even if it’s not a freebie. So if you’re free on May 23rd, I’m looking forward to seeing you there!

I’m going to be at NxtGenUG Birmingham next Monday, talking about LINQ Extensibility. Here’s information about the event – looking forward to meeting you there!

Speaking of grok talks in conjunction with DDD 5, there’s also a meeting of the London .NET User Group coming up on Feb 22nd, that focuses on grok talks on Windows Vista and Office 2007. Last I heard, Ian was still looking for attendees as well as volunteers for the grok talks themselves, so if you want to be there or even help out, be sure to let him know!

June 30th, 2007 it’s going to be. Session proposals are not accepted yet, that is planned for March. I expect sooner or later there’ll also be an “official” announcement on the DDD web page, so this is just a first heads-up.

One thing that was first tested at DDD 4 were the grok talks in the lunch breaks, and as they were a great success, the organizers are planning to keep them up. So if you’ve never spoken at such an event before, and a 1 hour sessions seems rather to you, consider coming up with a good grok talk topic and try things out in an informal setting.

I’m going to be away next week, for a bit of vacation, looking around the great English countryside with my wife. So in case you’re trying to contact me, please be patient… back online on the 12th. Talk to you then!

Karsten Januszewski announces Blend Beta 2 (yes, and Expression Design Beta 1 as well – personally I’m not as excited by this). Nice to hear we’re moving forward on this… let’s just hope Microsoft doesn’t repeat the Expression Web blunder with this. Posts I’ve read lately point to the possibility that they haven’t learnt anything in this regard, and I’m wondering how much time it is worth investing if I’m not going to use it anyway.