I have to say that I really liked this year’s Bleeding Edge event. It happens rarely that all the pieces fit together: weather was excellent, location was beautiful, I enjoyed my trip (part by train, part by bicycle), attendees were just great and my presentation was a nice interactive (with attendees) one – just as I like. I gave a ton of swag and shown how to enhance your development experience with extending/using CodeRush DXCore, PostSharp or just by using CSharpCompiler.

Hopefully the attendees did like the presentation as well.

Download the few slides below and see you at the next Bleeding Edge!

Prevajalnik kot storitev.ppt (586.50 kb)

Microsoft is working on compiler as a service codenamed Roslyn for Visual Studio 11 which is supposed to come sometime next year, I assume towards the end of the 2012. Not much is known and Roslyn might be less feature rich as one might expect. Microsoft announced at Build conference that they’ll release some Roslyn CTP bits in a few weeks time.

The good news is that you can already use compiler as a service today through tools such as CodeRush(commercial)/CodeRush Xpress(free), PostSharp(commerical) and custom coding. Even if some tools are commercial, they provide a tremendous value.

Anyway, after a sabbatical year, I’ll talk again at the Bleeding Edge. In fact I’ll be talking about how to leverage these tools and use compiler as a service for improving both design time coding and your applications in general.

But most importantly, I'll be giving a lot of swag away :-)

See you at Bleeding Edge - do stop by and say hi.

FlowLayoutControl unfortunately doesn’t support items binding. You can’t just provide a source and hope FlowLayoutControl will populate the content. But fear not, there is nothing attached properties can’t solve.

I’ve created an attached property ItemsSource that does all that for you. Here is its declaration:

public static readonly DependencyProperty ItemsSourceProperty = DependencyProperty.RegisterAttached("ItemsSource", typeof(IEnumerable), typeof(FlowLayoutExtensions), 
            new UIPropertyMetadata(null, new PropertyChangedCallback(OnItemsSourceChanged)));

It accepts an IEnumerable as an input.

And here is the relevant code when ItemsSource changes:

private static void OnItemsSourceChanged(DependencyObject o, IEnumerable oldValue, IEnumerable newValue)
{    
    FlowLayoutControl layout = o as FlowLayoutControl;
    if (layout != null)
    {

        NotifyCollectionChangedEventHandler collectionChanged = delegate(object s, NotifyCollectionChangedEventArgs e)
        {
            switch (e.Action)
            {
                case NotifyCollectionChangedAction.Add:
                    AddItems(layout, e.NewItems);
                    break;
                case NotifyCollectionChangedAction.Remove:
                    RemoveItems(layout, e.OldItems);
                    break;
            }
        };

        // remove event implementation
        if (oldValue != null)
        {
            INotifyCollectionChanged oldIncc = oldValue as INotifyCollectionChanged;
            if (oldIncc != null)
                oldIncc.CollectionChanged -= collectionChanged;
        }
        layout.Children.Clear();

        if (newValue != null)
        {
            AddItems(layout, newValue);
            INotifyCollectionChanged incc = newValue as INotifyCollectionChanged;
            if (incc != null)
            {
                incc.CollectionChanged += collectionChanged;
            }
        }
    }
}

First it defines a delegate that gets called upon collection changes (when source is INotifyCollectionChanged) then it unsubscribes from CollectionChanged if it has previously subscribed. And finally it populates FlowLayoutControl with items and optionally subscribes to CollectionChanged event (when source supports it). Note that ObservableCollection<T> implements INotifyCollectionChanged.

Here is the code that adds or removes items:

private static void AddItems(FlowLayoutControl layout, IEnumerable source)
{
    foreach (object item in source)
    {
        GroupBox box = new GroupBox { DataContext = item };
        layout.Children.Add(box);
    }
}

private static void RemoveItems(FlowLayoutControl layout, IEnumerable source)
{
    foreach (object item in source)
    {
        GroupBox match = (from gb in layout.Children.OfType<GroupBox>()
                          where gb.DataContext == item
                          select gb).FirstOrDefault();
        if (match != null)
            layout.Children.Remove(match);
    }
}

Add items adds an GroupBox instance for each new item and sets its DataContext to the item. While RemoveItems searches for a matching GroupBox (based on DataContext match) instance and removes it from the FlowLayoutControl's Children collection.

