compilewith.net

GL.NET WPF Talk

2010-01-21T17:10:00.001Z

For those of you who attended my WPF talk last night at the GL.NET User Group meeting, thank you for coming and listening; here are the book references I promised:

1. Essential WPF by Chris Anderson

Chris was one of the Architects on WPF and therefore provides a lot of insight into why things were done the way they were. This book gives you the essence of what WPF is all about.

2. WPF Unleashed by Adam Nathan

Adam is an excellent writer and this all colour book is a real "how to" book; a book on how to get things done by using WPF.

3. Programming WPF by Chris Sells and Ian Griffiths

This is the deep dive on WPF, the nuts and bolts, the nitty gritty of how things work. This is a great book that I constantly find myself going back to.

If you have any questions or comments please feel free to drop me a line here, just add a comment to this post or send me a mail by using the contact link above. See you all next month at the next meeting; think deeply and enjoy.

Download the presentation.

MIX10 10K Smart Coding Challenge

2009-12-22T08:08:00.001Z

The Microsoft MIX conference is starting to ramp up again with MIX10, and with it the MIX10K Smart Coding Challenge. So it’s time to crank out another application with 10K or less of source code, and get me another one of those lovely MIX t-shirts!

This year I’m doing something a little more conventional than my entry last year: a game (albeit a simple one), a game I like to call Bing Pairs. The idea is to simply find the pairs of Bing background images as fast as you can [click here to vote for my efforts].

Here’s a short video of the game in action:

All that, and all for less than 10K of source code!

I would be very grateful if you could take a moment out of your day to go and vote for my entry, thank you.

WPF Data Bound RadioButtonList

2009-11-28T17:24:00.001Z

During the process of writing a WPF application recently, I had the need for a data bound list of items where the options had to be mutually exclusive, so I figured something like a list of RadioButtons would be in order.

However, when I started looking around I could not find a RadioButtonList or anything that fitted the bill out-of-the-box. Therefore, I thought I’d put something together myself; I also needed to have the list render horizontally rather than vertically. This is what I came up with:

<Style x:Key="RadioButtonItemStyle" TargetType="{x:Type ListBoxItem}">
    <Setter Property="Margin" Value="0,0,5,0" />
    <Setter Property="Template">
        <Setter.Value>
            <ControlTemplate TargetType="{x:Type ListBoxItem}">
                <Border BorderThickness="0" Background="Transparent">
                    
                    <RadioButton
                        Focusable="False"
                        IsHitTestVisible="False"
                        IsChecked="{TemplateBinding IsSelected}">
                        <ContentPresenter />
                    </RadioButton>
                </Border>
            </ControlTemplate>
        </Setter.Value>
    </Setter>
</Style>

<ItemsPanelTemplate x:Key="HorizontalItemsPanel">
<VirtualizingStackPanel
Orientation="Horizontal" />
</ItemsPanelTemplate>

I defined a Style and the ItemsPanelTemplate in the Resources property of my Window that contains all the necessary XAML for the effects I need; note that you could just as easily define this XAML inline on the ListBox as opposed to using the Resources property. I then applied these two new elements to an instance of ListBox using the following mark-up:

I’ve highlighted where I’ve used the two resources.

For this example the data list is trivial and is provided by a ViewModel class attached to the DataContext of the Window; I’m only showing the code here as a example of how you can add sample data to an application, as well as proving that the above XAML all works as expected using a bound list of data:

public class MainWindowViewModel
{
    public IEnumerable<string> MyDataList
    {
        get
        {
            yield return "Stan";
            yield return "Cartman";
            yield return "Kenny";
            yield return "Karl";
        }
    }

    public string MyDataListSelectedValue
    {
        get { return "Cartman"; }
        set { /* TODO: save the value */ }
    }
}

<Window.DataContext>
<vm:MainWindowViewModel />
</Window.DataContext>

Here’s what it all looks like in the Visual Studio designer:

And there we have it, job done. Hope this helps someone, happy XAML hacking.

WPF: MV-VM Sample Application with Navigation

2009-11-04T10:47:00.001Z

I have recently been reminded of how difficult it can be to get started when you are trying to build an application and have been given a completely clean sheet of paper to start from – in terms of the application architecture and design – the options are limitless, which can at times be a little daunting.

Recently, to help a colleague combat the clean sheet of paper syndrome, we had a conversation about some of the patterns and ideas that he might want to consider with the particular application he is writing with WPF. The result of the meeting, after 90 minutes of discussion, was a whiteboard full of pattern names, blocks and arrows, which all appeared to be clearly understood by all involved at the time and we left feeling that it was a job well done. However, it occurred to me on the drive home that when faced with a blank code editor the next morning, would all those squiggles and arrows still make sense?

That lead me to thinking that a simple application that outlines not just the theory of some of the standard patterns that I use for building applications today, but also shows concrete implementations, real strategies, real code and compromises, not just code snippets of isolated issues, but a complete, albeit simple, application.

The following sample application, and accompanying screencast, are the results of that thinking. When I handed off both of these to my colleague it also occurred to me that others might benefit from the sample and would also serve as a reminder for me in the future, hence this post.

The application itself is somewhat trivial, but the patterns and architecture discussed are not. The sample covers:

ModelView-ViewModel (Application architecture)
Repository and Service Patterns (data modelling and retrieval)
Command Pattern (for communication between the Views and the ViewModels) ^[1]
Various different types of View, including Page and Window ^[2]
Text to FlowDocument value converter
Poor man’s Dependency Injection

Click here to download the sample code.

I sincerely hope that you get some value out of this post, and as usual if you have any comments, questions, flames, enhancements I would love to hear from you. In the meantime, think deeply and enjoy.

^[1] Including a hybrid DelegateCommand class inspired by standard MV-VM commanding, sometimes referred to as a RelayCommand, and Prism’s DelegateCommand implementation

^[2] Page based Views and navigation are specific to the application discussed in the 90 minute meeting, where what you would usually see in a traditional MV-VM discussion would be UserControl instances as the Views. I think the use of Pages in the sample makes it a more interesting sample that shows more varied View types than you would normally see.

MSDN Flash

2009-10-08T17:35:00.001+01:00

Update: 2009-11-02 The podcast is now available on Channel9 too.

