Firebug for XAML anyone?

by Pezi 20. July 2009 23:10

Sad is the time when all those web-related layout CSS and HTML issues come headlong together with desktop applications, but for anyone who has used XAML (or extensible camels as I like to call it/them) with WPF / .NET 3.5 will know exactly what I mean.

However all is not lost, no need to re-compile your project 100 times to try and move an arrow or change the colour of a label which after 2 hours transpires it is being modified by 6 different styles and properties from all over the place.... Snoop to the resuce!  No longer will you get the hump with those camels (as much!)


This is essentially firebug for WPF / Camels.  Complete with inspect button, full camel tree view, style heirachy and the ability to add/modify stuff on the fly.  And it's open source Cool

It's sad this should be required but 'tis the way of the future apparently !

Type constraints on generics

by Pezi 20. July 2009 22:54

Time to start using this a bit more for general ramblings on things I've been up to.  Have 0 time for electronics, robotics and the like at the moment.

I have been working on the game server a lot recently, which was originally written in .NET 1.1.  Unfortunately it still has a lot of this old code and one thing that as been annoying me in particular is the serialization mechanism.  .NET 1.1 did not have any support for generics, but sine we've upgraded to .NET 2.0 (ages ago) this stuff hasn't been upgraded.  This is massively annoying given that the old rubbishy ArrayList is the only thing it knows about for collections.  Why it wasn't implemented with ICollection or something I really have no idea.

These days on the server, I am busy throwing around type-safe strongly typed Lists of objects which are far superior to the (obsolete - hell List<Object> over ArrayList) ArrayList.  This means everytime I want to serialize these I have to make a copy of the List into new ArrayList and then pass that to the serialization class. Fail.

 Example.  Given a list is declared as a member varaible for some Item or other like so:


private List<SomeItem> m_SomeItemList =  new List<SomeItem>();
public override void Serialize(GenericWriter writer)

  writer.Write(0);  //version

  writer.WriteItemList(new ArrayList(m_SomeItemList ));  // FAIL

Then in the serialize method you have to do this:

 Rubbish - totally unnecessary and scary copy of the collection to an inferior type.  Our serialization class has three methods for writing collections of specific types - Items, Mobiles and Guilds.  In effect these are all the same they just have slightly different logic that works on the different types.  It doesn't STOP you passing totally the wrong data, mixtures of data or anything of the sort though.  Something like Item is only really a base class that has tons of other classes inheriting from it, and others from those - so this problem is obviously suited to generics.  The problem here is that depending on the item type some different logic is applied - this won't work then with generics because the T isn't known about at compile time and thus you can't access the type's specific fields/methods/etc.  Enter type constraints on generics.  These allow you to tell the compiler to expect the T to be at LEAST of a certain type, like so:

public abstract void WriteItemList<T>(List<T> list) where T : Item;

Now when this method is implemented in the serilializers, the compiler will know to expect a Item of some kind even if it has several other parent classes before Item in the inheritance tree, thus allowing us access to the properties and methods of the Item class directly.  There are other bits you can add to these constrains like New which will ensure a class is passed in which is capable of having a constructor called.

 This principle is also applied to the deserialization that also has methods to read these collections as serialized by the write methods. Before now I would have to iterate across the collection it returned and manually add each item into my strongly type list - waste.  I have written new overloads for these methods defined as followed:

public abstract List<T> ReadItemList<T>() where T : Item;
public abstract List<T> ReadMobileList<T>() where T : Mobile;       
public abstract List<T> ReadGuildList<T>() where T: BaseGuild;

public abstract void WriteItemList<T>(List<T> list) where T : Item;
public abstract void WriteItemList<T>(List<T> list, bool tidy) where T : Item;
public abstract void WriteMobileList<T>(List<T> list) where T : Mobile;
public abstract void WriteMobileList<T>(List<T> list, bool tidy) where T : Mobile;
public abstract void WriteGuildList<T>(List<T> list) where T : BaseGuild;
public abstract void WriteGuildList<T>(List<T> list, bool tidy) where T : BaseGuild;

Now we can simply read and write strongly typed lists of stuff with no unnecessary copying of collections, loss of type safety and any other such rubbishness.  Example of use now :


m_SomeItems = reader.ReadItemList<SomeItem>();