A bit of XAML is required as well. I control the GroupBox appearance through a Style, like this:

<Style TargetType="dxlc:GroupBox">
    <Setter Property="MaximizeElementVisibility" Value="Visible"/>
    <Setter Property="MinimizeElementVisibility" Value="Visible"/>
    <Setter Property="Width" Value="150"/>
    <Setter Property="Header" Value="{Binding Caption}" />
    <Setter Property="Content" Value="{Binding}" />
</Style>

Note the binding of the Content property (remember, I am assigning current item as DataContext). And here is the FlowLayoutControl instance declaration:

<dxlc:FlowLayoutControl loc:FlowLayoutExtensions.ItemsSource="{Binding}" />

There you go, a MVVM friendly approach.

Note that this is not a fully featured code but it is a good starting point.

31.8.2011 - correct demo files

20.9.2011 - ufff, again uploaded really proper demo

FlowLayoutExtensionsDemo.zip (9.99 kb)

Since the last version released I become aware of an issue in the visualizer. If you were working on a project that referenced newer DevExpress assemblies the visualizer might have reported an exception due to the binary incompatibility with its references to the DevExpress assemblies - a assembly binding issue.

(If you want just the binaries you can skip to the end of the article and download them.)

The solution is to use a custom build of DevExpress assemblies. If you have their sources you can build your custom DevExpress assemblies using these useful scripts.

Then I have to use those custom built assemblies with my visualizer but I want to use them only for release build, not for debug. So I created a folder named CustomAssemblies under visualizer solution. I added a reference path to this folder to all of the visualizer projects. Which means that the MSBuild will use assemblies in this folder if they are present or ones from GAC (the original ones) if the folder is empty. Unfortunatelly the reference paths are global to the project and you can't have two different sets for two different configurations.

So the building of the release version looks like: populate CustomAssemblies folder with custom DevExpress assemblies, run MSBuild on Release configuration and at the end clear the CustomAssemblies folder so the debug version works with the original DevExpress assemblies. But there is one more obstacle. The license.licx file lists public key of the DevExpress assemblies and it doesn't match the one found in custom version. So I have to replace all occurences of the original public key with my custom version public key before the build and restore the originals after the build. Problems solved.

The actual release process involves also {SmartAssembly} which merges all assemblies into a single file and signing it with a certificate+timestamping and finally zipping the rather large result. Because I am not a masochist I decided to create a FinalBuilder project that does all of this automatically for me (except for building custom DevExpress assemblies).

Let me know if there are still problems!

Righthand.DebuggerVisualizer.Dataset.2008_v1.0.1.zip (12.67 mb)

Righthand.DebuggerVisualizer.Dataset.2010_v1.0.1.zip (12.67 mb)

Read more about Righthand DataSet Visualizer here.

Out of curiosity I’ve decided to compare actual heating costs versus theoretical heating costs. The calculation shows how much it would cost If I used a modern conditioner instead of a centralized heating provided by city and fuelled by natural gas. Hence I crafted a simple Silverlight application using DevExpress Silverlight components (which helped a lot, but that’s another story).

The default data is my data for January but you can enter your own. While the application is in Slovene you can pretty much understand the huge difference just by looking at the chart below. So much for naively believing that heat provided directly by fire is the cheapest one.

Follow this link to the heating cost calculator

I’ve been using DVBLink 3.1 for IPTV and Server Network Pack for a week or two now. It is a software that makes IPTV stream available to various clients, Windows Media Center among of them. It works very well with my IPTV provider SIOL (note the SIOL’s IPTV service quality is crap nevertheless) and thus I am quite happy.

While it streams fine DVBLink for IPTV’s UI is a very ascetic one. Very. Imagine having 165 channels and you have to sort them by entering a number for any of them. Horrible, just horrible. Furthermore adding or modifying channels is not easy either if not impossible (luckily channel import works).

And hence here is the first step to the UI solution: Righthand’s DVBLink Editor v1.0.0. It is an application that will let you sort all those channels easily.

First you have to load the channels configuration file (application will try to locate it and load automatically upon the start) if it isn’t loaded yet – no channels are listed and no file name is present in the config file editor. Click on […] or enter its full path manually and then hit Load button to load the content. Configuration file is named DVBLinkChannelStorage.xml and is usually found in [Program Files]\DVBLogic\DVBLink2 folder.