At a recent GL.NET user group meeting I met Eric Nelson (@ericnel), and he asked me to write an article for the MSDN Flash newsletter (@ukmsdn), so I did. I expanded on my previous post regarding Memory Mapped Files in .NET 4, and that article has been published today.

You should be able to read the entire newsletter on-line, however, at the time of writing this post the current newsletter link was showing last month’s newsletter, but I’m sure that will change very soon. However, I’ve put a copy of the article at the end of this post, if you’re interested in reading it.

I also did the podcast which accompanies the newsletter with Eric, and it was an absolute blast. I’ve not done anything like that before so it was quite a departure from my normal working day. You can find all the podcasts here.

As usual if you have any comments, questions, flames, enhancements I would love to hear from you. In the meantime, think deeply and enjoy.

Memory Mapped Files with .NET 4

.NET 4 is on its way and there are many new features being blogged about, such as Parallel Computing and Dynamic Languages but the new feature that caught my eye was Memory Mapped Files. The idea of mapping memory to a physical file on disk has been around for a very long time on the Windows platform but this capability has not been available natively in managed code before and instead needed to be accessed via P/Invoke.

You might be wondering why you would wish to map memory on to a file, and why after numerous versions of the .NET Framework we need this feature now. To answer the first question it is worth pointing out that a memory mapped file is one of the most efficient ways for multiple processes on a single machine to talk to each other. What is more, most Windows IPC based communication mechanisms, such as COM, DDE, Sockets, Pipes and even Windows Messages themselves all sit on top of Memory Mapped Files. Another reason for using Memory Mapped Files is for processing extremely large files, as they enable random and concurrent access to a file without the need for seeking.

The large file processing is lovely and all that but I want to talk about inter-process communication on a single machine for a moment. There are many available options. You could go old school by using classic .NET Remoting for cross AppDomain communication by using transparent proxies, MarshalByRef and ContextBoundObject classes. You could code this using WCF and Named-Pipes; as well as all the available cross-machine techniques such as streams and sockets, or Web services by using one the various flavours of WCF Bindings or not forgetting plain old ASMX.

Given this wealth of options, when should you use Memory Mapped Files (MMF) over, say, WCF? For me, the answer is simple: it depends. As always with new technologies your millage may vary, but I think as a general rule, for IPC on a single machine MMF is the way to go; if only for the relatively simple programming model (see my blog post for a simple code example) and performance characteristics. Sometimes, when you need to send 4 bytes, you should just send 4 bytes; not a Soap envelope, encoded with a myriad of WS-* standards and human readable mark-up running into hundreds and hundreds of bytes – just to send your 4 byte message.

Memory mapped files will be my first choice for the scenarios that were previously reserved for WCF and Named Pipes, well, they will be as soon as .NET 4 ships. However, if you even suspect that at some point you might need your communication to spread across machines, then you are better off starting with WCF and named-pipes, because supporting cross machine communication in the future should simply be about making changes to configuration not recoding the communication layer.

That brings us back to the second question of: why now, why in .NET 4 and not some previous release. For that, we can only guess; but I am glad they finally did! You can find out more in the preliminary MSDN documentation.

Paul Jackson
Blog: http://compilewith.net
LinkedIn: http://www.linkedin.com/in/paulja

A word on Microsoft Oslo and installing MX files

2009-07-29T18:09:00.001+01:00

Each time I sit down to do something with Oslo I look forward to it. However, I keep tripping over the same issue: I never seem to be able to get the switch combination right the first time, and often not after the tenth time either! I always seem to burn 30-40 minutes each and every time I try and get my first .MX file into the target datastore.

This time loss is partly my fault, as for some reason I’ve neglected to write down the command line that works before moving on. Each and every time I’ve done this; it seems that after I’ve got it working, I look at it and say to myself:

“Oh, come-on. That’s obvious. I’ll figure it out easily next time”
Quote by: A Pillock

Well, let me present this post as evidence that this is positively the last time that it will EVER happen to me again. I’ve been duped too many times, I have now learned my lesson… promise.

I’m just not using the tooling often enough for it to stick, and it’s subtly broken enough to keep tripping me up, so here, for ever more (thanks to Google… oh, and Bing I guess – the jury is still out on that one though) is what you need to do to get a compiled “M” file into a SQL Express database using Integrated security where SQL Express is not the default instance, but is the default SQL Express install (if that makes any sense!?):

MX install <filename>.mx -s .\SQLEXPRESS -d <database name> -c –f

Don’t be fooled. I know this looks deceptively simple, but believe me, this is hard won information! Note the spaces between the switch and its value, for example –s and \SQLEXPRESS; that’s the thing that screws with your mind. The docs clearly state that a colon “:” between the name value pair should be used, however, I have found this not to be the case!

I’ve have had it confirmed by @csells via Twitter that this is indeed a bug, and I should be able to use a space, colon or even an equals! But I’m telling you now, dear reader, this won’t be catching ME out again!

.NET4 and Memory Mapped Files

2009-06-11T09:29:00.001+01:00

I think I am really going to like .NET 4:

I certainly welcome this new addition to .NET, and for inter-process communication on a single machine, it’s fabulous. Move over WCF and Named Pipes memory mapped files coming through. Memory mapped files will be my first choice for the scenarios that were previously reserved for WCF and Named Pipes, well, as soon as .NET 4 ships.

With great power comes great responsibility, the memory mapped file approach seriously ups the ante when it comes to understanding and using multithreading in your code; incidentally I highly recommend Joe Duffy’s Concurrent Programming on Windows, it is on my must read list for any developer working in Windows today.

If this is a topic that you enjoy, you can find more information about this feature in .NET 4 on Salvador Patuel’s blog. As usual if you have any comments, questions, flames, enhancements I would love to hear from you. In the meantime, think deeply and enjoy.

XBAPs and Bitmap Effects

2009-05-29T17:36:00.001+01:00

It has be a while since I last put together an XBAP (XAML Browser Application), so the myriad of security hurdles that one has to overcome has long since vanished from my short term memory; to the point where I am having to re-learning things. Bugger, I hate that! With that in mind, the purpose of this post is to document something I have rediscovered about XBAP’s and bitmap effects, in an attempt to help me remember and not have to keep relearning the same stuff.

So first off, bitmap effects are cool; they add a certain pizzazz to your UI, and if used subtly they really can make a big difference in the visual appeal of your UI:

However, you cannot use the BitmapEffect property on the UIElement class in an XBAP – note that UIElement is very high in the object hierarchy for WPF, so just about all visual elements contain this property by way of UIElement and then FrameworkElement; here is how you would use a BitmapEffect in XAML:

Attempting to run this XAML from within an XBAP, with the default configuration of Partial Trust, you see the following error message:

Interestingly, this is not a SecurityException, but simply a XamlParseException. However, if you are running in debug mode and happen to check the Output window, you see the following:

Note that the second to last line is a SecurityException, so the reason that the XAML cannot be parsed is due to a security failure. If you remove the BitmapEffect from the XAML, and only the BitmapEffect, all works as you would expect. From my experience this is the typical developer experience when falling over a partial trust issue, note that the SecurityException contains no additional information, let the needle in a haystack search begin; but more on that later.

It is also worth noting that WPF has matured, and is now able to leverage the GPU in your graphics card (or an approximation in software) by way of the Effect class. I am sure that there are some really awesome explanations as to how that works and what that is all really about, but that is not what this post is all about (if you know of a good explanation then please let leave a comment at the end of the post). From the point of view of a developer who has little interest in creating their own effects, to make use of this great feature simply use the new shiny Effect property, also found on the UIElement class, introduced in WPF 3.5 SP1.

However, WPF also does not allow an Effect class instance in Partial Trust – and therefore you still cannot use one in an XBAP without changing the permission requests. It is worth pointing out that not all the previous bitmap effects have been implemented as Effect‘s; at the time of writing there are only three:

BlurEffect
DropShadowEffect
ShaderEffect (used for creating custom effects)

Meaning that we cannot make use of the GPU today for the following type of effects:

Bevel
Emboss
OuterGlow

Personally, I do not think that this is any great loss, as the only effect that I miss is the OuterGlowBitmapEffect; it may well serve as a good catalyst to prompt me to learn a little more about creating my own effects.

To add an Effect to your application you use the following XAML:

Attempting to run this XAML from within an XBAP, with the default configuration of Partial Trust, you see the following error message:

This time, while it is a XamlParseException, as before, but Microsoft have massively improved the exception handling with these effects as they actually tell me WHY it has failed: Request for the permission of type ‘System.Security.Permissions.UIPermission’ failed. Awesome, this means I can “tweak” my security settings to get the application to run when using an Effect:

Now this is the only permission I have to change, I do not have to make my whole application run in Full Trust to use the effects. I can take this a step further in for my application by configuring the properties of the specific permission, to prevent access to the Clipboard, if the application does not need it:

So thanks to the better error reporting when using the Effect’s classes in a partial trust environment, I can now successfully isolate just the permission I need, and make a calculated decision as to whether this is something the application really needs. Note however, tweaking this permission does not work when using the BitmapEffect classes, I still have not found that needle in the haystack yet.

So while I cannot show you the application running in the wild due to the “extra” permission required (click the image above to see the security error), the screenshot above does show the application running in my environment, where I’m happy to allow the application the permission it requires, which is perfect for an intranet or extranet environment. Alternatively, I could sign the application with an SSL certificate and you could trust that.

Finally, I want to talk quickly about the analyzer tool in Visual Studio 2008. The purpose of the tool is to work out if your application can run in partial trust; it is good at telling me if I need to run in full trust or not, which is very helpful, but it is really poor at telling me WHY! Making it really, really, really hard to fix these violations of partial trust, especially in these cases where I cannot easily remember all the details of what you can and cannot do, or if you are a newbie. As we have seen they have improved the exception handling for an Effect, however, I sincerely hope for more improvements with WPF 4.0 in this area. If anyone knows of any other tooling or a better way to keep on top of this issue, I would love to hear from you.

I hope this has been useful, as it was only a small “nice to have” feature that I added to one of my applications and it threw for me quite a while to isolate the problem and get the XBAP working at all, never mind the effects; but it was useful to also explore both BitmapEffect and Effect and work out the differences.

As usual if you have any comments, questions, flames, enhancements I would love to hear from you. In the meantime, think deeply and enjoy.

Invalidate Often, Update Once

2009-05-28T11:36:00.001+01:00

I’ve recently been watching a bunch of the longer sessions from MIX09, mainly Hiking Mount Avalon and Robbie Ingebretsen’s session(s) Design Fundamentals for Developers; both of which are about 3 hours long but well worth the time spent watching.

During these sessions I’ve taken copious notes (by using Evernote) and for a few of the more complex and/or unexplored topics I want to write a post, as well as put together some code, on my own to make sure I’ve understood the concept, and to generally share the wealth: this is first post in what I suspect will be a series.

This post is about updating UI elements on the UI thread. A lot. Time consuming updates. On the UI thread. A lot of updates.

The example application I’ve written to discuss this technique is described by the following class diagram:

And this screenshot:

The application consists of a ListBox where the ItemsSource property is set to an ObservableCollection<int>, and then when the Add Items button is clicked a method called OnAddItems appends ten thousand random integer values to the collection. There is also a listener wired to the CollectionChanged event on the ObservableCollection<int>, which simply invokes a method called UpdateTotal that adds up all the integers currently in the collection, and then presents the calculated value in the UI as the Total.

What this application is attempting to simulate is a situation where a large number of items need to be added to the UI in quick succession, but where there is also some additional action required after an item has been added, a calculated value in the example application. Here’s the code for OnAddItems, OnCollectionChanged and UpdateTotal which outlines how these methods interact:

private void OnAddItems(object sender, RoutedEventArgs e)
{
    Random rnd = new Random((int)DateTime.Now.Ticks);
    for (int i = 0; i < 10000; i++)
        this.list.Add(rnd.Next(0, 100));
}

private void OnCollectionChanged(object sender, NotifyCollectionChangedEventArgs e)
{
UpdateTotal();
}

private void UpdateTotal()
{
    int total = 0;
    foreach (var item in this.list)
        total += item;

this.Total.Text = total.ToString();
}

The problem with the code is simply that it’s too noisy on the UI thread. The OnCollectionChanged method is called ten thousand times, and the list is totalled ten thousand times as each integer and the UI is also updated tens of thousands of times. Obviously this example is a little contrived but I’m sure you can think of some real world scenarios or maybe you’ve seen code like this in the wild.

