var interval = Observable.Interval(TimeSpan.FromMilliseconds(500)); interval.Subscribe(i => Console.WriteLine("First: {0}", i)); interval.Subscribe(i => Console.WriteLine("Second: {0}", i));

At first glance it might look like I’m setting up two listeners to a single interval pulse, but what’s actually happening is that each time I call Subscribe, I’ve created a new timer to tick values. Imagine how bad this could be if instead of an interval I was, say, sending a message across the network and waiting for a response.

There are a few ways to solve this problem, but only one of them is actually correct. The first thing most people latch on to in Intellisense is Publish(). Now that method looks useful. So I might try:

var interval = Observable.Interval(TimeSpan.FromMilliseconds(500)).Publish(); interval.Subscribe(i => Console.WriteLine("First: {0}", i)); interval.Subscribe(i => Console.WriteLine("Second: {0}", i));

Now I get nothing at all. Great advertising there.

So what is actually happening here? Well, for one you might notice that interval is no longer IObservable<long> but is now an IConnectableObservable<long>, which extends IObservable with a single method: IDisposable Connect().

As it turns out, Publish is simply a convenience method for Multicast that supplies the parameter for you. Specifically, calling stream.Publish() is exactly the same as calling stream.Multicast(new Subject<T>()). Wait, a subject?

What Multicast does is create a concrete implementation of IConnectableObservable<T> to wrap the subject we give it and forwards the Subscribe method of the IConnectableObservable<T> to Subject<T>.Subscribe, so it looks something like this:

You might have noticed that the input doesn’t go anywhere. That’s exactly why our simple call to Publish() earlier didn’t produce any results at all – IConnectableObservable<T> hadn’t been fully wired up yet. To do that, we need to make a call to Connect(), which will subscribe our input into our subject.

Connect() returns to us an IDisposable which we can use to cut off the input again. Keep in mind the downstream observers have no idea any of this is happening. When we disconnect, OnCompleted will not be fired.

Getting back to my example, the correct code looks like this:

var interval = Observable.Interval(TimeSpan.FromMilliseconds(500)).Publish(); interval.Subscribe(i => Console.WriteLine("First: {0}", i)); interval.Subscribe(i => Console.WriteLine("Second: {0}", i)); var connection = interval.Connect(); // Later connection.Dispose();

It is very important to make sure all of your subscribers are setup before you call Connect(). You can think of Publish (or, really, Multicast) like a valve on a pipe. You want to be sure you have all your pipes together and sealed before you open it up, otherwise you’ll have a mess.

A problem that comes up fairly often is what do you do when you do not control the number or timing of subscriptions? For instance, if I have a stream of USD/EUR market rates, there’s no need for me to keep that stream open if nobody is listening, but if someone is, I’d like to share that connection, rather than create a new one.

This is where RefCount() comes in. RefCount() takes an IConnectableObservable<T> and returns an IObservable<Tg>, but with a twist. When RefCount gets its first subscriber, it automatically calls Connect() for you and keeps the connection open as long as anyone is listening; once the last subscriber disconnects, it will call Dispose on its connection token.

So now you might be wondering why I didn’t use RefCount() in my so-called “correct” implementation. I wouldn’t have had to call either Connect() or Dispose, and less is more, right? All that is true, but it omits the cost of safety. Once I dispose my connection, my source no longer has an object reference to my object, which allows the GC to do what it does best. Often, these streams start to make their way outside of my class, which can create a long dependency chain of object references. That’s fine, but if I dispose an object in the middle, I want to make sure that that object is now ready for collection, and if I RefCount(), I simply can’t make that assertion, because I’d have to ensure every downstream subscriber had also disposed.

Another scenario that comes up is how to keep a record of things you’ve already received. For instance, I might make a call to find all tweets with the hashtag “#RxNet” with live updates. If I subscribe second observer, I might expect that all the previously found data to be sent again without making a new request to the server. Fortunately, we have Replay() for this. It literally has 15 overloads, which cover just about every permutation of windowing by count and/or time, and supplying an optional scheduler and/or selector. The parameterless call, however, just remembers everything. Replay is just like Publish in the sense that it also forwards a call to Multicast, but this time with a ReplaySubject<T>.

Now the temptation is to combine Replay() and RefCount to make caches of things for subscribers when they are needed. Lets look at my Twitter example.

tweetService.FindByHashTag("RxNet").Replay().RefCount()

When the first observer subscribes, FindByHashTag will make a call (I assume this is deferred) to the network and start streaming data, and all is well. When the second observer subscribes, he gets all the previously found data and updates. Great! Now, let’s say both unsubscribe and a third observer then subscribes. He’s going to get all that previous data, and then the deferred call in FindByHashTag is going to be re-triggered and provide results that we might have already received from the replay cache! Instead, we should implement a caching solution that actually does what we expect and wrap it in an Observable.Create, or if we expect only fresh tweets, use Publish().RefCount() instead.

I sat down to breakfast this morning with a couple guys I hadn’t met. Since Build Conference was an incorporation of both ISVs and IHVs, I greeted them with, “Software or hardware?” The man across the table told me he was involved with software, while the guy to my right ignored me entirely. Without quite playing 20 Questions, I found that the more vocal one was a client side developer in health care. He told me that he was very excited about the new Metro design and especially for the upcoming Windows 8 tablets. “Right now, everything is moving to Electronic Medical Records. So, when a doctor goes into see a patient, the first thing he does is turn his back on that patient and bring up the records on a desktop. A tablet is much more like the clipboards doctors used to use.” And, of course, Metro plays a huge role in the realization of that use case; a friendly, full-screen touch-accelerated app is intrinsic to the paradigm of a tablet. Not only that, but ease of access to peripherals, especially the webcam, make Windows Runtime (WinRT) a compelling API. As an added bonus, he pointed out that he could transition his current ASP.NET development stack and programmers much more easily to use either C# and XAML or even HTML5 and JavaScript to produce a Metro app than to use Coco and Objective-C to make an iPad app. Without a doubt, this is what Microsoft had envisioned.

At the opposite end of the spectrum, I met a couple developers that maintain an institutional client-facing application written in MFC. “There’s over three hundred screens in our application. No way can we fit that into Metro.” He went on further to explain that their application opens direct connections to a SQL Server instances located on both the client and server tiers. “I have to figure out how to go back and tell my boss that there’s just no way we can move over to Metro.”

I don’t know if he was aware or not of the seemingly obvious flaws in his app’s design, or that Microsoft was encouraging developers to forsake that all-too-familiar design of MFC apps that he showed me. “It’d be a complete rewrite;” that much we completely agreed upon.

There is a continuing consensus around the notion that WinRT is by far the most ambitious thing Microsoft has done in decades. Perhaps in a lot of ways, Windows XP is an apt analog of Win32 programming: it’s been around for so long, it’s in use in so many places, and it’s so well known, that it will take a very, very long time to unwind from it. Windows 8 and WinRT have enormous potential to revitalize the failing Windows desktop software market. All that remains to be seen is whether developers choose to capitalize upon it or cut their losses and move on.

To take some shavings off of the top top of the iceberg that is why I use Powershell, I’d like to share a recent experience of Powershell delivering for me.

Setup for Failure

As a co-orgranizer for the New York .NET Meetup I was tasked with getting the list of attendees off of meetup.com and over to the lovely people at Microsoft who kindly give us space to meet. Now, you might think there’d be some nifty “export attendee list to CSV” function the meetup.com website, but like a lot of software, it doesn’t do half the things you think it should and this is one of those things. Usually my colleague David assembles the list, but this particular month he was out on vacation. He did, however, point me over to a GitHub repository of a tool that would do the extraction.