Once channels configuration is loaded you can order them. But before sorting the channels make sure grid sorts them by number (default) and they have unique numbers. Reorder button will assign them unique numbers while preserving the original sort order if any (it sorts by exisiting number and then by name). Basically Reorder button is a big friend of yours. Once you have them sorted you can change their order.

You can change channels order in various ways:

• by rotating mouse wheel while holding Shift key
• by pressing up or down key while holding Shift key
• by entering the number directly – the two channels will swap position

Once you’ve done with ordering you have to save the changes by clicking on Save button. By default Stop service checkbox is checked which means that editor will try to stop DVBLink Server service before saving and it will restart it (only if it was running before) afterwards. When unchecked no service will be touched. If you wonder why a service restart is necessary, there is a simple explanation: DVBLink Server won’t pick changes otherwise.

System requirements

.net 4.0 (you will be prompted to downloaded and install it if it is not installed yet on your OS).

Possible problem

DVBLogic stores configuration file under Program Files folder which is a very problematic practice. Due to the security concerns no writable configuration file should be placed in there. Period. Furthermore you’ll need administrator privileges to change the file in question.

Happy sorting and keep an eye on this blog for further improvements to the Righthand’s DVBLink Editor! Feedback is appreciated.

Find the application here.

I had to investigate a memory leak in an application I am building for my client. It is a MDI application using DevExpress XtraTabbedMdiManager that provides some MDI eyecandy. Anyway, I’ve used ANTS Memory Profiler (an excellent profiler, highly recommended) for my mission. I have soon found the cause of the true memory leak, which wasn’t an actual memory leak but rather a feature of the application – it was logging events in the memory.

One thing puzzled me though. I’ve tried this scenario. Take a memory snapshot, open a MDI child form, close it and take another snapshot. There shouldn’t be any memory leak, should it? But it was. ANTS Memory Profiler reported that the form wasn’t disposed and still held in memory. So I went looking at the Object Retention Graph for the form in question only to see this image (sensitive namespace is removed in Paint.net):

Is is pretty much obvious that there are two references holding my should-be-disposed form. One is from InternalAccessibleObject and the other one is from Form.PropertyStore. Neither is caused by application’s code. So, what’s going on? It turns out that this is a feature of .net framework MDI and not a real memory leak – it stores the last reference of the active MDI child form or something like that and thus the last form isn’t released. If you repeat the open form/close step the memory leak shouldn’t increase. In fact even the memory leak from the first step is cured.

Even though it is not a true memory leak it is a distractive feature when it comes to memory profiling – for any .net memory profiler, not just ANTS. I guess only experience helps you with these kind of distractions when hunting for a real memory leak.

See also this thread in ANTS Memory Profiler support forum.

The problem

One of the biggest annoyance when doing unit-test-friendly projects is that you have to deal with interfaces much more than you usually would. This isn’t bad by itself but it will effectively kill your F12 aka “Go To Definition”. In other words F12 won’t show you the code anymore but rather the interface definition of the method or property. Which is not what I like and I guess not what you like as well.

Let’s see an example:

When you F12 (or right click, Go To Definition) on DoTubo() you’ll get catapulted to the interface declaration of the method. Which might be what you want but mostly it isn’t. I’d like to see  the Tubo.DoTubo() method declaration where the code I am interested is. Specially because often an interface is really implemented just by one class, at least in design time.

This is what I’d like to see. And this is what you’d get if you weren’t using IAnnoy interface but rather Tubo type directly.

The solution

Good news is that now there is a way to use the go to method implementation. Even better news is that it is free. As a free lunch.

I’ve created a DXCore plugin named “Go To Implementator” that does exactly that. When over a interface’s method or property reference it will give you an option to go directly to (one of the) implementation. Sounds fine?

Installation

1. If you don’t have CodeRush already installed then do install its Express version which is free or even better, go with full version (which is not free but it is well worth it).

2. Download attached zip file and unpack its content into either [USER]\Documents\DevExpress\IDE Tools\Community\PlugIns or [Program files [x86]]\DevExpress [DX version, i.e. 2009.3]\IDETools\System\CodeRush\BIN\PLUGINS.

3. Run Visual Studio. Go to DevExpress/Options… menu and select IDE/Shortcuts node the left.