To give you some idea of how the performance degrades on my machine here’s the debug output for this sample application, which displays the total time it takes, in milliseconds, along with how many items are currently in the list; remember that ten thousand items are appended each time Add Items is clicked:

Time taken (milliseconds): 787.375, # List Items: 10000
Time taken (milliseconds): 2084.1261, # List Items: 20000
Time taken (milliseconds): 3344.678, # List Items: 30000
Time taken (milliseconds): 4715.5841, # List Items: 40000
Time taken (milliseconds): 5948.9176, # List Items: 50000
Time taken (milliseconds): 7232.911, # List Items: 60000

Assuming that we all agree that while this is a contrived example it is still a real world problem that needs a solution; and that solution is the WPF Dispatcher and a single boolean flag. Take a look at the following video that I put together to demonstrate how badly the current code impacts the UI thread, and how massive the improvement is by using the Dispatcher and an invalidate approach, as opposed to update approach:

Here are the the changes to OnCollectionChanged and UpdateTotal methods, and the new InvalidateTotal method that makes this approach work:

private bool isTotalValid;

…

private void OnCollectionChanged(object sender, NotifyCollectionChangedEventArgs e)
{
InvalidateTotal();
}

private void InvalidateTotal()
{
    if (this.isTotalValid)
    {
        this.isTotalValid = false;
        this.Dispatcher.BeginInvoke(DispatcherPriority.Normal, (ThreadStart)delegate
        {
            UpdateTotal();
        });
    }
}

private void UpdateTotal()
{
    int total = 0;
    foreach (var item in this.list)
        total += item;

this.Total.Text = total.ToString();
this.isTotalValid = true;
}

With the code above, a new flag has been introduced: isTotalValid, which indicates whether the UpdateTotal method should be called. The OnCollectionChanged method no longer invokes UpdateTotal directly, instead it calls a new method called InvalidateTotal. The new method checks the isTotalValid flag, and if the total is valid promptly marks the total as invalid and queues a asynchronous call to UpdateTotal by using the Dispatcher.

By doing this the call to UpdateTotal has been placed on the Dispatcher’s message queue behind the currently executing call, effectively delaying the call to the UpdateTotal method until after the current thread becomes idle or the scheduler decides to let someone else have a turn, meaning that in most cases the UpdateTotal method is called only once, but InvalidateTotal is called thousands of times. Finally, the UpdateTotal method marks the total as valid once more, and the cycle begins again.

The key takeaway here, is invalidate rather than update; this is an approach adopted all over WPF, and one that I will certainly be adopting in my WPF code. I also want to offer a big thank you to Robby Ingebretsen, Jaime Rodriguez, Mike Hillberg, Lee Brenner, Laurent Bugnion and particularly for his help with this post Jonathan Russ, who explained this concept in the Hiking Mount Avalon session.

You can download the sample application from here: PaulJ.InvalidateOftenUpdateOnce.zip

As usual if you have any comments, questions, flames, enhancements I would love to hear from you. In the meantime think deeply and enjoy.

ICloneable, a perspective on the current guidelines

2009-05-09T12:36:00.001+01:00

To be talking about an interface this old might seem strange, but I’m primarily working with legacy code (code without tests) at the moment, and I’ve seen some uses of this interface that took me aback, as for me, the thinking shown below has been with me so long it’s almost a subconscious thought; but I felt the need to say it out loud as it might help someone.

First off, ICloneable is considered a Bad Thing^TM; the reason for this is poor naming in relation to whether the clone is a deep or shallow copy, see here for more information about this, but here’s a snippet from BradA’s blog about the use of ICloneable:

Because the interface contract does not specify the type of clone performed, different classes have different implementations. A consumer cannot rely on ICloneable to let them know whether an object is deep-cloned or not.

Having said that, cloning is useful. Given that we’re not going to be able to change the name of the interface method inside the framework, here are my guidelines for working with cloning and the ICloneable interface:

Do use the ICloneable interface .. but decide upfront in your project whether Clone means a deep or shallow copy .. to be perfectly honest a shallow copy is rarely useful, therefore I nearly always stipulate that Clone means deep; and then, be consistent throughout the code-base.
If Clone means shallow in your project, then use the Brad’s guideline and create a new interface, say ICloneable<T>, with two methods: Clone and DeepClone.
If following step 1, implement the Clone method to be type safe and then also provide a public typed version of the call; for example:

public class EffectInfo : ICloneable
{
    #region ICloneable Members

    // Typed version of the call
    public EffectInfo Clone()
    {
        return (EffectInfo)this.MemberwiseClone();
    }

    // Interface implementation
    object ICloneable.Clone()
    {
        return this.Clone();
    }

    #endregion
}

<digression> The ICloneable interface shipped with v.1.0 of the Framework, generics did not yet exist; therefore to implement a type safe version of an interface you have to do interface implementation and then provide public typed versions of the members, as shown above. </digression>

Obviously, if you have the concept of ICloneable<T> in your project, with deep and shallow copies, you do not need to take this approach to get type safe versions of the call.

As usual if you have any comments, questions, flames, enhancements I would love to hear from you. In the meantime think deeply and enjoy.

Just say no to the pop-up

2009-04-24T08:29:00.001+01:00

I don’t usually write a blog post to simply link to some other blog post (that’s what delicious and Twitter are for), but I think that this is such an important concept for UI design today, and in the future, that I feel the need to underscore it with a blog post:

yes, … "pop" is a bad thing.

Above is a (mangled) quote from the “How pop is the new flicker” blog post by the Microsoft Surface team, which highlights a very simple but important aspect for new UI, also illustrated in the following short movie from the same post .. which is: remove the pop-up window/dialog/menu.

The call to action:

Read the post, and then eliminate the pop-up from your code.

If you do this I believe you’ll dramatically improve the user experience and polish of your application. Obviously you have to put this advice in context with your application as it might not always be appropriate, but as a general rule, if you can replace a pop-up with a transition (made easier by tools such as WPF and Silverlight) you will be in a better place, and your users will thank you.

As usual if you have any comments, questions, flames, enhancements I would love to hear from you. In the meantime think deeply and enjoy.

Have you taken the Prism survey?

2009-04-02T09:14:00.001+01:00

Blaine Wastell has published a survey on his blog about Prism, in his words:

We use this information to understand where we need to improve the guidance for the next release of Prism. If you have ideas for what is needed in the next version of Prism....

