True to the motto “oldie but a goldie” I have a simple solution for a typical problem arising in a modular WPF application: If you have a setup where your Resource Dictionary is located in another project, the designer is very likely to be ignorant about its contents. Merging the dictionary into your App.xaml Resource node will handle the runtime situation correctly, but VS is likely to fail in showing the resource at design time as desired.
In my last blog post I described the general idea of using Rx to handle typical query situation with all their pitfalls. Let us take the idea one step further in developing a WPF control that directly makes use of Rx. The source code excerpts in this post are simplified and I tried to focus just on the important aspects. The final code looks a bit different and can be downloaded from GitHub.
In this blog post we will focus on the Rx aspects of developing an autocomplete feature. In the next blog post we are going to work on a re-usable WPF auto-complete TextBox that uses Rx under the covers. Some months ago I delivered a Workshop on Reactive Extensions (Rx). If you never heard about Rx, you should read this first. One little exercise I did with the workshop attendees was to develop a basic auto-complete TextBox that would query an online dictionary service and the results would be shown in the UI.
Not exactly a brand new topic in the area of WPF development are attached behaviors. However, in my opinion, they should be used more often - that’s why I decided to write about it. Let us start from the beginning. What is an attached behavior? From a high level perspective attached behaviors allow you to write a snippet of code that can add additional features to a WPF control without doing something that drastic as inheriting from an existing control class.