Problem

Within the WPF framework access keys are always scoped to the active window, regardless of what settings you may have set. This can cause problems when multiple elements exist within the window hierarchy. The WPF framework will likely choose the incorrect target element. What you need is to scope the access keys to the currently focused element, and unfortunately the WPF framework contains a internal bug that prevents this functionality.

Solution

Problem

When you need to add a double-quote character to a string, you will run into a problem. Double-quotes are the delimiters for the beginning and end of a string, so placing a double-quote within a string will confuse the compiler and it will give you an exception.

Solution

Problem

When passing in a formatted string as an argument to a method such as Console.WriteLine, String.Format, etc., curly braces have a special meaning. They are used as a placeholder for a variable. Therefore when you want to add a curly brace within the formatted string, but you don’t want it to be interpreted as a placeholder for a variable, you have a problem.

Solution

Problem

As some of you may have noticed while working with a Selector-derived control and an ICollectionView, there is a bug with the IsSynchronizedWithCurrentItem property of Selector. IsSynchronizedWithCurrentItem is provided by Selector to support the ability to keep its SelectedItem in-sync with the CurrentItem of its ItemSource’s ICollectionView. IsSynchronizedWithCurrentItem works perfectly except for one specific case: when the CurrentChanging event of ICollectionView is handled and the item change is cancelled.

In this case the Selector does not respect the cancel and it gets out-of-sync with the ICollectionView. I’d imagine this bug exists because the Selector class was likely implemented before ICollectionView, and Selector was not updated to match the addition. Whatever happened though the bug does exist in WPF 4.0 and can be very problematic. Luckily, with attached properties at our disposable we can work up an easy fix.

Solution

Problem

COM exceptions that give you just a HRESULT to describe an exception are terrible. During some VSTO development for Outlook 2007, I kept getting a COM exception with an HRESULT of 0x800A01A8, and eventually I found the reason why I was receiving the exception. I though I’d share since little information is available on this particular exception.

Solution

Problem

Often times WPF developers want to throw their computer out the window because of a small and very irritating truth about the ContextMenu control. I’m talking about the fact that ContextMenu is not in the same visual tree as its containing parent, resulting in many data binding issues. Since the ContextMenu is not in the same visual tree, ElementName, RelativeSouce (FindAncestor), etc bindings will not work. You can get around this through the use of the PlacementTarget property and some complex DataContext re-routing, but it is a pain, confusing, and does not scale well (at all). I will present a very simple attached property that relieves the situation.

Introduction

When dealing with software applications it is commonplace for users to have certain expectations. These expectations not only include the abilities of an application, but also include how such abilities are executed. The specific expectations that this article is focused upon directly concern those of the data grid control, and more specifically Microsoft’s implementation of such a control under the Windows Presentation Foundation (WPF) user-interface rendering sub-system for Windows-based applications.

Users have come to expect the ability to hide or show the columns of a data grid control. Such an action is typically executed by right-clicking on any of the data grid’s column headers. This results in the option to select a menu item, via a context menu, that will toggle the visibility of the column labeled on the menu item. Therefore providing this ability with access to execute its associated actions in the typical way, would be a wise and logical decision. The implementation of meeting this need should be provided through an encapsulated and reusable interface. Unfortunately, Microsoft’s implementation of the data grid control does not offer this functionally as a built-in feature and adding it has proving to be a difficult task.

In this article you will be provided with a solution that implements this functionality specifically for Microsoft’s implementation of the data grid control. This solution has proving reliable regardless of whether the data grid’s columns have been auto-generated through the data in which it represents, while still conforming to the generally accepted Model-View-ViewModel (MVVM) design pattern guidelines. This has been accomplished by utilizing WPF’s attached properties system whose means provide the ability of separate child elements to specify unique values on properties defined in a parent element; thus providing the ability to manipulate the parent element’s behavior indirectly. In this way the concepts of encapsulation and reuse have been applied.

Problem

The SelectAll button on Microsoft’s DataGrid control cannot be styled without a workaround. This is a direct result of there being no SelectAllButtonTemplate property on the control. To get around this issue we’ll make our own property using attached properties. This way we can have nice, clean, MVVM-compliant code and XAML-markup, while still getting what we want.

Problem

Sometimes in WPF you want to have a list of items contained in a ListBox (or ListView) that you don’t want to be selectable. You could set those items to be disabled, by assigning IsEnabled to False, but that may interfere with styles among other things. You could also (probably the best idea) use a ItemsControl, from which the ListBox derives, that doesn’t include selectable-items functionality. However, for whatever reason, you may just want to use a ListBox (or ListView) instead.

Overview
Yesterday I worked up a static helper class that encapsulates the functionality to disable/enable/toggle the minimize and maximize buttons on a standard WPF window. This morning I updated that code to fix some bugs that I overlooked. Finally just not long ago, I updated the code with a new static class called WindowCustomizer, which allows this same functionality through the use of attached properties straight from XAML-markup. The advantage here is that this is now a full MVVM-compliant solution.Read the rest of this entry »

Overview
Back not to long ago, I released a post dealing with the dynamic generation of classes at run-time. Since then I have applied the concepts shown in that post in my real-world projects. As expected of any new code, I have found several bugs and inconveniences with the original code from that post. This time around I have an updated CodeGenerationHelper class, a DynamicFactory class, and an actual example of how to use the generated objects. The download-able version of the sample can be obtained through this link: http://thrash505.webs.com/DynamicCodeGeneration.zip

Overview
Back a few months ago I had a class that needed (or so I thought) to be generated at run-time. The need arose from WPF controls only working with Properties, not fields, and more specifically ones that implemented INotifyPropertyChanged. (or dependency properties, but I typically save those for custom controls) After some research I created a simple straightforward helper class, CodeGenerationHelper, that would create a dynamic class at run-time from a hashtable. From a hashtable because my solution was working with data received through XML-RPC in the from of an extended hastable implementation. (XmlRpcStruct)

Problem

When your application has a control on it that derives from Selector and has no items on load nothing is selected. During run-time when the user is clicking around and adds items to the Selector-derived control, you would assume that the control would automatically select the first item because that only makes sense. However, your assumption and mine would be wrong; this is not the behavior at all. Instead the selector will still have no items selected. This means in order to get this “auto-select first item” behavior, you have to do it yourself. Luckily its an easy fix as shown below.

I’ve always disliked dialog boxes… especially ones that only have an “OK” button on it. These sorts of dialog boxes are not very helpful because they stop the user in there tracks to tell them something and then force them to click “OK”. I really don’t like that scenario so I came up with an alternative method of accomplishing the same thing in what I think is a better way.

Its called a message bar and by default it sits on the bottom of a window where the status bar would normally be. When the program needs to subtly tell the user something and the user doesn’t have to make an immediate decision, you can use the message bar. It is not meant for letting the user take an action… so no “Do you want to save?” scenarios. I like this approach better because it still draws attention, but doesn’t stop the user from what there trying to do. Use it when saving to a file failed, when there network connection drops, when they entered an invalid value, etc.

Problem

I’ve found myself in the situation where I have an array of objects that I want to cast into an array of some other type. You’d think that this would be as simple as: (TheType[])objectArray, but unfortunately, one way or another, you have to loop through each object and cast it into the new type. This becomes a pain when you need to do it frequently.

Problem

In WPF most animations are time-based, using storyboards to animate a objects properties over a certain period of time. That is great and works well until an artist hands you a stack of images that are to be used as individual frames of an animation. This is my current situation, so I spent an hour or two trying to figure out a way to accomplish frame-based animations in WPF. This is what I came up with…