If you have used Composite WPF (a.k.a. Prism) in any way and want to help shape the next release, please go ahead and take the survey .. it’s about 20 questions and will only take you about 10 minutes.

WPF unit testing trouble with Pack URIs

2009-03-30T11:02:00.001+01:00

I have been busily coding WPF and Silverlight 2 for the last couple of months, and I will be for at least a few more weeks to come; however, during this development frenzy I ran into an issue with unit testing some new code. I also found an interesting solution to the problem, which required more than a simple query by way of Google, so I thought I’d share the problem and the solution here, just help the boys and girls at Google out a little.

The code under test relies on certain embedded resources. Said resources are to be consumed by a WPF bootstrapped assembly; therefore each resource is embedded in the assembly by using the build type of Resource, as opposed to Embedded Resource, which in turn means each resource has to be referenced by using a Pack URI. Therein lies the rub: whenever the unit test attempted to call the code that pulled out any of resources I would get the following UriFormatException:

System.UriFormatException was unhandled
Message="Invalid URI: A port was expected because of there is a colon (':') present but the port could not be parsed."
Source="System"
StackTrace:
at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)
at System.Uri..ctor(String uriString, UriKind uriKind) … <snip/>

Bugger! You can easily reproduce this error by running the following code snippet in anything other than a WPF application:

var packUri = new Uri(
"pack://application:,,,/ReferencedAssembly;component/Subfolder/ResourceFile.xaml",
UriKind.Absolute);

As the test harness is not bootstrapped by a WPF application it knows absolutely nothing about Pack URIs; and in my case the System.Uri parsing code ended up trying to parse the Pack URI as if it were a Web URI, which is clearly not what I wanted and creates a situation where all roads lead to Exception City.

However, all is not lost, here is the simple solution I used for my tests:

if (!UriParser.IsKnownScheme("pack"))
{
UriParser.Register(new GenericUriParser
(GenericUriParserOptions.GenericAuthority), "pack", -1);
}

