Posts Tagged Controls
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.
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.
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.