Following his advice, I grabbed the repository and brought up the C#/WinForms solution in Visual Studio. Looking at the project structure, I was a bit stunned at the scale of it all. The author had divided his concerns very well into UI, data access, the core infrastructure, and, of course, unit testing. I thought that was pretty peculiar considering all I wanted to do was get a CSV of names and such off of a website. Far be it for me to criticize another developer’s fastidiousness. Maybe it also launched space shuttles; you never know.

In what I can only now describe as naivety, I hit F5 and expected something to happen.

I was rewarded with 76 errors.

Right off the bat, I realized that the author had botched a commit and forgot a bunch of libraries. I was able to find NHibernate fairly easily with Nuget, but had no luck with “Rhino.Commons.NHibernate”. I tried to remove the dependency problem, but didn’t have much luck. And the whole time I was wondering why the hell you needed all these libraries to extract a damn CSV from the internet.

The Problem

Rather than throw more time after the problem, I decided to forge out on my own. Really, how hard could it be to

1. Get an XML doc from the internet
2. Extract the useful data
3. Perform some heuristics on the names
4. Dump a CSV file

Being a long-time C# programmer, my knee-jerk reaction was to build a solution in that technology. Forgoing a GUI to spend as little time as possible in building this, I’d probably build a single file design that ostensibly could consist of a single method. And if that were the case, why not script it?

So if I was going to write a script, what to use? I could write a JavaScript and run it on node.js, but it’s lacking proper CSV utilities and I’d have to run it on something other than my main Windows box. Not to mention I don’t particularly writing in JavaScript, so I’d probably write it in CoffeeScript and have to compile it, etc, etc.

I briefly considered writing an F# script, but I suspect only about ten people would know what on earth it was, and, at the end of the day, I would like to share my script to others.

The Solution

In the end, I concluded what I had known already: Powershell was the tool to use. It had excellent support for dealing with XML (via accelerators) and, as a real scripting language, had no pomp and circumstance.

Here’s the script I ended up writing:

function Get-MeetupRsvps([string]$eventId, [string]$apiKey) {$nameWord = "[\w-']{2,}" $regex = "^(?'first'$nameWord) ((\w\.?|($nameWord )+) )?(?'last'$nameWord)|(?'last'$nameWord), ?(?'first'$nameWord)( \w\.|( $nameWord)+)?$" function Get-AttendeeInfo {process {$matches = $null $answer = $_.answers.answers_item if(-not ($_.name -match $regex)) { $answer -match $regex | Out-Null }return New-Object PSObject -Property @{ 'FirstName' = $matches.first 'LastName' = $matches.last 'RSVPName' = $_.name 'RSVPAnswer' = $answer 'RSVPGuests' = $_.guests }} }$xml = [Xml](New-Object Net.WebClient).DownloadString("https://api.meetup.com/rsvps.xml?event_id=$eventId`&key=$apiKey") $xml.SelectNodes('/results/items/item[response="yes"]') `| Get-AttendeeInfo `| select FirstName, LastName, RSVPName, RSVPAnswer, RSVPGuests }

To dump this to a CSV file is then really easy:

Get-MeetupRsvps -EventId 1234 -ApiKey 'MyApiKey' | Export-Csv -Path rsvps.csv -NoTypeInformation

And because of this design, it’s really extensible. Potentially, instead of exporting to a CSV, you could pipe the information into another processor that would remove anyone named “Thorsten.” Actually, that would look like this:

Get-MeetupRsvps -EventId 1234 -ApiKey 'MyApiKey' `| ? { %_.FirstName -ne 'Thorsten' } ` | Export-Csv -Path rsvps.csv -NoTypeInformation

It’d be pretty difficult to do that if I’d written a C# executable – you’d have to go into Excel to do that. Or write a Powershell script. Just saying.

Here’s the real kicker: I spent all of five minutes writing my Powershell script and then spent minutes tweaking my regex to identify as many names as possible. I didn’t need to recompile, just F5 again in Poweshell ISE, which you have installed already if you’re on Windows 7. Since I left the Export-Csv part off during debugging, I could just read the console output and see what I got.

When I was happy with my output, it was dead simple to distribute: throw it in a GitHub Gist and move on with my life. If you decide to use it, all you need is Powershell installed (again, are you on Windows 7?) and the ability to copy and paste. No libraries. No worries. If you don’t like my regex, it couldn’t be easier to figure out how to replace it. If you want more fields, it’s easy to see where they should be added.

It’s really just that easy.

Introducing the Streams Pattern

First we need to create a “stream provider”. The purpose of this class is to establish a single place that “owns” the stream. I like to use the stream provider to establish default values and behavior:

public static class StreamNames {private const string Prefix = "Streams_"; public const string Accounts = Prefix + "Accounts"; public const string SelectedAccount = Prefix + "SelectedAccount"; }// No need to export this type. An instance will be // shared between the two child exports. public class AccountStreamProvider {[ImportingConstructor] public AccountStreamProvider(IAccountService accountService) {// Defer the query for the list of accounts until the first subscription var publishedAccounts = Observable .Defer(() => Observable.Return(accountService.GetAccounts())) .Publish(); publishedAccounts.Connect(); Accounts = publishedAccounts; SelectedAccount = new ReplaySubject(1); // Take the first account and set it as the initially selected account. Accounts .Take(1) .Select(Enumerable.FirstOrDefault) .Subscribe(SelectedAccount.OnNext); }[Export(StreamNames.Accounts)] public IObservable<IEnumerable<Account>> Accounts { get; set; }[Export(StreamNames.SelectedAccount)] [Export(StreamNames.SelectedAccount, typeof(IObservable<Account>)] public ISubject<Account> SelectedAccount { get;set; }}

Already the benefits of RX over the EventAggregator are showing.

Now we just need to get a reference to our exports in a relevant view model:

public static class Extensions {public static void DisposeWith(this IDisposable source, CompositeDisposable disposables) {disposables.Add(source); }} [Export, PartCreationPolicty(CreationPolicy.NotShared)] public class AccountViewModel : BindableBase, IDisposable {private readonly Streams _streams; private readonly CompositeDisposable _disposables; [Export] public class Streams {[Import(StreamNames.Accounts)] public IObservable<IEnumerable<Account>> Accounts { get; set; }[Import(StreamNames.SelectedAccount)] public ISubject<Account> SelectedAccount { get; set; }} [ImportingConstructor] public AccountViewModel(Streams streams) {_streams = streams; _disposables = new CompositeDisposable(); _streams .Accounts .Subscribe(a => Accounts = a) .DisposeWith(_disposables); _streams .SelectedAccount .Subscribe(a => SelectedAccount = a) .DisposeWith(_disposables); }private IEnumerable<Account> _accounts; public IEnumerable<Account> Accounts {get { return _accounts; }private set { SetProperty(ref _accounts, value, "Accounts"); }} private Account _selectedAccount; public Account SelectedAccount {get { return _selectedAcccount; }private set { SetProperty(ref _selectedAccount, value, "SelectedAccount", OnSelectedAccountChanged); }} // This method is only called when _selectedAccount // actually changes, so there's no indirect recursion. private void OnSelectedAccountChanged() {_streams.SelectedAccount.OnNext(_selectedAccount); }public void Dispose() {_disposables.Dispose(); }}

By the way, I’m using BinableBase from my INPC template.

Introducing the Config Pattern

If you’ve been using RX for a while, you might have noticed that I forgot to put my setters on the dispatcher. Sure, I could rely on automatic dispatching to fix that problem, but if my queries got any more complicated It’d be better for me to take care of the dispatch myself.

Of course, the problem with ObserveOnDispatcher is that it makes testing a huge pain. Fortunately, we can use MEF to get around that problem, too.

public class AccountViewModel : BindableBase, IDisposable {private readonly Streams _streams; private readonly Config _config; private readonly CompositeDisposable _disposables; [Export] public class Streams {[Import(StreamNames.Accounts)] public IObservable<IEnumerable<Account>> Accounts { get; set; }[Import(StreamNames.SelectedAccount)] public ISubject<Account> SelectedAccount { get; set; }} [Export] public class Config {public virtual IScheduler DispatcherScheduler { get { return Scheduler.Dispatcher; } } }[ImportingConstructor] public AccountViewModel(Streams streams, Config config) {_streams = streams; _config = config; _disposables = new CompositeDisposable(); _streams .Accounts .ObserveOn(_config.DispatcherScheduler) .Subscribe(a => Accounts = a ).DisposeWith(_disposables); _streams .SelectedAccount .ObserveOn(_config.DispatcherScheduler) .Subscribe(a => SelectedAccount = a) .DisposeWith(_disposables); }// ... }

Since the DispatcherScheduler property is virtual, it’s easy to mock it out. Using Moq, all you need to do is:

Mock.Of<AccountViewModel.Config>(m => m.DispatcherScheduler == Scheduler.Immediate)

So one of the things that I’ve been missing in my BindableBase class is property coercion, a la dependency properties. It’s a pretty smart idea; you can keep values in a valid state without pushing change notification. Unfortunately, there are some problems that crop up pretty quickly in INotifyPropertyChanged based view models.

Consider a Foo property that refuses to set a value less than zero.

private int _foo; public int Foo {get { return _foo; }set {if(_foo >= 0) SetProperty(ref _foo, value, "Foo"); }}

That looks like pretty good coercion, but the problem is that your binding and your property are now out of sync. That is, the binding told your object to set a value and assumed it did; you gave it no notification to the contrary. So while your object retains the old value, the bound TextBox will blissfully report -23.

A more brute force option would raise PropertyChanged in the event of this kind of coercion, but that breaks the code contract for INotifyPropertyChanged in that nothing changed. So how do we get around this problem?

If you take a look at the invocation list of your PropertyChanged event with some bound variables, you’ll notice that there’s a PropertyChangedEventManager hooked up.

Considering that the other item in the list is my default delegate, this object must be responsible for communicating my events to the binding system

Of course, the next thing to do is fire up Reflector and take a look at what’s there.

public class PropertyChangedEventManager : WeakEventManager {// Fields private WeakEventManager.ListenerList _proposedAllListenersList; private static readonly string AllListenersKey; // Methods static PropertyChangedEventManager(); private PropertyChangedEventManager(); public static void AddListener(INotifyPropertyChanged source, IWeakEventListener listener, string propertyName); private void OnPropertyChanged(object sender, PropertyChangedEventArgs args); private void PrivateAddListener(INotifyPropertyChanged source, IWeakEventListener listener, string propertyName); private void PrivateRemoveListener(INotifyPropertyChanged source, IWeakEventListener listener, string propertyName); protected override bool Purge(object source, object data, bool purgeAll); public static void RemoveListener(INotifyPropertyChanged source, IWeakEventListener listener, string propertyName); protected override void StartListening(object source); protected override void StopListening(object source); // Properties private static PropertyChangedEventManager CurrentManager { get; }}

Basically, AddListener access the private CurrentManager singleton and subscribes the given listener to OnPropertyChanged. Fortunately for us, there’s a flaw in th the implementation of OnPropertyChanged. What it does is it gets the list of listeners based on the sender and raises their event with the given sender and args. The problem here is that it doesn’t verify that the object raising the event is actually the sender! That is to say, we should be able to send a fake PropertyChanged event through another object acting as a surrogate. All we need to do is add that object to the PropertyChangedEvenManager’s list and start impersonating.

To that end, I added this private class to BindableBase to lazily add the INotifyPropertyChanged proxy object to the PropertyChangedEventManager. Since we’re not actually interested in the events, I made a stub implementation of IWeakEventListener that returns false constantly to indicate it’s not handling the event. Finally, I hold onto both of these references to keep them from being garbage collected.

private class PropertyChangedEventManagerProxy {// We need to hold on to these refs to keep it from getting GC'd private readonly NotifyPropertyChangedProxy _notifyPropertyChangedProxy; private readonly IWeakEventListener _weakEventListener; private PropertyChangedEventManagerProxy() {_notifyPropertyChangedProxy = new NotifyPropertyChangedProxy(); _weakEventListener = new WeakListenerStub(); PropertyChangedEventManager.AddListener(_notifyPropertyChangedProxy, _weakEventListener, string.Empty); }public void RaisePropertyChanged(object sender, string propertyName) {_notifyPropertyChangedProxy.Raise(sender, new PropertyChangedEventArgs(propertyName)); }private static PropertyChangedEventManagerProxy _instance; public static PropertyChangedEventManagerProxy Instance { get { return _instance ?? (_instance = new PropertyChangedEventManagerProxy()); } } private class NotifyPropertyChangedProxy : INotifyPropertyChanged {public event PropertyChangedEventHandler PropertyChanged = delegate { }; public void Raise(object sender, PropertyChangedEventArgs e) {PropertyChanged(sender, e); }} private class WeakListenerStub : IWeakEventListener {public bool ReceiveWeakEvent(Type managerType, object sender, EventArgs e) { return false; }} }

The only thing left to do is add the coerce value function as an optional parameter on SetProperty and hook it up:

protected void SetProperty<T>( ref T backingStore, T value, string propertyName, Action onChanged = null, Action<T> onChanging = null, Func<T, T> coerceValue = null) {VerifyCallerIsProperty(propertyName); var effectiveValue = coerceValue != null ? coerceValue(value) : value; if (EqualityComparer<T>.Default.Equals(backingStore, effectiveValue)) {// If we coerced this value and the coerced value is not equal to the original, we need to // send a fake PropertyChanged event to notify WPF that this value isn't what it thinks it is. if (coerceValue != null && !EqualityComparer<T>.Default.Equals(value, effectiveValue)) PropertyChangedEventManagerProxy.Instance.RaisePropertyChanged(this, propertyName); return; }if (onChanging != null) onChanging(effectiveValue); OnPropertyChanging(propertyName); backingStore = effectiveValue; if (onChanged != null) onChanged(); OnPropertyChanged(propertyName); }

And there you have it. All the benefits of dependency property coercion, and the same short, sweet SetProperty syntax.

As before, everything is on GitHub so you can take a look at the whole thing and fork it if you see something to be improved.

I want to inform you all that you’re doing it wrong.

The Problem

Most projects choose to implement INotifyPropertyChanged instead of extending DependencyObject for the sole reason that dependency properties are an enormous pain to write. Having worked on a large project that used the latter approach, I’ve entirely sworn it off, and I don’t care what kind of tooling you say makes life better. It’s just too complicated. On top of that, it’s really difficult to subscribe to changes programmatically. Sure you can go through DependencyPropertyDescriptor and subscribe yourself, but that’s a hell of a lot harder than +=. So that leaves some people with properties that look like this:

private int _myValue; public int MyValue {get { return _myValue; }set { _myValue = value; OnPropertyChanged("MyValue"); }}

Not bad, perhaps. It just doesn’t do much. What about INotifyPropertyChanging? How do I do things internally when that property changes other than subscribing to my own PropertyChanged event?

These things could almost be overlooked. The real kicker is that this isn’t actually a proper implementation of INotifyPropertyChanged. According to MSDN, the PropertyChanged event is described as, “Occurs when a property value changes,” and this code will raise an event even if the value doesn’t. Their implementation looks like this:

private string customerNameValue = String.Empty; public string CustomerName {get {return this.customerNameValue; }set {if (value != this.customerNameValue) {this.customerNameValue = value; NotifyPropertyChanged("CustomerName"); }} }

Aside from their code style (or lack thereof), allow me to point out a few things. First – and foremost – they’re comparing string equality with operators, no mere venial sin in my book. Secondly, this puts the onus of figuring out how to compare two types on the property writer ad-hoc, rather than using something more intelligent. Finally, does anyone else think that 17 lines is a few too many for a dirt simple property? It’s crazy.

The Trouble with Lambda

Some very smart programmers I know like to have their NotifyPropertyChanged method take an Expression<Func<TProp>> so you can do something like:

private int _myValue; public int MyValue {get { return _myValue; }set { _myValue = value; NotifyPropertyChanged(() => MyValue); }}

They say it improves type checking and the ease of refactoring. But as it turns out, it’s god-awful for performance, which can run you into a lot of problems if you don’t keep track of even moderate update bursts.

I’d almost be willing to accept the performance trade-off if it weren’t for the fact that the only place that’s calling it is inside the property setter. When you’re refactoring, I don’t see it as too much effort to go ahead and fix the string in the underlying property setter while you’re there; you have to fix the backing member anyway.

Really what we need is lambdas for subscription. All those places out in your code that subscribe to PropertyChanged and then you check the property name with a string! That’s the real refactoring nightmare. What I want to do is myViewModel.SubscribeToPropertyChanged(vm => vm.Foo, OnFooChanged);

The implementation isn’t that complex at all:

public static IDisposable SubscribeToPropertyChanged<TSource, TProp>( this TSource source, Expression<Func<TSource, TProp>> propertySelector, Action onChanged) where TSource : INotifyPropertyChanged {if (source == null) throw new ArgumentNullException("source"); if (propertySelector == null) throw new ArgumentNullException("propertySelector"); if (onChanged == null) throw new ArgumentNullException("onChanged"); var subscribedPropertyName = GetPropertyName(propertySelector); PropertyChangedEventHandler handler = (s, e) => {if (string.Equals(e.PropertyName, subscribedPropertyName, StringComparison.InvariantCulture)) onChanged(); }; source.PropertyChanged += handler; return Disposable.Create(() => source.PropertyChanged -= handler); }public static IDisposable SubscribeToPropertyChanging<TSource, TProp>( this TSource source, Expression<Func<TSource, TProp>> propertySelector, Action onChanging) where TSource : INotifyPropertyChanging {if (source == null) throw new ArgumentNullException("source"); if (propertySelector == null) throw new ArgumentNullException("propertySelector"); if (onChanging == null) throw new ArgumentNullException("onChanged"); var subscribedPropertyName = GetPropertyName(propertySelector); PropertyChangingEventHandler handler = (s, e) => {if (string.Equals(e.PropertyName, subscribedPropertyName, StringComparison.InvariantCulture)) onChanging(); }; source.PropertyChanging += handler; return Disposable.Create(() => source.PropertyChanging -= handler); }private static string GetPropertyName<TSource, TProp>(Expression<Func<TSource, TProp>> propertySelector) {var memberExpr = propertySelector.Body as MemberExpression; if (memberExpr == null) throw new ArgumentException("must be a member accessor", "propertySelector"); var propertyInfo = memberExpr.Member as PropertyInfo; if (propertyInfo == null || propertyInfo.DeclaringType != typeof(TSource)) throw new ArgumentException("must yield a single property on the given object", "propertySelector"); return propertyInfo.Name; }

The Best Solution

This leaves me with a pretty explicit spec for implementing INotifyPropertyChanged:

1. It will take no more lines than a basic backing field setter.
2. It will raise INotifyPropertyChanged and INotifyPropertyChanging.
3. It will only raise the properties if the value has changed.
4. it will provide an easy way to have internal property changed subscriptions.
5. It will not use Lambdas to identify the property.

My solution allows you to do this:

private int _myValue; public int MyValue {get { return _myValue; }set { SetProperty(ref _myValue, value, OnMyValueChanged, OnMyValueChanging); }} private void OnMyValueChanged() { } private void OnMyValueChanging(int newValue) { }

Isn’t that nice? SetProperty looks like this:

protected void SetProperty( ref T backingStore, T value, string propertyName, Action onChanged = null, Action onChanging = null) {VerifyCallerIsProperty(propertyName); if (EqualityComparer<T>.Default.Equals(backingStore, value)) return; if (onChanging != null) onChanging(value); OnPropertyChanging(propertyName); backingStore = value; if (onChanged != null) onChanged(); OnPropertyChanged(propertyName); }[Conditional("DEBUG")] private void VerifyCallerIsProperty(string propertyName) {var stackTrace = new StackTrace(); var frame = stackTrace.GetFrames()[2]; var caller = frame.GetMethod(); if (!caller.Name.Equals("set_" + propertyName, StringComparison.InvariantCulture)) throw new InvalidOperationException( string.Format("Called SetProperty for {0} from {1}", propertyName, caller.Name)) }

The default parameters on SetProperty allow you to specify the changed callback or the changing callbacks in any permutation with the usual syntax and the stack trace analysis happens at debug time to make sure that the string you provide actually represents the property it’s being called from.

So how do we update dependent properties? The one thing you don’t want to do is ever have external property changing logic directly in your set method. It’s better to call out to a OnMyPropertyChanging event and have that method update your dependent method. The syntax is a little verbose, but it’s the most readable and extensible way to do it:

private int _foo; public int Foo {get { return _foo; }set { SetProperty(ref _foo, value, "Foo", OnFooChanged); }} private int _bar; public int Bar {get { return _bar; }set { SetProperty(ref _bar, value, "Bar", OnBarChanged); }} private int _foobar; public int Foobar {get { return _foobar; }private set { SetProperty(ref _foobar, value, "Foobar"); }} private void OnFooChanged() { UpdateFoobar(); }private void OnBarChanged() { UpdateFoobar(); }private void UpdateFoobar() { Foobar = _foo + _bar; }

In general you should never call OnProeprtyChanged; that decision is best left to the property and its underlying helper.

I hope this clears the water  for some people new to WPF and provides reasons for the veterans to change their tune. If you think I’m wrong, feel free to try and prove it to me in the comments section. After all, duty calls.

The source and XML documentation for all this and a few tests is on github.

Naturally, the first thing I did was to Google the answer. The first result looked pretty good so I implemented that:

<Application.Resources> <ResourceDictionary> <ResourceDictionary.MergedDictionaries> <ResourceDictionary Source="/PresentationFramework.Aero;V4.0.0.0;31bf3856ad364e35;component/themes/aero.normalcolor.xaml" /> </ResourceDictionary.MergedDictionaries> </ResourceDictionary> </Application.Resources>

This worked great up until I started styling things. Any time I created a style for one of the system controls, it’d change the underlying style back to the original system them, rather than the one I wanted. It turns out that naturally styles are based on the system theme, rather than implicit style (for reasons we’ll get into later). So the way to base a theme off of the implicit style is like this:

<Style x:Key="GreenButtonStyle" TargetType="Button" BasedOn="{StaticResource {x:Type Button}}"> <Setter Property="Background" Value="Green"/> <Setter Property="Foreground" Value="White"/> </Style>

Maybe a little inconvenient, but it gets the job done:

All was well up until I needed to make a new style based off of the default theme. Like many WPF applications, we had some default styles defined to give our controls a clean, consistent look. But in my particular case, I needed to make a whole new visual “branch,” using the default theme as the “trunk.” If I used my BasedOn workaround, I’d just get my implicit style; if I didn’t I’d get that nasty classic theme.

The more I thought about this, the more I realized that all of these problems were being caused by the fact that I was applying a system theme (aero.normalcolor) as a style on top of the actual system theme, rather than actually changing it. So I set off on a journey in Reflector to find out how WPF picks the current theme. This sounds hard, and it’s actually a lot harder than it sounds. After a dozen or so hours (spread out over a few weeks) and a some guidance by a blog that got really close (unfortunately, my link is now dead), I found out that however WPF calls a native method in uxtheme.dll to get the actual system theme, then stores the result in MS.Win32.UxThemeWrapper, an internal static class (of course). Furthermore, the properties on the class are read only (and also marked internal), so the best way to change it was by directly manipulating the private fields. My solution looks like this:

public partial class App : Application {public App() {SetTheme("aero", "normalcolor"); }/// <summary> /// Sets the WPF system theme. /// </summary> /// <param name="themeName">The name of the theme. (ie "aero")</param> /// <param name="themeColor">The name of the color. (ie "normalcolor")</param> public static void SetTheme(string themeName, string themeColor) {const BindingFlags staticNonPublic = BindingFlags.Static | BindingFlags.NonPublic; var presentationFrameworkAsm = Assembly.GetAssembly(typeof(Window)); var themeWrapper = presentationFrameworkAsm.GetType("MS.Win32.UxThemeWrapper"); var isActiveField = themeWrapper.GetField("_isActive", staticNonPublic); var themeColorField = themeWrapper.GetField("_themeColor", staticNonPublic); var themeNameField = themeWrapper.GetField("_themeName", staticNonPublic); // Set this to true so WPF doesn't default to classic. isActiveField.SetValue(null, true); themeColorField.SetValue(null, themeColor); themeNameField.SetValue(null, themeName); }}

I call the method in the App constructor so it sets the values after WPF does its detection, but before the system theme is loaded for rendering.

Here’s what I got back:

Success!

There’s still a couple downsides to this approach. First, I can’t change the theme whenever I want to, and secondly, if the user changes their Windows theme while the application is running, the theme I set gets wiped out.

Wait a minute. If Windows can change the application theme, I can too!

Poking around a little more, I found out that when WPF wants to find a system resource, it also calls System.Windows.SystemResources.EnsureResourceChangeListener() which makes sure there’s a listener attached to the Windows message pump, ready to interpret events like a theme change.

[SecurityCritical, SecurityTreatAsSafe] private static void EnsureResourceChangeListener() {if (_hwndNotify == null) {HwndWrapper wrapper = new HwndWrapper(0, -2013265920, 0, 0, 0, 0, 0, "SystemResourceNotifyWindow", IntPtr.Zero, null); _hwndNotify = new SecurityCriticalDataClass<HwndWrapper>(wrapper); _hwndNotify.Value.Dispatcher.ShutdownFinished += new EventHandler(SystemResources.OnShutdownFinished); _hwndNotifyHook = new HwndWrapperHook(SystemResources.SystemThemeFilterMessage); _hwndNotify.Value.AddHook(_hwndNotifyHook); }}

The handler looks like this:

[SecurityTreatAsSafe, SecurityCritical] private static IntPtr SystemThemeFilterMessage(IntPtr hwnd, int msg, IntPtr wParam, IntPtr lParam, ref bool handled) {WindowMessage message = (WindowMessage) msg; switch (message) {// abridged case WindowMessage.WM_THEMECHANGED: SystemColors.InvalidateCache(); SystemParameters.InvalidateCache(); OnThemeChanged(); InvalidateResources(false); break; }return IntPtr.Zero; }

So the plan was to remove the hook so the message pump couldn’t change the theme out from under me and then call the handler whenever I want. As it turns out, it’s even easier than that. Because the list of hooks is implemented with a WeakReferenceList, all I need to do is null out the private _hwndNotifyHook field. There’s just one problem here: killing the handler prevents us from receiving system notifications for the other messages like device changes, power updates, etc. So we really need to inject a filter into the pipeline and pass along everything except the ThemeChanged event.

Fair warning: if you get queasy around reflection, you should probably stop reading here.

public static class ThemeHelper {private const BindingFlags InstanceNonPublic = BindingFlags.Instance | BindingFlags.NonPublic; private const BindingFlags StaticNonPublic = BindingFlags.Static | BindingFlags.NonPublic; private const int ThemeChangedMessage = 0x31a; private static readonly MethodInfo FilteredSystemThemeFilterMessageMethod =typeof(ThemeHelper).GetMethod("FilteredSystemThemeFilterMessage", StaticNonPublic); private static readonly Assembly PresentationFramework =Assembly.GetAssembly(typeof(Window)); private static readonly Type ThemeWrapper =PresentationFramework.GetType("MS.Win32.UxThemeWrapper"); private static readonly FieldInfo ThemeWrapper_isActiveField =ThemeWrapper.GetField("_isActive", StaticNonPublic); private static readonly FieldInfo ThemeWrapper_themeColorField =ThemeWrapper.GetField("_themeColor", StaticNonPublic); private static readonly FieldInfo ThemeWrapper_themeNameField =ThemeWrapper.GetField("_themeName", StaticNonPublic); private static readonly Type SystemResources =PresentationFramework.GetType("System.Windows.SystemResources"); private static readonly FieldInfo SystemResources_hwndNotifyField =SystemResources.GetField("_hwndNotify", StaticNonPublic); private static readonly FieldInfo SystemResources_hwndNotifyHookField =SystemResources.GetField("_hwndNotifyHook", StaticNonPublic); private static readonly MethodInfo SystemResources_EnsureResourceChangeListener =SystemResources.GetMethod("EnsureResourceChangeListener", StaticNonPublic); private static readonly MethodInfo SystemResources_SystemThemeFilterMessageMethod =SystemResources.GetMethod("SystemThemeFilterMessage", StaticNonPublic); private static readonly Assembly WindowsBase =Assembly.GetAssembly(typeof(DependencyObject)); private static readonly Type HwndWrapperHook =WindowsBase.GetType("MS.Win32.HwndWrapperHook"); private static readonly Type HwndWrapper =WindowsBase.GetType("MS.Win32.HwndWrapper"); private static readonly MethodInfo HwndWrapper_AddHookMethod =HwndWrapper.GetMethod("AddHook"); private static readonly Type SecurityCriticalDataClass =WindowsBase.GetType("MS.Internal.SecurityCriticalDataClass`1") .MakeGenericType(HwndWrapper); private static readonly PropertyInfo SecurityCriticalDataClass_ValueProperty =SecurityCriticalDataClass.GetProperty("Value", InstanceNonPublic); /// <summary> /// Sets the WPF system theme. /// </summary> /// <param name="themeName">The name of the theme. (ie "aero")</param> /// <param name="themeColor">The name of the color. (ie "normalcolor")</param> public static void SetTheme(string themeName, string themeColor) {SetHwndNotifyHook(FilteredSystemThemeFilterMessageMethod); // Call the system message handler with ThemeChanged so it // will clear the theme dictionary caches. InvokeSystemThemeFilterMessage(IntPtr.Zero, ThemeChangedMessage, IntPtr.Zero, IntPtr.Zero, false); // Need this to make sure WPF doesn't default to classic. ThemeWrapper_isActiveField.SetValue(null, true); ThemeWrapper_themeColorField.SetValue(null, themeColor); ThemeWrapper_themeNameField.SetValue(null, themeName); }public static void Reset() {SetHwndNotifyHook(SystemResources_SystemThemeFilterMessageMethod); InvokeSystemThemeFilterMessage(IntPtr.Zero, ThemeChangedMessage, IntPtr.Zero, IntPtr.Zero, false); }private static void SetHwndNotifyHook(MethodInfo method) {var hookDelegate = Delegate.CreateDelegate(HwndWrapperHook, FilteredSystemThemeFilterMessageMethod); // Note that because the HwndwWrapper uses a WeakReference list, we don't need // to remove the old value. Simply killing the reference is good enough. SystemResources_hwndNotifyHookField.SetValue(null, hookDelegate); // Make sure _hwndNotify is set! SystemResources_EnsureResourceChangeListener.Invoke(null, null); // this does SystemResources._hwndNotify.Value.AddHook(hookDelegate) var hwndNotify = SystemResources_hwndNotifyField.GetValue(null); var hwndNotifyValue = SecurityCriticalDataClass_ValueProperty.GetValue(hwndNotify, null); HwndWrapper_AddHookMethod.Invoke(hwndNotifyValue, new object[] { hookDelegate }); }private static IntPtr InvokeSystemThemeFilterMessage(IntPtr hwnd, int msg, IntPtr wParam, IntPtr lParam, bool handled) {return (IntPtr)SystemResources_SystemThemeFilterMessageMethod.Invoke(null, new object[] { hwnd, msg, wParam, lParam, handled }); }private static IntPtr FilteredSystemThemeFilterMessage(IntPtr hwnd, int msg, IntPtr wParam, IntPtr lParam, ref bool handled) {if (msg == ThemeChangedMessage) return IntPtr.Zero; return InvokeSystemThemeFilterMessage(hwnd, msg, wParam, lParam, handled); }}

What a mess! What’s really annoying is that this entire process could have (and, I argue, should have) been made public to user code. In the very least, I’d like to be able to decorate my assembly with an attribute declaring which theme I’d like to run under, but I think it’s completely reasonable to have an public static class provide the same API I have here.

The whole test suite is available here on GitHub.

DM F#, Clojure, and Scala are all fairly new and popular languages this decade, the former two with striking resemblance to OCaml and Lisp, respectively, and the lattermost being more original in syntax. In what way do these languages represent forward thinking in language design, or how do they fail to build upon lessons learned in more venerable languages like Haskell?

KT It’s a common story in the world of software that time brings increasingly precise and accurate programs.  Anybody who grew up playing games on an Atari 2600 has witnessed this firsthand.  The image of a character has changed from one block, to five blocks, to fifty blocks, to (eventually) thousands of polygons.  By this modern analog of the Greeks’ method of exhaustion, Mario’s facial structure has become increasingly clear.  This inevitable progression, squeezed out between the increasing sophistication of programmers and the decreasing punishment of Moore’s Law, has primarily operated at three levels: the images produced by game programs, the logic of the game programs themselves, and finally the programming languages with which programs are produced.  It’s this last group that deserves special attention today.

The lambda calculus (and its myriad derivatives) exemplifies this progression at the level of programming languages.  In the broadest terms, you have the untyped lambda calculus at the least-defined end (which closely fits languages like Lisp, Scheme, Clojure, Ruby and Python), and the calculus of constructions at the most-defined end (which closely fits languages like Cayenne and Epigram).  With the least imposed structure, you can’t solve the halting problem, and with the most imposed structure you (trivially) can solve it.  With the language of the untyped lambda calculus, you get a blocky, imprecise image of what your program does, and in the calculus of constructions you get a crisp, precise image.

Languages like F#, Scala and Haskell each fall somewhere in between these two extremes.  None of them are precise enough to accept only halting programs (although Haskell is inching more and more toward a dependently-typed language every year).  Yet all of them are more precise than (say) Scheme, where fallible human convention alone determines whether or not the “+” function returns an integer or a chicken.  But even between these languages there is a gulf of expressiveness.  Where a language like C is monomorphically-typed (and an “int_list” must remain ever distinguished from a “char_list”), F# introduces principled polymorphic types (where, pun intended, you can have “’a list” for any type ‘a).  Beyond that, Haskell (and Scala) offer bounded polymorphism so that constraints can be imposed (or inferred) on any polymorphic type – you can correctly identify the “==” function as having type “Eq a => a -> a -> Bool” so that equality can be determined only on those types which have an equivalence relation, whereas F# has to make do with the imprecise claim that its “=” function can compare any types.

No modern programming language is perfect, but the problems that we face today and the history of our industry points the way toward ever more precise languages.  Logic, unreasonably effective in the field of computer science, has already set the ideal that we’re working toward.  Although today you might hear talk that referential transparency in functional languages makes a parallel map safe, tomorrow it will be that a type-level proof of associativity makes a parallel reduce safe.  Until then, it’s worth learning Haskell (or Scala if you must), where you can count the metaphorical fingers on Mario’s hands, though not yet the hairs of his moustache.

DM One might assume that increased “precision” in a language would come at the cost of increased complexity in concepts and/or syntax. In a research scenario, the ability to solve the halting problem certainly has its merits, but is that useful for modern commercial application development, and, if so, does it justify the steeper learning curve?

KT It’s absolutely true that languages that can express concepts more precisely also impose a burden on programmers, and that a major part of work in language design goes into making that burden as light as possible (hence type-inference, auto roll/unroll for recursive types, pack/unpack for existential types, etc).

However — to your point about the value of that increased precision – I would argue that it’s even more important in commercial application development than in academia.  For example, say you’ve just rolled out a new pricing server for a major client.  Does it halt?  There’s a lot more riding on that answer than you’re likely to find in academia.  And really, whether or not it halts is just one of the simplest questions you can ask.  What are its time/space characteristics?  Can it safely be run in parallel?  Is it monotonic?  In our business, these questions translate into dollars and reputation.  Frankly I think it’s amazing that we’ve managed to go on this long without formal verification.

DM Most dynamic languages have some air of functional programming to them, while still being fundamentally imperative. Even more rigorous imperative languages like C# are picking up on a more functional style of programming. The two languages you mentioned earlier, Cayenne and Epigram, are both functional languages. Are we moving toward a pure functional paradigm, or will there continue to be a need for imperative/functional hybrids?

KT What is a “functional language”?  If it’s a language with first-class functions, then C is a functional language.  If it’s a language that disallows hidden side-effects, then Haskell isn’t a functional language.  I think that, at least as far as discussing the design and development of programming languages is concerned, it’s well worth getting past that sort of “sales pitch”.

I believe that we’re moving toward programming languages that allow programmers to be increasingly precise about what their programs are supposed to do, up to the level of detail necessary.  The great thing about referential transparency is that it makes it very easy to reason about what a function does — it’s almost as easy as high school algebra.  However, if you’re not engaged in computational geometry, but rather need to transfer some files via FTP, there’s just no way around it.  You’ve got to do this, then this, then this, and you’ll need to switch to something more complicated, like Hoare logic, to reason about what your program is doing.  Even there, you have plenty of opportunity for precision — you expect to use hidden side-effects but only of a certain type (transfer files but don’t launch missiles).

But maybe the most important tool in programming is logic itself.  It’s a fundamental fact – well known in some circles as the “Curry-Howard isomorphism” – that programs and proofs are equivalent in a very subtle and profound way.  This fact has produced great wealth for CS researchers, who can take the results painstakingly derived by logicians 100 years ago and (almost mechanically) publish an outline of their computational analog.  Yet, although this amazing synthesis has taken place rivaling the unification of electricity and magnetism, most programmers in industry are scarcely aware of it.  It’s going to take some time.

I think there’s a good answer to your question in that correspondence between logic and programming.  The function, or “implication connective” (aka “->”), is an important tool and ought to feature in any modern language.  As well, there are other logical connectives that should be examined.  For example, conjunction is common (manifested as pair, tuple, or record types in a programming language), but disjunction (corresponding to variant types) is less common though no less important.  Negation (corresponding to continuations consuming the negated type), predicated quantified types, and so on.  The tools for building better software are there, but we need to work at recognizing them and putting them to good use.

Anybody interested in understanding these logical tools better should pick up a copy of Benjamin Pierce’s book Types and Programming Languages.

DM Many frameworks have a one or more DSLs to express things as mundane as configuration to tasks as complicated as UI layout, in an effort to be more express specific kinds of ideas more concisely. Do you see this as an expanding part of the strategy for language designers to increase expressiveness in code? Is it possible that what we consider “general purpose languages” today will become more focused on marshalling data from one DSL to another, or will DSLs continue to remain a more niche tool?

KT I guess it depends on what you mean by “DSL”.  Like you say, some people just have in mind some convenient shorthand serialization for data structures (I’ve heard some people refer to a text format for orders as a DSL, for example).  I’m sure that will always be around, and there’s nothing really profound about it.

On the other hand, by “DSL” you could mean some sub-Turing language with non-trivial semantics.  For example, context-free grammars or makefiles.  Modern programming languages, like Haskell, are often used to embed these “sub-languages” as combinator libraries (the “Composing Contracts” paper by Simon Peyton-Jones et al is a good example of this).  I think it’s likely that these will continue as valuable niche tools.  If you take monadic parser combinators for example, it’s very attractive the way that they fit together within the normal semantics of Haskell, however you’ve got to go through some severe mental gymnastics to determine for certain what the space/time characteristics of a given parser will be.  Contrast that with good old LALR(1) parsers, where if the LR table can be derived you know for certain what the space/time characteristics of your parser will be.

On the third hand, if a “DSL” is a data structure with semantics of any kind, your description of a future where programs are written as transformations between DSLs could reasonably describe the way that compilers are written today.  Generally a compiler is just a sequence of semantics-preserving transformations between data structures (up to assembly statements).  I happen to think that’s a great way to write software, so I hope it’s the case that it will become ever more successful.

• Level 0: 1 year
• Level 1: 2-5 years
• Level 2: 6-9 years
• Level 3: 10+ years

To be perfectly honest, I find the entire idea reprehensible. According to this matrix, nobody could be considered an “expert” programmer in C#, since the language has only been around since 2001. I’m not breaking the news to Anders. Ok, maybe that’s a bit of a “gotcha” exception, but I think the entire idea can’t hold water. The problem with the assertion is that it assumes that all years are equal in quality. There’s no comparison between a year in a challenging company on the cutting edge of your technology field working with the leaders in industry and a year making small changes to an enterprise CMS. No offense to the latter group, but it’s just the ugly truth.

What really bothers me is that this kind of fallacy isn’t limited to a few people, but, as I’m sure we all know, almost every employer has some kind of experience requirement in strict years. In fact, one employer I was looking at after graduation actually wanted candidates to have experience with C# since day 1, according to the advertisement. We, as an industry, have got to dispel the myth of causation (and even really correlation) between years experience and skill in development. Basing our recruitment standards on this primitive metric only encourages age-warfare, not unlike a number of discussions I’ve seen on Slashdot, with the younger programmers calling older ones “set in their ways,” and the older programmers calling younger guys “re-creators of the wheel in their inexperience.” It’s got to stop. We have to gather together and celebrate knowledge in our field and, in turn, work to better everyone in our technical community.

This is what I think makes Lab49 recruitment so effective: we don’t predicate someone’s candidacy on experience. Don’t have a degree in computer science or software engineering? Doesn’t matter. Don’t have ten years experience in software? So what? What matters is that you are skilled in your technology, be it C#, Flex, Java, or C++, and you’re someone who works well on a team. When you think about it, this is just good business. Who cares about someone’s pedigree? We’re in the business of creating effective software solutions, not showing off our employees’ education and past merits.

I think moving beyond simply removing the years experience criterion, résumés are becoming more and more deprecated. It’s not because people don’t have significant accomplishments that are noteworthy, but rather that people use ambiguous language, and even outright lies on their résumés in a desperate attempt to be hired for a job for which they’re not qualified, and for every gem in a stack of résumés, there’s a lot of rocks. This is where the community steps in. People involved in their local technology meet ups and people involved in online communities like StackOverflow show their skill on a regular basis, and it’s much harder to BS someone, especially if they start asking questions.

Over the next few years I suspect we’ll start seeing a paradigm shift in the way employers find talent. I won’t prognosticate that StackOverflow and its careers division will be the future, but I’m willing to be it’s going to have a hand in it, at least. The change in talent-hunting strategy, I think, is just one facet of a larger shift in our industry towards building communities. It’s already underway, so all we have to do now is embrace the change and jump in.

Since a color can be thought of as a three-tuple of its R, G, and B channels, the formula is easily distributed to each of these values.

At this point, I decided I could probably just pull out a calculator and crunch the numbers. But maybe, in about the same time, I could also whip something together, say in PowerShell, to do it for me. Since I’m still learning PowerShell, I figured the learning experience would be worth at least something.

So the first thing I needed was the ability to parse an ARGB hex code into a hashtable with each channel separated out. Here’s what I got.

function Blend-Colors ([string[]] $colors) {# $argbHexColorRegex should recognize all 4-byte hex color strings prefixed with a '#' # and assign them to groups named a, r, g, and b for each channel, respectively. $argbHexColorRegex = "(?i)^#(?'a'[0-9A-F]{2})(?'r'[0-9A-F]{2})(?'g'[0-9A-F]{2})(?'b'[0-9A-F]{2})$" foreach($colorHex in $colors) {if($colorHex -match $argbHexColorRegex) {$color = @{ a = [int]::Parse($matches.a, 'AllowHexSpecifier') r = [int]::Parse($matches.r, 'AllowHexSpecifier'); g = [int]::Parse($matches.g, 'AllowHexSpecifier'); b = [int]::Parse($matches.b, 'AllowHexSpecifier'); }$color | ft } else {throw "Invalid color: $colorHex" }} }

Ok, not too shabby. If you’re wondering where $matches came from, as a side effect of the -match operation, the $matches hashtable is set with all the matched groups defined. I just prefer to use the object syntax in this case over the index syntax.

So, I’m not real happy with the amount of repetition going on in the assignment of my hashtable. My first attempt to clean it up looked like this:

$color = ('a','r','g','b') | % { @{ $_ = [int]::Parse($matches.$_, 'AllowHexSpecifier') } }

But that just gave me an array of hashtables with one attribute in each. I asked Doug Finke what he thought and he recommended this modification:

('a','r','g','b') | % { $color = @{} } { $color.$_ = [int]::Parse($matches.$_, 'AllowHexSpecifier') }

Cool! It seems a little obvious now, though.

Next on the agenda was to translate the blending equation into PowerShell. Since the equation is a little more involved, I decided to abstract it out into a subfunction like so:

function Merge-Channel ($c0, $c1, $c) {$a0 = $c0.a / 255 $a1 = $c1.a / 255 return $a0 * $c0.$c + $a1 * $c1.$c * (1 - $a0) }

$c0 and $c1 are color hashtables and $c is the name of the channel to blend. I had to divide the alpha channels by 255 to produce a value compatible with the equation, namely, between 0 and 1.

The reason I chose to accept the entire color and desired channel, rather than a more terse definition accepting the specific channel values and related alpha values was to make calling the code a little more elegant:

('r','g','b') | % `{ $mergeColor = @{ a = [Math]::Min(255, $outColor.a + $addColor.a) } } `{ $mergeColor.$_ = Merge-Channel $addColor $outColor $_ }

When blending, the alpha channels simply sum, so I put that in my hashtable initializer and just iterated over the color channels.

Now the final step is to return our value back in hex form. Fortunately, the formatting styles for int make this really easy:

return '#{0:x2}{1:x2}{2:x2}{3:x2}' -f (('a','r','g','b') | % { [int][Math]::Round($baseColor.$_, 0) })

I’m rounding to ensure the highest accuracy to the blended color, as opposed to simply truncating.

Putting it all together, I decided to create two array constants, $argb and $rgb to alias arrays of the channels. While I was at it, I also promoted my $argbHexColorRegex to a constant just for good measure. Finally, I made the base color white, so there would be something to blend against. The result looks like this:

function Blend-Colors ([Parameter(Mandatory=$true)] [string[]] $colors) {# $argbHexColorRegex should recognize all 4-byte hex color strings prefixed with a '#' # and assign them to groups named a, r, g, and b for each channel, respectively. Set-Variable argbHexColorRegex -Option Constant `-Value "(?i)^#(?'a'[0-9A-F]{2})(?'r'[0-9A-F]{2})(?'g'[0-9A-F]{2})(?'b'[0-9A-F]{2})$" Set-Variable argb -Option Constant -Value 'a','r','g','b' Set-Variable rgb -Option Constant -Value 'r','g','b' function Merge-Channel ($c0, $c1, $c) {$a0 = $c0.a / 255 $a1 = $c1.a / 255 return $a0 * $c0.$c + $a1 * $c1.$c * (1 - $a0) }$argb | % { $outColor = @{} } { $outColor.$_ = 255 } # set $outColor to white (#FFFFFFFF) foreach($color in $colors) {if(-not ($color -match $argbHexColorRegex)) {throw "Invalid color: $color" }$argb | % { $addColor = @{} } { $addColor.$_ =  [int]::Parse($matches.$_, 'AllowHexSpecifier') }$rgb | % `{ $mergeColor = @{ a = [Math]::Min(255, $outColor.a + $addColor.a) } } `{ $mergeColor.$_ = Merge-Channel $addColor $outColor $_ }$outColor = $mergeColor }return '#{0:x2}{1:x2}{2:x2}{3:x2}' -f ($argb | % { [int][Math]::Round($outColor.$_, 0) }) }

This is looking really good, and, really, I might have just stopped here. The only things I was missing at this point were pipelining and documentation, and since my solution had become completely over-engineered as it was, I decided I might as well go for broke.

The first thing I wanted to do was abstract out my initialization of $outColor to a parameter. Since I’d have to parse the string, I’d also need to abstract my color hex parser.

function Parse-Color ([string] $hex) {if($hex -match $argbHexColorRegex) {$argb | % { $color = @{} } { $color.$_ =  [int]::Parse($matches.$_, 'AllowHexSpecifier') }return $color; } else {return $null; }}

The reason I decided to return null instead of throwing an error immediately is because I wanted to treat errors differently in both places. Specifically, if an invalid string is passed in to the -background, I want to throw an argument exception, and if something invalid comes in over the pipeline, I just want to write the error to the error output and keep on trucking.

I tried a few different approaches to being able to both accept input over the parameter list and I finally found out about [Parameter(ValueFromPipeline=$true)]. Here is my test setup:

function Get-Range([int]$max) {for($i=0; $i -lt $max; $i++) {Write-Host "pushing $i to pipeline" Write-Output $i }} function Test-Pipeline([Parameter(ValueFromPipeline=$true)][int[]]$vals = $null) {process {foreach($item in @($vals)){ Write-Host "processing $item from pipeline" }} }

And my test output:

> Get-Range 3 | Test-Pipeline pushing 0 to pipeline processing 0 from pipeline pushing 1 to pipeline processing 1 from pipeline pushing 2 to pipeline > Test-Pipeline ('1','2','3') processing 1 from pipeline processing 2 from pipeline processing 3 from pipeline

Notice the @($vals) in my foreach? That’s to protect against null inputs by ensuring $vals is a list.

Now that I’ve got all my pieces together, I just need to put everything in place with a splash of documentation.

<# .SYNOPSIS Takes a list of ARGB hex values and blends them in order against a specified background. .PARAMETER background The background color to blend against, defaults to white. .PARAMETER colors A list of ARGB hex color strings, can be pushed from the pipeline. .EXAMPLE Blend-Colors '#ff121212', '#705F6A87' .LINK http://en.wikipedia.org/wiki/Alpha_compositing #> function Blend-Colors ([string] $background = '#FFFFFFFF', [Parameter(ValueFromPipeline = $true)] [string[]] $colors = $null) {begin {# $argbHexColorRegex should recognize all 4-byte hex color strings prefixed with a '#' # and assign them to groups named a, r, g, and b for each channel, respectively. Set-Variable argbHexColorRegex -Option Constant `-Value "(?i)^#(?'a'[0-9A-F]{2})(?'r'[0-9A-F]{2})(?'g'[0-9A-F]{2})(?'b'[0-9A-F]{2})$" Set-Variable argb -Option Constant -Value 'a','r','g','b' Set-Variable rgb -Option Constant -Value 'r','g','b' function Parse-Color ([string] $hex) {if($hex -match $argbHexColorRegex) {$argb | % { $color = @{} } { $color.$_ =  [int]::Parse($matches.$_, 'AllowHexSpecifier') }return $color; } else {return $null; }} function Merge-Channel ($c0, $c1, $c) {$a0 = $c0.a / 255 $a1 = $c1.a / 255 return $a0 * $c0.$c + $a1 * $c1.$c * (1 - $a0) }$outColor = Parse-Color $background if(-not $outColor) {throw (New-Object ArgumentException -ArgumentList "Invalid color: '$background'", 'background') }} process {foreach($color in @($colors)){ $addColor = Parse-Color $color if(-not $addColor) {Write-Error "Invalid input color: $_" break }$rgb | % `{ $mergeColor = @{ a = [Math]::Min(255, $outColor.a + $addColor.a) } } `{ $mergeColor.$_ = Merge-Channel $addColor $outColor $_ }$outColor = $mergeColor }} end {return '#{0:x2}{1:x2}{2:x2}{3:x2}' -f ($argb | % { [int][Math]::Round($outColor.$_, 0) }) }}

Now all you have to do is save it in %userprofile%\My Documents\WindowsPowerShell\Modules\UITools as UITools.psm1 and call Import-Module UITools to bring in this function.