If you run this code before you try to parse any Pack URIs all will be well. It is worth mentioning that you need to only call this code once per process. This code registers pack as a valid scheme (in the form of pack://) and then puts all URI parsing into a generic mode, only parsing against registered schemes (which pack is now one), and that is it .. the job, as they say, is a good ‘un.

I’ve written a small test application that tests the URI parsing across threads to prove that the Register call is truly process wide, which you can download from here: PaulJ.PackUriParsing.zip

Above is a screenshot of the app .. the first call shows the parse failing, before the call to Register, then the second two calls show the exact same Pack URI being parsed successfully on two different threads (the main UI thread, and a newly created thread for the test).

I hope this helps to make for a better Google experience for someone; as usual if you have any comments, questions, flames, enhancements I would love to hear from you. In the meantime think deeply and enjoy.

Taskbar Compass: how to use NotifyIcon in WPF

2009-03-12T09:31:00.001Z

There are a number of options available ranging from a CodePlex rewrite of the whole NotifyIcon control using the native WIN32 APIs to simply reusing the Windows Forms version of the control. I did not want to take a dependency on code that I did not have to, so in this case so I went with the Windows Forms version. It has all I need, and the implementation is really simple to boot.

This is the process I followed in my WPF app:

Create an Icon (I use Paint.NET with this plug-in to create icons)
Add the new icon to your project as a resource Windows Forms style .. not as a Resource build type but as EmbeddedResource (I tend to put icons in a folder with the name Resources and then use then use the Resources tab in the projects Properties).
In the App class, override the OnStartup method, and then create your NotifyIcon instance:

private System.Windows.Forms.NotifyIcon notify;
...

this.notify = new System.Windows.Forms.NotifyIcon();
this.notify.Text = "Taskbar Compass";
this.notify.Icon = PaulJ.TaskbarCompass.Properties.Resources.Compass;
this.notify.Visible = true;
this.notify.ContextMenu = new System.Windows.Forms.ContextMenu(new System.Windows.Forms.MenuItem[]
{
    new System.Windows.Forms.MenuItem("Show compass", (s, e) => this.MainWindow.Show()),
    new System.Windows.Forms.MenuItem("Hide compass", (s, e) => this.MainWindow.Hide()),
    new System.Windows.Forms.MenuItem("-"),
    new System.Windows.Forms.MenuItem("Close", (s, e) => this.Shutdown())
});

In the App class, over the OnExit method, and then dispose the NotifyIcon; otherwise the icon will hang around after the application is closed:

if (this.notify != null)
{
this.notify.Dispose();
}

And there you have it. I have updated the Taskbar Compass sample application (initially created in this post) to now include with a NotifyIcon, which you can download from here: TaskbarCompass.zip.

As usual if you have a comments, questions, flames, enhancements I would love to hear from you; in the meantime think deeply and enjoy.

The Taskbar Compass: how to use the SHAppBarMessage Windows API

2009-03-09T16:33:00.001Z

Over the last couple of weeks I’ve been writing production code in both Silverlight 2 and WPF; during that development I have had a need to provide a custom notify icon in WPF, to which I chose to the WinForms version as opposed to the myriad of versions available on Codeplex, but that’s a whole different post.

One issue that I came across was that I wanted my custom popup window to be positioned based on the location of the Windows Taskbar. There did not appear to be a WPF API to help there, so I resorted to the Win32 API and the SHAppBarMessage call:

[DllImport("shell32", CallingConvention = CallingConvention.StdCall)]
private static extern uint SHAppBarMessage(int dwMessage, ref APPBARDATA pData);

The APPBARDATA class is a simple struct that provides, amongst a few other things, the location of the Taskbar on the screen (left, top, right or bottom). By way of an example I’ve written a fun little application that I call the Taskbar Compass that points to the current position of the Taskbar.

The idea is that the red arrow points to where the Taskbar currently is. The application also listens for changes in user preferences and updates the compass if the Taskbar is moved. You can drag the window around as you would expect and a right mouse close will close it down. Take a look at a little movie I did to show the app in action:

<br/><a href="http://video.msn.com/video.aspx?vid=9be37e4c-6644-4961-a5f9-771e76cefe35" target="_new" title="Taskbar Compass">Video: Taskbar Compass</a>

You can download the sample application from here: TaskbarCompass.zip

As usual if you have a comments, questions, flames, enhancements I would love to hear from you; in the meantime think deeply and enjoy.

Synchronisation shock… you do not need Lock

2009-03-08T21:37:00.007Z

When you write code that must work in a concurrent environment you may have to synchronise access a resource. It is very common to use a semaphore for this need; .NET is no different, and provides the Monitor class specifically for this purpose. You use the Monitor class like so:

private static object SyncObject = new object();
...
Monitor.Enter(SyncObject);
try
{
    // thread sensitive code
}
finally
{
    Monitor.Exit(SyncObject);
}

This code enters in to a critical section of code by using the Monitor.Enter() method, passing in a static sync object on which all threads can block; creating a mechanism to synchronise access to a thread sensitive resource. Then, after the code has completed its work with the resource, in the finally block, it exits the critical section with a call to Monitor.Exit() handing in the same sync lock object.

This was considered a common scenario by the C# designer, so common in fact a special keyword for exists to facilitate this pattern of Monitor usage; the keyword is called lock, and the following code that uses the lock keyword is semantically the same as the code shown above:

private static object SyncObject = new object();
...
lock(SyncObject)
{
    // thread sensitive code
}

It is worth mentioning that the lock keyword does not actually do anything special; it simply emits the same code shown in the first code snippet in this post, by wrapping the use of the Monitor class in a try/finally guaranteeing that you exit the Monitor on exception.

While I would find it difficult to argue that this code is not simpler and cleaner than direct Monitor usage, I do assert that this is actually very rare scenario, and almost certainly not common enough to warrant a keyword all of its own! This may sound a little controversial but let me explain.

Consider for a moment that the vast majority of code that needs to be synchronised needs to also be atomic; therefore, if an exception is thrown during the execution of the code within the critical section you would not want your application to hobble on using potentially corrupt or broken data by blindly exiting the critical section. This would almost certainly put your application is an unstable state, creating intermittent and really tough to find and debug errors.

Now consider the scenario where you do not leave the critical section on error and simply report the exception and let the application hang the thread. Now you are in a situation that’s much easier to debug, as you’ll most likely be very near the call site where the error occurred, and your application is then not allowed to continue in an inconsistent state, which is a very good thing in my book.

Here’s a little sample code, showing what I think to be a more common scenario than that promoted by the use of the lock keyword:

private static object SyncObject = new object();
...
Monitor.Enter(SyncObject);
// thread sensitive code
Monitor.Exit(SyncObject);

Note this time there is no try/finally, so the code will stop on any unhandled exception (good thing). Obviously you can still wrap code of this nature in a try/catch, but then the normal rules of engagement come into play with regards to exception handling; it may even be appropriate to exit the critical section in the exception handler, and in that exception case you should probably use the lock keyword. However, I think that situation is rare; about as rare as actually handling a known exception, which of course you should only do when you can actually do something about it.

As usual if you have a comments, questions, flames, enhancements I would love to hear from you; but in the meantime happy multithreading, the future is concurrent and massively multithreaded, so think deeply and enjoy.

GL.NET Group Meeting … the code

2009-02-26T09:20:00.001Z

The first Gloucestershire .NET User Group meeting was a great success; a big thank you to all that came along, I hope you enjoyed the talks.

As promised here’s the image from my talk on Sockets in Silverlight 2:

The code is available for download here: SilverlightSockets.zip

The next meeting is scheduled for the 25th March, same place and time. If you have any questions or comments about the talk, Silverlight, WPF or you just have something to say then, as always, I’d love to hear from you.

GL.NET Group Meeting

2009-01-19T14:45:00.001Z

The first Gloucestershire .NET User Group meeting date and agenda has been set (well done Jimmy). There will be two presentations: What’s new in C# 4.0 by Guy Smith-Ferrier, and the second by me on Sockets in Silverlight 2. The idea for my presentation is to code up a simple Silverlight 2 socket based application in front of your very eyes, Quick Start Guide style.

It should be a fun evening; would be great to see you there.

MIX09 10K Smart Coding Challenge

2009-01-09T08:57:00.001Z

Update: Sadly all good things must come to an end; the MIX09 event is now over; I do not know how long they’ll keep the 10K completion pages alive for so I have uploaded my entry to the Silverlight Streaming Service (which is awesome BTW) and provides a simple page to host my entry: http://code.compilewith.net/pj.fviz.html

–PJ

My entry for the 10K coding challenge has been accepted, let the voting begin.

The basic premise for my idea is to visualize RSS or ATOM feeds. I don’t know about you but I have loads of feeds in my RSS reader and I come in to contact with countless others during my day; sometimes I just want a quick fingerprint of what the feed looks like, a snapshot of what they talk about, how often they post over what time frame etc. etc.

To that end the Visualizer was born:

Above is a screenshot of the application, showing three feeds: this blog, Derek’s Cloudstore and the feed for Scott Hanselman’s site. The following is the help for the application that describes each element within the UI:

Also, I’d like to point out the crux of the challenge: this has to all be achieved in 10K or less of source code. Source code includes all .cs and .xaml files as well as any resources and/or images used; a challenge indeed.

I would really appreciate it if you would take the time and pop on over to my entry and vote… I’m not asking for 5 stars or anything (although that would be nice :o), I’m just after your vote. As always if you have any other comments or suggestions please let me know.

ScrollViewer customization – Part 2

2009-01-02T15:29:00.001Z

Carrying on from my previous post, I’ve added a little more functionality to the CyclicScrollViewer control. I have added code to handle horizontal scrolling and included an attached property for turning off the cyclic behaviour, making the control behave similar to a standard ScrollViewer . I have also created a sample application to show all these new features:

For the top two ListBoxes cyclic scrolling is enabled; so, if you click and hold the ScrollBar buttons the list goes around and around as you would expect. However, for the bottom ListBox the CyclicScrollViewer is in use, but the CanContentCycle attached property has been set to False (the default is True).

Here’s the code for the attached dependency property:

public static readonly DependencyProperty CanContentCycleProperty =
    DependencyProperty.RegisterAttached(
        "CanContentCycle",
        typeof(bool),
        typeof(CyclicScrollViewer),
        new FrameworkPropertyMetadata(true) { Inherits = true });

The reason I wanted to show this code is that there is a gotcha when working with attached properties in this way: by that I mean when you apply them to parent containers as opposed to child objects (you apply a DockPanel’s attach properties to the elements it contains, as opposed to the containing element). In our case, we’re contained rather that containing. Anyway, ensure you replace the property metadata, by using a FrameworkPropertyMetadata instance, and set the Inherits to true; otherwise all you’ll see at runtime is the default value, no matter what you’d applied it in the code. Here’s how to use the property:

What you may notice if you download the sample application is that we’re still missing one key feature… keyboard support. Currently items only cycle if you use your mouse on the ScrollBar buttons, so that’s the next feature.

Update: Here's an XBAP version of the sample application for your viewing pleasure.

ScrollViewer customization

2009-01-02T09:47:00.001Z

Another StackOverflow question; this time about making a ListBox cycle its contents when scrolling. The question:

WPF ListBox: Can you make it cycle? i.e. not hit hard stops at top and bottom

Seems like a pretty simple request: make a circular list, i.e. when you roll off the end of the list start from the beginning again (or end depending on which direction you scrolled in). After a quick examination of the control template for a ListBox I figured that a good solution might be to try and work with the ScrollViewer control, and see if I could get that to cycle... then I could simply replace the ScrollViewer instance in the control template for the ListBox, job done!

So that's what I did:

public class CyclicScrollViewer : ScrollViewer
{
    public CyclicScrollViewer()
    {
      this.CommandBindings.Add(new CommandBinding(ScrollBar.LineUpCommand, LineCommandExecuted));
      this.CommandBindings.Add(new CommandBinding(ScrollBar.LineDownCommand, LineCommandExecuted));
    }

    private void LineCommandExecuted(object sender, ExecutedRoutedEventArgs e)
    {
      if (e.Command == ScrollBar.LineUpCommand)
      {
          if (this.VerticalOffset == 0)
              this.ScrollToEnd();
          else
              this.LineUp();
      }

      if (e.Command == ScrollBar.LineDownCommand)
      {
          if (this.VerticalOffset == this.ScrollableHeight)
              this.ScrollToTop();
          else
              this.LineDown();
      }
   }
}

This code simply installs event handlers for the LineUpCommand and LineDownCommand commands dispatched by the vertical ScrollBar in the control template for the ScrollViewer. Which, by the way, is a seriously fabulous way for this control to behave. In the event handler I examine incoming command type, then dispatch to the LineUp or LineDown methods as appropriate. However, before that I do a check to see if the control is already fully scrolled to either the top or the bottom of the viewer, and then, depending on the command, call either ScrollToEnd or ScrollToTop to loop the ScrollViewer - all the methods used, and more, already exist on the ScrollViewer, making the coding a very simple affair.

I've uploaded a sample application that uses the new ScrollViewer here:

PaulJ.CyclicListBox.zip

This sample is clearly incomplete; it only handles vertical scrolling. However, you can see how it could be extended to handle horizontal scrolling too. In fact, I intend to hack on this a little more in the coming weeks and try and create a complete working control... unless another question catches my eye in the meantime ;)