4. Create a new shortcut: click on the first icon under Shortcuts title. Click on Key 1 text box on the left and press F12 (you are telling which key to respond to). Pick “Go to interface implementation” command from Commands combo box. The last step is to click on checkbox Focus/Documents/Source/Code Editor on the usage tree list on right side – a green checkmark should appear. Note that you can bind this action (or any other) to a different shortcut or even a mouse shortcut or any other way supported by CodeRush.

Take also note that there is a “Parameters” text box. I’ll use it pass parameters to my action later on in the article.

Test & use

Create a console application and past in there this code:

class Program
{
    static void Main(string[] args)
    {
        IAnnoy annoy = new Tubo();
        annoy.DoTubo();
    }
}

interface IAnnoy
{
    void DoTubo();
}

class Tubo : IAnnoy
{
    public void DoTubo()
    {
    }
}

Position the caret on DoTubo() method reference. There are two ways to invoke my plugin.

Context menu

Right click, there should be an submenu “Go To Implementator” in context menu:

Keyboard shortcut (F12)

Just press F12. But what if you are not on a interface method/property reference? The default “Go To Definition” will be called like it would be without this plugin.

Dealing with more than one interface implementation

So far there was only one interface implementation. But what happens if there are two or more classes that implement the interface?

Let’s add another implementation to the crowd:

class AnotherTubo : IAnnoy
{
    public void DoTubo()
    {
    }
}

Now both Tubo and AnotherTubo implement the IAnnoy interface. Right click context menu should give both options in no particular sort order, like this:

 

Let’s pick AnotherTubo class. Plugin will remember this choice and next time it will be placed on the top:

But what about F12?

If there is no default class assigned then it should present you a smart tag with options:

 

 

However, if a default is available it would go straight to the implementation rather then presenting this smart tag.

Customizing the action

Popup menu behavior is fixed and can’t be customized in current version. The action, one that you can bind to a keyboard shortcut or whatever else input CodeRush is supporting can be customized. There are two parameters (parameters are a comma delimited string that you pass to Parameters text box when you are creating/editing shortcut in DevExpress/Options… – see the 4. step in installation) you might use.

NoPassGoToDefinition

You can disable invoking Go To Definition when action doesn’t do anything. The default behavior is to pass through when action does nothing. So why would you need this option? In case you are using the action from non F12 shortcut or if you want the action to do its job and nothing else.

ShowPopupAlways

When there is a default class for action available no smart tag is shown by default. You can override this behavior by passing ShowPopupAlways parameter. Then smart tags menu will be shown always when there is more than one class suitable regardless the default value is present or not.

Here is an example of passing both parameters:

The conclusion

I hope you’ll find this plugin useful. I am starting to use it and it saves me a lot of clicking. And thanks to DXCore it was really easy to create it.

Let me know if you have ideas how to enhance it or anything else, all feedback is welcome.

1.0.0 (18.1.2010)

  Initial release

1.0.1 (19.1.2010)

  Bug fix: it worked only within project scope.

1.0.2 (19.1.2010)

  Too strict parsing used which might resulted in no go to implementor option at all.

1.0.3 (21.1.2010)

  Didn't work on partial classes.

1.0.4 (26.1.2010)

  Fixed navigational bug (thanks to Quan Truong Anh for finding the bug and creating a repro case)

1.0.5 (16.7.2010)

  Added some logging - make sure DevExpress/Options.../Diagnostics/Message Logs is turned on (if you are turning it on then you have to restart IDE).
  No new functionallity besides logging - you might consider this version if plugin doesn't work well and you want to understand why.

GotoImplementator_1_0_5.zip (10.20 kb)

17.1.2011

Important: this is the last version supporting DXCore/CodeRush 10.1.x and lower.

Even more important: I've created a dedicated page and all further improvements will be published throug that page. This post won't be updated anymore.

Here is the thing. DevExpress WinForms components support custom skinning. Out of the box there are plenty of skins you might use just by assigning a simple property with a name of the skin. Every DevExpress WinForms control will follow the skin settings and will look fancy and so will your application. That’s great. But if you want more advanced skinning you are in for troubles.

Let’s see my case. An application I am building for a customer of mine supports skinning. However I had to slightly modify out of the box skins with some adjustments and I’ve added few new glyphs which I use in my custom controls (they follow skinning UI as well since entire application does). Here is how I started. I’ve opened SkinEditor, a tool provided by DevExpress and created new skins based on their skins, i.e. MyCaramel from Caramel, etc. Once I had “my” skins I’ve adjusted some properties still using SkinEditor. Finally I’ve created a “skin resource” assembly. That’s all easily done via SkinEditor. So far so good. But there are problems ahead.