I may also look into providing a Silverlight version, but that'll largely depend on the comments get back from this post, so let me know if you think that'll be a good idea.

As always, comments and suggestions very welcome.

WPF - FlagsEnumValueConverter

2008-12-23T10:15:00.001Z

I feel a trend starting… another http://stackoverflow.com/ answer, here’s the question (massively snipped):

I have a nearly functional example of two-way binding a checkbox to an individual bit of a flags enumeration… The problem though is that the binding behaves as if it is one way (UI to DataContext, not vice versa). So effectively the check box does not initialize, but if it is toggled the data source is correctly updated…

Here’s the full link to the post for more context, if required.

The bottom line is that a solution to binding to “bit” flags can be challenging, but the solution initially offered in the question was extremely complex (class with a bunch of Attached Properties yadda, yadda, yadda), when I looked at it thought, I thought "surely that can be done with a value converter”; after a little bit of hacking I have a simple IValueConverter implementation for any flags enumeration.

But first, consider the following Enum definition:

[Flags]
public enum Department
{
    None = 0,
    A = 1,
    B = 2,
    C = 4,
    D = 8
}

My first step was to create a specific converter for the Department Enum:

public class DepartmentValueConverter : IValueConverter
{
private Department target;

    public DepartmentValueConverter()
    {
    }

    public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
    {
        Department mask = (Department)parameter;
        this.target = (Department)value;
        return ((mask & this.target) != 0);
    }

    public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)
    {
        this.target ^= (Department)parameter;
        return this.target;
    }
}

The tricky part, according to the initial question, was the ConvertBack implementation. The solution here is to simply store the incoming value in the Convert method, and when the value is changed the ConvertBack method uses the Exclusive-Or assignment operator to toggle the bit, which works lovely.

However, I also figured that it should be possible to create a generic version of this converter – this type of converter is not something that you’d be creating everyday, so to have a specific version for each Flags Enum would probably be a totally acceptable solution… but… this is what I came up with:

public class FlagsEnumValueConverter : IValueConverter
{
private int targetValue;

    public FlagsEnumValueConverter()
    {
    }

    public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
    {
        int mask = (int)parameter;
        this.targetValue = (int)value;
        return ((mask & this.targetValue) != 0);
    }

    public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)
    {
        this.targetValue ^= (int)parameter;
        return Enum.Parse(targetType, this.targetValue.ToString());
    }
}

So the key to this solution is that it works with the underlying type for most Enum values: Int32. The basic pattern is the same, but it simply replaces the specific Enum value with an Int32; with the only tricky part being in the ConvertBack: When I simply returned an Int32, when an Enum value was expected, WPF did not update the underlying value in the binding. I found I had to convert the Int32 to the specific Enum value represented by the Int32; which I simply handled by using the Enum.Parse method.

The following screenshot then shows how to consume the converter in XAML. Note that the mask value for the Enum value instance is passed in the CommandParameter property on the binding declaration.

I have uploaded a sample application here:

PaulJ.FlagsValueConverter.zip

Here’s a screenshot of the app, for what it’s worth given its simplicity :)

Comments and questions welcome as always.

Constrained StackPanel

2008-12-18T16:48:00.001Z

I’ve been spending a little time today over on stackoverflow.com and just answered a question about constraining the width of a StackPanel, and I thought I’d share my solution here too.

The question in its entirety was:

How can I constrain a vertical WPF StackPanel's width to the most narrow item it contains. The StackPanel's width must not be greater than the width of any other child element.

My initial thought to try and use a simple IValueConverter implementation; hand the in the child collection at the right time and bingo! constrain the size of the panel. However, that proved to be a little problematic as due to timing and data binding issues. One answer already suggested was to create a custom panel (which had no up votes for some reason – go figure); which would have been my next choice after the converter.

So I set about knocking up a ConstrainedStackPanel, which looks something like this:

public class ConstrainedStackPanel : StackPanel
{
    public ConstrainedStackPanel()
    {
    }

    protected override Size MeasureOverride(Size constraint)
    {
        foreach (var item in this.Children)
        {
            FrameworkElement element = item as FrameworkElement;
            if (element != null)
                constraint.Width = Math.Min(element.Width, constraint.Width);
        }

        return base.MeasureOverride(constraint);
    }

    protected override Size ArrangeOverride(Size arrangeSize)
    {
        foreach (var item in this.Children)
        {
            FrameworkElement element = item as FrameworkElement;
            if (element != null)
                arrangeSize.Width = Math.Min(element.Width, arrangeSize.Width);
        }

        return base.ArrangeOverride(arrangeSize);
    }
}

Here I’m simply enumerating the child collection at the right time, being a good WPF citizen and overriding both Measure and Arrange to get the desired effect, by keeping the smallest Width value at all times during the two stage rendering process. To consume the new panel in XAML, simply use it like any other StackPanel, as shown here:

<l:ConstrainedStackPanel x:Name="panelB">
    <Button Width="100" Content="100" />
    <Button Width="200" Content="200" />
    <Button Width="300" Content="300" />
    <Button Width="400" Content="400" />
</l:ConstrainedStackPanel>

When compared with a regular StackPanel the results look like the following screenshot:

And there you have it. In terms of requirements for a custom panel they don’t get much simpler than that, so it was a pretty straight-forward solution, but I hope it helps someone.

To follow the progress of the question and to see what other people come up with here’s a full link to the question: http://stackoverflow.com/questions/377523/constrain-stackpanels-width-to-smallest-child-element.

Comments and questions welcome as always.

Separated Presentation Patterns

2008-11-25T13:38:00.001Z

It is generally agreed amongst developers that a good clean separation between the visual elements of an application and the logic of an application is a good idea. To that end a number of patterns have emerged over the years:

and more recently:

Model View View-Model - sometimes incorrectly referred to as Presentation Model; they are similar but not the same. The MV-VM pattern is more WPF centric.

Over the years I have formed my own ideas as to when, why and where to apply these patterns, and it has been hard going, and to be quite frank, I've been a little inconsistent and vague at times; but recently I have formed more concrete ideas about when, why and where - especially when working with XAML (e.g. WPF and Silverlight) - which I have written down for others to throw stones at, here it is:

In time I plan to add code to illustrate these patterns - as I seem them - to provide more fodder for stone throwing; but in the process hopefully we'll all learn something.

Enjoy! I would love you know what you think and why.

More change notification for Dependency Properties

2008-11-24T17:01:00.001Z

In an earlier post I wrote a little on change notification in relation to dependency properties that you do not own, like those found on a TextBlock or Label. In that post I walked you though using a DependencyPropertyDescriptor, which in essence enables you to add an event handler to a ValueChanged event for any dependency property.

Here's a code example to help illustrate the approach:

DependencyPropertyDescriptor descriptor =
DependencyPropertyDescriptor.FromProperty
(UIElement.VisibilityProperty, typeof(UIElement));

descriptor.AddValueChanged
(this.labelShowHide, new EventHandler(VisibilityChanged));

The example code above creates a instance of a descriptor for the Visibility dependency property owned by the UIElement class, and then adds an event handler called VisibilityChanged. As I pointed out in the previous post there are two issues with this approach:

The event handler delegate is of type EventHandler and therefore only passes a simple EventArgs, losing the rich information provided by a typical dependency property change notification via the DependencyPropertyChangedEventArgs, which includes data such as the old and new values of the property.
The descriptor approach has a potential memory leak if you're not careful. This is because a reference to your event handler forever roots your class, in a Garbage Collector sense, because the reference is ultimately stored a static Hashtable.

I also think that there is a third, less concrete, issue with this approach: I don't like it. It just feels all wrong; hacking into the hooks provided for the tooling, which does all work fine, but it left me feeling a little dirty ;) There has to be a better way! And there is...

I discovered the proper way to do this kind of change notification a short while ago; however, this is the first opportunity I've had to write up - primarily for me to remember it in the future. The answer is actually quite simple, and related to the approach you would take extending an existing control by using inheritance... a Metadata override!

UIElement.OpacityProperty.OverrideMetadata(
    typeof(TextBlock),
    new FrameworkPropertyMetadata(
        1.0,
        FrameworkPropertyMetadataOptions.Inherits,
        new PropertyChangedCallback(DetailedPropertyChanged)));

The example code above replaces the property metadata for the Opacity dependency property for all TextBlock control instances in scope. The new metadata provides an event handler for change notification, and unlike the descriptor approach the callback is a true dependency property changed event handler:

private void DetailedPropertyChanged(
    DependencyObject d,
    DependencyPropertyChangedEventArgs e)
{
    Debug.WriteLine(string.Format(
        "{0}: old value was '{1}' and the new value is '{2}'",
        e.Property.Name,
        e.OldValue.ToString(),
        e.NewValue.ToString()));
}

Providing access to the old and new values, information about the source and the dependency property that has actually been changed. You now have all the information you could possibly need to handle the changed property; this approach has none of the drawbacks of the previous descriptor approach.

The only thing to be aware of when using this approach is that it impacts the overridden dependency property for all instances of the target type that are in scope; but you have a reference to the target object and property in the event handler, so this is easily coded for via a switch or if statement - it's just something to be aware of.

Here's a simple application that helps to illustrate the approach described here. If you have any comments or questions please leave a comment.

1.	Essential WPF by Chris Anderson Chris was one of the Architects on WPF and therefore provides a lot of insight into why things were done the way they were. This book gives you the essence of what WPF is all about.
2.	WPF Unleashed by Adam Nathan Adam is an excellent writer and this all colour book is a real "how to" book; a book on how to get things done by using WPF.
3.	Programming WPF by Chris Sells and Ian Griffiths This is the deep dive on WPF, the nuts and bolts, the nitty gritty of how things work. This is a great book that I constantly find myself going back to.