First problem – adding custom glyphs to skin

Since I have custom controls that have custom glyphs I had to add those glyphs to skins. After all they belong in the skin assembly since they will be also changed when skin changes. I could add them somewhere else, but that would be asking for troubles – better to have “grouped” resources in one place. But there is no way to add custom glyphs to my skin via SkinEditor. By design. Obviously nobody at DevExpress ever supposed that custom skins might be used for custom controls.

Second problem – updating the custom skin

Next, much more annoying problem, is updating custom skin to a newer DevExpress version. Even when a minor DevExpress version is released the out of the box skin definition might change a bit - here and there. So, the template you have built your custom skin from has changed but your custom skin still “sits” on the top of the old template version. It might even result in a runtime exception if you don’t upgrade the skin while application uses newer version of DevExpress components. And go wonder, SkinEditor doesn’t have an “upgrade custom skin” option. You have to recreate the original project (what a fun when you are dealing with 20+ skins – you have to add separately) and reapply all changes you might to out of the box skins. Eeek.

Third problem – skin size

If you use a lot of custom skins they will use a lot of space (each skin is about 500KB) even though you might not be using all of DevExpress controls and thus you don’t require full skins. The relatively big size might be a problem if you distribute your application via internet and even if you don’t your application uses more memory without any apparent benefit. SkinEditor doesn’t support removing of skin elements and even if you modify skin.xml definition (by removing unnecessary nodes) SkinEditor will add them again when you open the project next time.

Fourth problem – nor skin nor its assembly can’t be unloaded

Once the skin assembly is loaded to your application (main AppDomain) it can’t be unloaded. And once skin is registered it creates a hash table of all resources (a ton of Images – I am not 100% about this but it pretty much looks like it) and you can’t unloaded any of them. So, when you register a skin assembly it will remain loaded until the application is closed and all resources will be loaded to hash table in the form of images (souds like a sort of duplication to me). There is no way to load a skin from a custom AppDomain.

Solutions to problems

The first problem can be solved “manually”. I say manually, but you can pretty easily create some XML manipulation and file copy code. While SkinEditor doesn’t support adding custom glyphs you can still add them manually in two steps – save the graphics to the proper folder of the SkinEditor project and modify skin.xml file by adding proper XML nodes pointing to newly added glyphs. After some trial and error I was able to accomplish this task.

I’ll write about the solution to the second problem in a later post. I’ll also provide an utility that does a part of the job.

I have an idea how to solve the third problem but didn’t solve it yet nor I am sure whether it will work.

The fourth problem is the most hard to solve due to the current implementation. I am not sure whether it is even possible or whether does it make sense to invest much energy into this.

Conclusion

While skinning works pretty nicely in DevExpress controls its implementation is not the best one. Specially support for custom skinning isn’t very well thought and SkinEditor can be enhanced with these problems in mind.

The good news is that with little effort I’ve managed the overcome the most important issue – how to create slightly modified out of the box skins and how to update them to new versions (automatically). I’ll talk more about this solution in a later post.

What do you think? Do you use DevExpress skinning feature? Did you create your own skins?

First new “feature” is stepping down from three releases per year to two releases per year. Regardless how it sounds, it makes sense. A lot of sense. Developers and other staff spent a lot of time preparing releases and I don’t mean implementing new features but just preparing and testing the releases. From now one they will have more time for coding new features. As per DevEx clients this is good news as well – having to do major updates less time per year provides similar benefits. Bottom line is that we have more features, less work and possibly less bugs.

From the technologies perspective it looks like WPF and Silverlight are getting mainstream while WinForms is dropping down from first place (that said it isn’t a dead product, far from it, it is just not the most important anymore – I am very pleased to see this shift happening). ASP.NET MVC will get some beta versions (“we shall be testing the waters with beta versions of the data grid, menu, navigation bar, and tab control”) while ASP.NET is still the most important of the two.

Visual Studio 2010 is going to be supported big time including CodeRush for VS2010.

These are news in brief from what I can read. But don’t take my word for granted, read it yourself at http://www.devexpress.com/Home/Announces/roadmap-2010.xml.