I have a WPF programming question for you all. I just can't find a way to do this, even after trying several hacks. Suppose I have a TreeView where items should all contain CheckBoxs. I want it so that the user can easily navigate through the tree and press Spacebar to check/uncheck an item's CheckBox. The problem is with input focus. I find that the TreeViewItems want to take focus first, requiring me to press an arrow key twice to bring focus to the contained CheckBox. I tried setting Focusable on the ItemContainerStyle to false, but then the keyboard navigation does not work properly. I also tried writing some code that handles GotFocus and GotKeyboardFocus of all TreeViewItems and then use FindName to get at the CheckBox and give it focus. This doesn't work either, because focus never leaves the first CheckBox.
Here's the XAML I am using: <TreeView ItemsSource="{Binding}"> <TreeView.ItemTemplate> <HierarchicalDataTemplate ItemsSource="{Binding Children}"> <CheckBox x:Name="chk" Content="{Binding Name}" IsChecked="{Binding IsChecked}" /> </HierarchicalDataTemplate> </TreeView.ItemTemplate> </TreeView>
Anyone ever figured this out before? If so, what's the trick? This seems like it should be a simple XAML-only solution, but I can't figure it out! :(
Focus management with TreeView and List based controls is pretty tricky and one of the big pain points in WPF. I still don't have a good hold on this topic. I had done something similar earlier just that my template for the TreeViewItem was more complex and had more controls. However due to lack of time, we decided to provide only mouse support (Sucks .. but that was how it went).
On Wed, Jul 30, 2008 at 2:41 PM, Josh Smith <flappleja...@gmail.com> wrote: > Hey all,
> I have a WPF programming question for you all. I just can't find a way to > do this, even after trying several hacks. Suppose I have a TreeView where > items should all contain CheckBoxs. I want it so that the user can easily > navigate through the tree and press Spacebar to check/uncheck an item's > CheckBox. The problem is with input focus. I find that the TreeViewItems > want to take focus first, requiring me to press an arrow key twice to bring > focus to the contained CheckBox. I tried setting Focusable on the > ItemContainerStyle to false, but then the keyboard navigation does not work > properly. I also tried writing some code that handles GotFocus and > GotKeyboardFocus of all TreeViewItems and then use FindName to get at the > CheckBox and give it focus. This doesn't work either, because focus never > leaves the first CheckBox.
> Anyone ever figured this out before? If so, what's the trick? This seems > like it should be a simple XAML-only solution, but I can't figure it out! > :(
Thanks Pavan. Of course, that isn't the answer I was hoping for! :) Oh well, it seems I've got my work cut out for me (unless someone can come to the rescue...).
josh
On Wed, Jul 30, 2008 at 3:43 PM, Pavan Podila <pavan.pod...@gmail.com>wrote:
> Focus management with TreeView and List based controls is pretty tricky and > one of the big pain points in WPF. I still don't have a good hold on this > topic. I had done something similar earlier just that my template for the > TreeViewItem was more complex and had more controls. However due to lack of > time, we decided to provide only mouse support (Sucks .. but that was how it > went).
> On Wed, Jul 30, 2008 at 2:41 PM, Josh Smith <flappleja...@gmail.com>wrote:
>> Hey all,
>> I have a WPF programming question for you all. I just can't find a way to >> do this, even after trying several hacks. Suppose I have a TreeView where >> items should all contain CheckBoxs. I want it so that the user can easily >> navigate through the tree and press Spacebar to check/uncheck an item's >> CheckBox. The problem is with input focus. I find that the TreeViewItems >> want to take focus first, requiring me to press an arrow key twice to bring >> focus to the contained CheckBox. I tried setting Focusable on the >> ItemContainerStyle to false, but then the keyboard navigation does not work >> properly. I also tried writing some code that handles GotFocus and >> GotKeyboardFocus of all TreeViewItems and then use FindName to get at the >> CheckBox and give it focus. This doesn't work either, because focus never >> leaves the first CheckBox.
>> Anyone ever figured this out before? If so, what's the trick? This seems >> like it should be a simple XAML-only solution, but I can't figure it out! >> :(
On Wed, Jul 30, 2008 at 3:46 PM, Josh Smith <flappleja...@gmail.com> wrote: > Thanks Pavan. Of course, that isn't the answer I was hoping for! :) Oh > well, it seems I've got my work cut out for me (unless someone can come to > the rescue...).
> josh
> On Wed, Jul 30, 2008 at 3:43 PM, Pavan Podila <pavan.pod...@gmail.com>wrote:
>> Focus management with TreeView and List based controls is pretty tricky >> and one of the big pain points in WPF. I still don't have a good hold on >> this topic. I had done something similar earlier just that my template for >> the TreeViewItem was more complex and had more controls. However due to lack >> of time, we decided to provide only mouse support (Sucks .. but that was how >> it went).
>> On Wed, Jul 30, 2008 at 2:41 PM, Josh Smith <flappleja...@gmail.com>wrote:
>>> Hey all,
>>> I have a WPF programming question for you all. I just can't find a way >>> to do this, even after trying several hacks. Suppose I have a TreeView >>> where items should all contain CheckBoxs. I want it so that the user can >>> easily navigate through the tree and press Spacebar to check/uncheck an >>> item's CheckBox. The problem is with input focus. I find that the >>> TreeViewItems want to take focus first, requiring me to press an arrow key >>> twice to bring focus to the contained CheckBox. I tried setting Focusable >>> on the ItemContainerStyle to false, but then the keyboard navigation does >>> not work properly. I also tried writing some code that handles GotFocus and >>> GotKeyboardFocus of all TreeViewItems and then use FindName to get at the >>> CheckBox and give it focus. This doesn't work either, because focus never >>> leaves the first CheckBox.
>>> Anyone ever figured this out before? If so, what's the trick? This seems >>> like it should be a simple XAML-only solution, but I can't figure it out! >>> :(
BTW, did you try calling MoveFocus() on the element that has focus with a TraversalRequest of Down/Up. Keyboard.FocusedElement should get you the current element. This is a pretty manual way and not Xaml based (although if you can get this working you could make it into an attached property).
On Wed, Jul 30, 2008 at 3:46 PM, Josh Smith <flappleja...@gmail.com> wrote: > Thanks Pavan. Of course, that isn't the answer I was hoping for! :) Oh > well, it seems I've got my work cut out for me (unless someone can come to > the rescue...).
> josh
> On Wed, Jul 30, 2008 at 3:43 PM, Pavan Podila <pavan.pod...@gmail.com>wrote:
>> Focus management with TreeView and List based controls is pretty tricky >> and one of the big pain points in WPF. I still don't have a good hold on >> this topic. I had done something similar earlier just that my template for >> the TreeViewItem was more complex and had more controls. However due to lack >> of time, we decided to provide only mouse support (Sucks .. but that was how >> it went).
>> On Wed, Jul 30, 2008 at 2:41 PM, Josh Smith <flappleja...@gmail.com>wrote:
>>> Hey all,
>>> I have a WPF programming question for you all. I just can't find a way >>> to do this, even after trying several hacks. Suppose I have a TreeView >>> where items should all contain CheckBoxs. I want it so that the user can >>> easily navigate through the tree and press Spacebar to check/uncheck an >>> item's CheckBox. The problem is with input focus. I find that the >>> TreeViewItems want to take focus first, requiring me to press an arrow key >>> twice to bring focus to the contained CheckBox. I tried setting Focusable >>> on the ItemContainerStyle to false, but then the keyboard navigation does >>> not work properly. I also tried writing some code that handles GotFocus and >>> GotKeyboardFocus of all TreeViewItems and then use FindName to get at the >>> CheckBox and give it focus. This doesn't work either, because focus never >>> leaves the first CheckBox.
>>> Anyone ever figured this out before? If so, what's the trick? This seems >>> like it should be a simple XAML-only solution, but I can't figure it out! >>> :(
> BTW, did you try calling MoveFocus() on the element that has focus with a > TraversalRequest of Down/Up. Keyboard.FocusedElement should get you the > current element. This is a pretty manual way and not Xaml based (although if > you can get this working you could make it into an attached property).
> On Wed, Jul 30, 2008 at 3:46 PM, Josh Smith <flappleja...@gmail.com>wrote:
>> Thanks Pavan. Of course, that isn't the answer I was hoping for! :) Oh >> well, it seems I've got my work cut out for me (unless someone can come to >> the rescue...).
>> josh
>> On Wed, Jul 30, 2008 at 3:43 PM, Pavan Podila <pavan.pod...@gmail.com>wrote:
>>> Focus management with TreeView and List based controls is pretty tricky >>> and one of the big pain points in WPF. I still don't have a good hold on >>> this topic. I had done something similar earlier just that my template for >>> the TreeViewItem was more complex and had more controls. However due to lack >>> of time, we decided to provide only mouse support (Sucks .. but that was how >>> it went).
>>> On Wed, Jul 30, 2008 at 2:41 PM, Josh Smith <flappleja...@gmail.com>wrote:
>>>> Hey all,
>>>> I have a WPF programming question for you all. I just can't find a way >>>> to do this, even after trying several hacks. Suppose I have a TreeView >>>> where items should all contain CheckBoxs. I want it so that the user can >>>> easily navigate through the tree and press Spacebar to check/uncheck an >>>> item's CheckBox. The problem is with input focus. I find that the >>>> TreeViewItems want to take focus first, requiring me to press an arrow key >>>> twice to bring focus to the contained CheckBox. I tried setting Focusable >>>> on the ItemContainerStyle to false, but then the keyboard navigation does >>>> not work properly. I also tried writing some code that handles GotFocus and >>>> GotKeyboardFocus of all TreeViewItems and then use FindName to get at the >>>> CheckBox and give it focus. This doesn't work either, because focus never >>>> leaves the first CheckBox.
>>>> Anyone ever figured this out before? If so, what's the trick? This >>>> seems like it should be a simple XAML-only solution, but I can't figure it >>>> out! :(
On Wed, Jul 30, 2008 at 4:03 PM, Josh Smith <flappleja...@gmail.com> wrote: > Yes I tried that, but that didn't work either. It is amazing how difficult > this is. It should be dead simple, in my opinion.
> On Wed, Jul 30, 2008 at 4:01 PM, Pavan Podila <pavan.pod...@gmail.com>wrote:
>> BTW, did you try calling MoveFocus() on the element that has focus with a >> TraversalRequest of Down/Up. Keyboard.FocusedElement should get you the >> current element. This is a pretty manual way and not Xaml based (although if >> you can get this working you could make it into an attached property).
>> On Wed, Jul 30, 2008 at 3:46 PM, Josh Smith <flappleja...@gmail.com>wrote:
>>> Thanks Pavan. Of course, that isn't the answer I was hoping for! :) Oh >>> well, it seems I've got my work cut out for me (unless someone can come to >>> the rescue...).
>>> josh
>>> On Wed, Jul 30, 2008 at 3:43 PM, Pavan Podila <pavan.pod...@gmail.com>wrote:
>>>> Focus management with TreeView and List based controls is pretty tricky >>>> and one of the big pain points in WPF. I still don't have a good hold on >>>> this topic. I had done something similar earlier just that my template for >>>> the TreeViewItem was more complex and had more controls. However due to lack >>>> of time, we decided to provide only mouse support (Sucks .. but that was how >>>> it went).
>>>> On Wed, Jul 30, 2008 at 2:41 PM, Josh Smith <flappleja...@gmail.com>wrote:
>>>>> Hey all,
>>>>> I have a WPF programming question for you all. I just can't find a way >>>>> to do this, even after trying several hacks. Suppose I have a TreeView >>>>> where items should all contain CheckBoxs. I want it so that the user can >>>>> easily navigate through the tree and press Spacebar to check/uncheck an >>>>> item's CheckBox. The problem is with input focus. I find that the >>>>> TreeViewItems want to take focus first, requiring me to press an arrow key >>>>> twice to bring focus to the contained CheckBox. I tried setting Focusable >>>>> on the ItemContainerStyle to false, but then the keyboard navigation does >>>>> not work properly. I also tried writing some code that handles GotFocus and >>>>> GotKeyboardFocus of all TreeViewItems and then use FindName to get at the >>>>> CheckBox and give it focus. This doesn't work either, because focus never >>>>> leaves the first CheckBox.
>>>>> Anyone ever figured this out before? If so, what's the trick? This >>>>> seems like it should be a simple XAML-only solution, but I can't figure it >>>>> out! :(
> Let me know if you figure it out ... I'd love to hear !
> On Wed, Jul 30, 2008 at 4:03 PM, Josh Smith <flappleja...@gmail.com>wrote:
>> Yes I tried that, but that didn't work either. It is amazing how >> difficult this is. It should be dead simple, in my opinion.
>> On Wed, Jul 30, 2008 at 4:01 PM, Pavan Podila <pavan.pod...@gmail.com>wrote:
>>> BTW, did you try calling MoveFocus() on the element that has focus with a >>> TraversalRequest of Down/Up. Keyboard.FocusedElement should get you the >>> current element. This is a pretty manual way and not Xaml based (although if >>> you can get this working you could make it into an attached property).
>>> On Wed, Jul 30, 2008 at 3:46 PM, Josh Smith <flappleja...@gmail.com>wrote:
>>>> Thanks Pavan. Of course, that isn't the answer I was hoping for! :) >>>> Oh well, it seems I've got my work cut out for me (unless someone can come >>>> to the rescue...).
>>>> josh
>>>> On Wed, Jul 30, 2008 at 3:43 PM, Pavan Podila <pavan.pod...@gmail.com>wrote:
>>>>> Focus management with TreeView and List based controls is pretty tricky >>>>> and one of the big pain points in WPF. I still don't have a good hold on >>>>> this topic. I had done something similar earlier just that my template for >>>>> the TreeViewItem was more complex and had more controls. However due to lack >>>>> of time, we decided to provide only mouse support (Sucks .. but that was how >>>>> it went).
>>>>> On Wed, Jul 30, 2008 at 2:41 PM, Josh Smith <flappleja...@gmail.com>wrote:
>>>>>> Hey all,
>>>>>> I have a WPF programming question for you all. I just can't find a >>>>>> way to do this, even after trying several hacks. Suppose I have a TreeView >>>>>> where items should all contain CheckBoxs. I want it so that the user can >>>>>> easily navigate through the tree and press Spacebar to check/uncheck an >>>>>> item's CheckBox. The problem is with input focus. I find that the >>>>>> TreeViewItems want to take focus first, requiring me to press an arrow key >>>>>> twice to bring focus to the contained CheckBox. I tried setting Focusable >>>>>> on the ItemContainerStyle to false, but then the keyboard navigation does >>>>>> not work properly. I also tried writing some code that handles GotFocus and >>>>>> GotKeyboardFocus of all TreeViewItems and then use FindName to get at the >>>>>> CheckBox and give it focus. This doesn't work either, because focus never >>>>>> leaves the first CheckBox.
>>>>>> Anyone ever figured this out before? If so, what's the trick? This >>>>>> seems like it should be a simple XAML-only solution, but I can't figure it >>>>>> out! :(
On Wed, Jul 30, 2008 at 4:05 PM, Josh Smith <flappleja...@gmail.com> wrote: > Hey, you stole my role in this thread!! :D
> On Wed, Jul 30, 2008 at 4:04 PM, Pavan Podila <pavan.pod...@gmail.com>wrote:
>> Let me know if you figure it out ... I'd love to hear !
>> On Wed, Jul 30, 2008 at 4:03 PM, Josh Smith <flappleja...@gmail.com>wrote:
>>> Yes I tried that, but that didn't work either. It is amazing how >>> difficult this is. It should be dead simple, in my opinion.
>>> On Wed, Jul 30, 2008 at 4:01 PM, Pavan Podila <pavan.pod...@gmail.com>wrote:
>>>> BTW, did you try calling MoveFocus() on the element that has focus with >>>> a TraversalRequest of Down/Up. Keyboard.FocusedElement should get you the >>>> current element. This is a pretty manual way and not Xaml based (although if >>>> you can get this working you could make it into an attached property).
>>>> On Wed, Jul 30, 2008 at 3:46 PM, Josh Smith <flappleja...@gmail.com>wrote:
>>>>> Thanks Pavan. Of course, that isn't the answer I was hoping for! :) >>>>> Oh well, it seems I've got my work cut out for me (unless someone can come >>>>> to the rescue...).
>>>>> josh
>>>>> On Wed, Jul 30, 2008 at 3:43 PM, Pavan Podila <pavan.pod...@gmail.com>wrote:
>>>>>> Focus management with TreeView and List based controls is pretty >>>>>> tricky and one of the big pain points in WPF. I still don't have a good hold >>>>>> on this topic. I had done something similar earlier just that my template >>>>>> for the TreeViewItem was more complex and had more controls. However due to >>>>>> lack of time, we decided to provide only mouse support (Sucks .. but that >>>>>> was how it went).
>>>>>> On Wed, Jul 30, 2008 at 2:41 PM, Josh Smith <flappleja...@gmail.com>wrote:
>>>>>>> Hey all,
>>>>>>> I have a WPF programming question for you all. I just can't find a >>>>>>> way to do this, even after trying several hacks. Suppose I have a TreeView >>>>>>> where items should all contain CheckBoxs. I want it so that the user can >>>>>>> easily navigate through the tree and press Spacebar to check/uncheck an >>>>>>> item's CheckBox. The problem is with input focus. I find that the >>>>>>> TreeViewItems want to take focus first, requiring me to press an arrow key >>>>>>> twice to bring focus to the contained CheckBox. I tried setting Focusable >>>>>>> on the ItemContainerStyle to false, but then the keyboard navigation does >>>>>>> not work properly. I also tried writing some code that handles GotFocus and >>>>>>> GotKeyboardFocus of all TreeViewItems and then use FindName to get at the >>>>>>> CheckBox and give it focus. This doesn't work either, because focus never >>>>>>> leaves the first CheckBox.
>>>>>>> Anyone ever figured this out before? If so, what's the trick? This >>>>>>> seems like it should be a simple XAML-only solution, but I can't figure it >>>>>>> out! :(
>>>>>>> Thanks, >>>>>>> Josh
>>>>>> -- >>>>>> the approach, rather than the solution >>>>>> ...o0O0o... >>>>>> http://blog.pixelingene.com
> Sorry ...all yours :)) I am just equally curious as I know the amount of > time I wasted (researched)
> On Wed, Jul 30, 2008 at 4:05 PM, Josh Smith <flappleja...@gmail.com>wrote:
>> Hey, you stole my role in this thread!! :D
>> On Wed, Jul 30, 2008 at 4:04 PM, Pavan Podila <pavan.pod...@gmail.com>wrote:
>>> Let me know if you figure it out ... I'd love to hear !
>>> On Wed, Jul 30, 2008 at 4:03 PM, Josh Smith <flappleja...@gmail.com>wrote:
>>>> Yes I tried that, but that didn't work either. It is amazing how >>>> difficult this is. It should be dead simple, in my opinion.
>>>> On Wed, Jul 30, 2008 at 4:01 PM, Pavan Podila <pavan.pod...@gmail.com>wrote:
>>>>> BTW, did you try calling MoveFocus() on the element that has focus with >>>>> a TraversalRequest of Down/Up. Keyboard.FocusedElement should get you the >>>>> current element. This is a pretty manual way and not Xaml based (although if >>>>> you can get this working you could make it into an attached property).
>>>>> On Wed, Jul 30, 2008 at 3:46 PM, Josh Smith <flappleja...@gmail.com>wrote:
>>>>>> Thanks Pavan. Of course, that isn't the answer I was hoping for! :) >>>>>> Oh well, it seems I've got my work cut out for me (unless someone can come >>>>>> to the rescue...).
>>>>>> josh
>>>>>> On Wed, Jul 30, 2008 at 3:43 PM, Pavan Podila <pavan.pod...@gmail.com >>>>>> > wrote:
>>>>>>> Focus management with TreeView and List based controls is pretty >>>>>>> tricky and one of the big pain points in WPF. I still don't have a good hold >>>>>>> on this topic. I had done something similar earlier just that my template >>>>>>> for the TreeViewItem was more complex and had more controls. However due to >>>>>>> lack of time, we decided to provide only mouse support (Sucks .. but that >>>>>>> was how it went).
>>>>>>> On Wed, Jul 30, 2008 at 2:41 PM, Josh Smith <flappleja...@gmail.com>wrote:
>>>>>>>> Hey all,
>>>>>>>> I have a WPF programming question for you all. I just can't find a >>>>>>>> way to do this, even after trying several hacks. Suppose I have a TreeView >>>>>>>> where items should all contain CheckBoxs. I want it so that the user can >>>>>>>> easily navigate through the tree and press Spacebar to check/uncheck an >>>>>>>> item's CheckBox. The problem is with input focus. I find that the >>>>>>>> TreeViewItems want to take focus first, requiring me to press an arrow key >>>>>>>> twice to bring focus to the contained CheckBox. I tried setting Focusable >>>>>>>> on the ItemContainerStyle to false, but then the keyboard navigation does >>>>>>>> not work properly. I also tried writing some code that handles GotFocus and >>>>>>>> GotKeyboardFocus of all TreeViewItems and then use FindName to get at the >>>>>>>> CheckBox and give it focus. This doesn't work either, because focus never >>>>>>>> leaves the first CheckBox.
>>>>>>>> Anyone ever figured this out before? If so, what's the trick? This >>>>>>>> seems like it should be a simple XAML-only solution, but I can't figure it >>>>>>>> out! :(
>>>>>>>> Thanks, >>>>>>>> Josh
>>>>>>> -- >>>>>>> the approach, rather than the solution >>>>>>> ...o0O0o... >>>>>>> http://blog.pixelingene.com
I found a solution, but it sucks. I make the CheckBox Focusable=False, hook up a custom command on my TreeView that is triggered via keygestures of Space and Enter, and the execution logic of that command gets the SelectedItem viewmodel object from the tree and toggles it's IsChecked property. YUCK!
On Wed, Jul 30, 2008 at 4:07 PM, Josh Smith <flappleja...@gmail.com> wrote: > It's all good, Pavan. Thanks for your help!!
> On Wed, Jul 30, 2008 at 4:07 PM, Pavan Podila <pavan.pod...@gmail.com>wrote:
>> Sorry ...all yours :)) I am just equally curious as I know the amount of >> time I wasted (researched)
>> On Wed, Jul 30, 2008 at 4:05 PM, Josh Smith <flappleja...@gmail.com>wrote:
>>> Hey, you stole my role in this thread!! :D
>>> On Wed, Jul 30, 2008 at 4:04 PM, Pavan Podila <pavan.pod...@gmail.com>wrote:
>>>> Let me know if you figure it out ... I'd love to hear !
>>>> On Wed, Jul 30, 2008 at 4:03 PM, Josh Smith <flappleja...@gmail.com>wrote:
>>>>> Yes I tried that, but that didn't work either. It is amazing how >>>>> difficult this is. It should be dead simple, in my opinion.
>>>>> On Wed, Jul 30, 2008 at 4:01 PM, Pavan Podila <pavan.pod...@gmail.com>wrote:
>>>>>> BTW, did you try calling MoveFocus() on the element that has focus >>>>>> with a TraversalRequest of Down/Up. Keyboard.FocusedElement should get you >>>>>> the current element. This is a pretty manual way and not Xaml based >>>>>> (although if you can get this working you could make it into an attached >>>>>> property).
>>>>>> On Wed, Jul 30, 2008 at 3:46 PM, Josh Smith <flappleja...@gmail.com>wrote:
>>>>>>> Thanks Pavan. Of course, that isn't the answer I was hoping for! >>>>>>> :) Oh well, it seems I've got my work cut out for me (unless someone can >>>>>>> come to the rescue...).
>>>>>>> josh
>>>>>>> On Wed, Jul 30, 2008 at 3:43 PM, Pavan Podila < >>>>>>> pavan.pod...@gmail.com> wrote:
>>>>>>>> Focus management with TreeView and List based controls is pretty >>>>>>>> tricky and one of the big pain points in WPF. I still don't have a good hold >>>>>>>> on this topic. I had done something similar earlier just that my template >>>>>>>> for the TreeViewItem was more complex and had more controls. However due to >>>>>>>> lack of time, we decided to provide only mouse support (Sucks .. but that >>>>>>>> was how it went).
>>>>>>>> On Wed, Jul 30, 2008 at 2:41 PM, Josh Smith <flappleja...@gmail.com >>>>>>>> > wrote:
>>>>>>>>> Hey all,
>>>>>>>>> I have a WPF programming question for you all. I just can't find a >>>>>>>>> way to do this, even after trying several hacks. Suppose I have a TreeView >>>>>>>>> where items should all contain CheckBoxs. I want it so that the user can >>>>>>>>> easily navigate through the tree and press Spacebar to check/uncheck an >>>>>>>>> item's CheckBox. The problem is with input focus. I find that the >>>>>>>>> TreeViewItems want to take focus first, requiring me to press an arrow key >>>>>>>>> twice to bring focus to the contained CheckBox. I tried setting Focusable >>>>>>>>> on the ItemContainerStyle to false, but then the keyboard navigation does >>>>>>>>> not work properly. I also tried writing some code that handles GotFocus and >>>>>>>>> GotKeyboardFocus of all TreeViewItems and then use FindName to get at the >>>>>>>>> CheckBox and give it focus. This doesn't work either, because focus never >>>>>>>>> leaves the first CheckBox.
>>>>>>>>> Anyone ever figured this out before? If so, what's the trick? This >>>>>>>>> seems like it should be a simple XAML-only solution, but I can't figure it >>>>>>>>> out! :(
>>>>>>>>> Thanks, >>>>>>>>> Josh
>>>>>>>> -- >>>>>>>> the approach, rather than the solution >>>>>>>> ...o0O0o... >>>>>>>> http://blog.pixelingene.com
>>>>>> -- >>>>>> the approach, rather than the solution >>>>>> ...o0O0o... >>>>>> http://blog.pixelingene.com
On Wed, Jul 30, 2008 at 6:25 PM, Josh Smith <flappleja...@gmail.com> wrote: > I found a solution, but it sucks. I make the CheckBox Focusable=False, > hook up a custom command on my TreeView that is triggered via keygestures of > Space and Enter, and the execution logic of that command gets the > SelectedItem viewmodel object from the tree and toggles it's IsChecked > property. YUCK!
> On Wed, Jul 30, 2008 at 4:07 PM, Josh Smith <flappleja...@gmail.com>wrote:
>> It's all good, Pavan. Thanks for your help!!
>> On Wed, Jul 30, 2008 at 4:07 PM, Pavan Podila <pavan.pod...@gmail.com>wrote:
>>> Sorry ...all yours :)) I am just equally curious as I know the amount of >>> time I wasted (researched)
>>> On Wed, Jul 30, 2008 at 4:05 PM, Josh Smith <flappleja...@gmail.com>wrote:
>>>> Hey, you stole my role in this thread!! :D
>>>> On Wed, Jul 30, 2008 at 4:04 PM, Pavan Podila <pavan.pod...@gmail.com>wrote:
>>>>> Let me know if you figure it out ... I'd love to hear !
>>>>> On Wed, Jul 30, 2008 at 4:03 PM, Josh Smith <flappleja...@gmail.com>wrote:
>>>>>> Yes I tried that, but that didn't work either. It is amazing how >>>>>> difficult this is. It should be dead simple, in my opinion.
>>>>>> On Wed, Jul 30, 2008 at 4:01 PM, Pavan Podila <pavan.pod...@gmail.com >>>>>> > wrote:
>>>>>>> BTW, did you try calling MoveFocus() on the element that has focus >>>>>>> with a TraversalRequest of Down/Up. Keyboard.FocusedElement should get you >>>>>>> the current element. This is a pretty manual way and not Xaml based >>>>>>> (although if you can get this working you could make it into an attached >>>>>>> property).
>>>>>>> On Wed, Jul 30, 2008 at 3:46 PM, Josh Smith <flappleja...@gmail.com>wrote:
>>>>>>>> Thanks Pavan. Of course, that isn't the answer I was hoping for! >>>>>>>> :) Oh well, it seems I've got my work cut out for me (unless someone can >>>>>>>> come to the rescue...).
>>>>>>>> josh
>>>>>>>> On Wed, Jul 30, 2008 at 3:43 PM, Pavan Podila < >>>>>>>> pavan.pod...@gmail.com> wrote:
>>>>>>>>> Focus management with TreeView and List based controls is pretty >>>>>>>>> tricky and one of the big pain points in WPF. I still don't have a good hold >>>>>>>>> on this topic. I had done something similar earlier just that my template >>>>>>>>> for the TreeViewItem was more complex and had more controls. However due to >>>>>>>>> lack of time, we decided to provide only mouse support (Sucks .. but that >>>>>>>>> was how it went).
>>>>>>>>> On Wed, Jul 30, 2008 at 2:41 PM, Josh Smith < >>>>>>>>> flappleja...@gmail.com> wrote:
>>>>>>>>>> Hey all,
>>>>>>>>>> I have a WPF programming question for you all. I just can't find >>>>>>>>>> a way to do this, even after trying several hacks. Suppose I have a >>>>>>>>>> TreeView where items should all contain CheckBoxs. I want it so that the >>>>>>>>>> user can easily navigate through the tree and press Spacebar to >>>>>>>>>> check/uncheck an item's CheckBox. The problem is with input focus. I find >>>>>>>>>> that the TreeViewItems want to take focus first, requiring me to press an >>>>>>>>>> arrow key twice to bring focus to the contained CheckBox. I tried setting >>>>>>>>>> Focusable on the ItemContainerStyle to false, but then the keyboard >>>>>>>>>> navigation does not work properly. I also tried writing some code that >>>>>>>>>> handles GotFocus and GotKeyboardFocus of all TreeViewItems and then use >>>>>>>>>> FindName to get at the CheckBox and give it focus. This doesn't work >>>>>>>>>> either, because focus never leaves the first CheckBox.
>>>>>>>>>> Anyone ever figured this out before? If so, what's the trick? >>>>>>>>>> This seems like it should be a simple XAML-only solution, but I can't figure >>>>>>>>>> it out! :(
>>>>>>>>>> Thanks, >>>>>>>>>> Josh
>>>>>>>>> -- >>>>>>>>> the approach, rather than the solution >>>>>>>>> ...o0O0o... >>>>>>>>> http://blog.pixelingene.com
>>>>>>> -- >>>>>>> the approach, rather than the solution >>>>>>> ...o0O0o... >>>>>>> http://blog.pixelingene.com
I faced the same issue a while back and actually implemented a
solution in which I used a static class called VirtualToggleButton to
expose attached properties that would turn any input element (a
TreeViewItem, for example) into a toggle button. In your case, the
markup would look like this:
I guess the /en vogue/ term for this type of thing is /"attached
behavior". /(Thank you Mr. Gossman... you've saved me from the overly
wordy description about leveraging an attached property to extend a
class in order to add support for yada yada yada...)
When the IsVirtualToggleButton property is attached to the
TreeViewItem and set to true, the class monitors the TreeViewItem for
input events (mouse clicks or key presses) and responds to those
events just like a toggle button. A spacebar press or mouse click
will update the attached IsChecked property. It even supports the
IsThreeState property and raises all the expected toggle button events
(Checked, Unchecked, and Indeterminate) on the target element.
(Although, it doesn't include the ButtonBase events or properties...
I'm too lazy for that.)
You will still need to set Focusable to false on the CheckBox. Any
solution will likely require that because you'll never want the
additional navigation stop for the CheckBox.
I'm happy to send you the code if you'd like. Just let me know and
I'll dig it up. :-)
> I found a solution, but it sucks. I make the CheckBox Focusable=False, hook
> up a custom command on my TreeView that is triggered via keygestures of
> Space and Enter, and the execution logic of that command gets the
> SelectedItem viewmodel object from the tree and toggles it's IsChecked
> property. YUCK!
> On Wed, Jul 30, 2008 at 4:07 PM, Josh Smith <flappleja...@gmail.com> wrote:
>> It's all good, Pavan. Thanks for your help!!
>> On Wed, Jul 30, 2008 at 4:07 PM, Pavan Podila <pavan.pod...@gmail.com>wrote:
>>> Sorry ...all yours :)) I am just equally curious as I know the amount of
>>> time I wasted (researched)
>>> On Wed, Jul 30, 2008 at 4:05 PM, Josh Smith <flappleja...@gmail.com>wrote:
>>>> Hey, you stole my role in this thread!! :D
>>>> On Wed, Jul 30, 2008 at 4:04 PM, Pavan Podila
>>>> <pavan.pod...@gmail.com>wrote:
>>>>> Let me know if you figure it out ... I'd love to hear !
>>>>> On Wed, Jul 30, 2008 at 4:03 PM, Josh Smith
>>>>> <flappleja...@gmail.com>wrote:
>>>>>> Yes I tried that, but that didn't work either. It is amazing how
>>>>>> difficult this is. It should be dead simple, in my opinion.
>>>>>> On Wed, Jul 30, 2008 at 4:01 PM, Pavan Podila
>>>>>> <pavan.pod...@gmail.com>wrote:
>>>>>>> BTW, did you try calling MoveFocus() on the element that has focus
>>>>>>> with a TraversalRequest of Down/Up. Keyboard.FocusedElement
>>>>>>> should get you
>>>>>>> the current element. This is a pretty manual way and not Xaml based
>>>>>>> (although if you can get this working you could make it into
>>>>>>> an attached
>>>>>>> property).
>>>>>>> On Wed, Jul 30, 2008 at 3:46 PM, Josh Smith
>>>>>>> <flappleja...@gmail.com>wrote:
>>>>>>>> Thanks Pavan. Of course, that isn't the answer I was hoping for!
>>>>>>>> :) Oh well, it seems I've got my work cut out for me
>>>>>>>> (unless someone can
>>>>>>>> come to the rescue...).
>>>>>>>> josh
>>>>>>>> On Wed, Jul 30, 2008 at 3:43 PM, Pavan Podila <
>>>>>>>> pavan.pod...@gmail.com> wrote:
>>>>>>>>> Focus management with TreeView and List based controls is pretty
>>>>>>>>> tricky and one of the big pain points in WPF. I still don't
>>>>>>>>> have a good hold
>>>>>>>>> on this topic. I had done something similar earlier just
>>>>>>>>> that my template
>>>>>>>>> for the TreeViewItem was more complex and had more
>>>>>>>>> controls. However due to
>>>>>>>>> lack of time, we decided to provide only mouse support
>>>>>>>>> (Sucks .. but that
>>>>>>>>> was how it went).
>>>>>>>>> On Wed, Jul 30, 2008 at 2:41 PM, Josh Smith <flappleja...@gmail.com
>>>>>>>>> > wrote:
>>>>>>>>>> Hey all,
>>>>>>>>>> I have a WPF programming question for you all. I just can't find a
>>>>>>>>>> way to do this, even after trying several hacks. Suppose
>>>>>>>>>> I have a TreeView
>>>>>>>>>> where items should all contain CheckBoxs. I want it so
>>>>>>>>>> that the user can
>>>>>>>>>> easily navigate through the tree and press Spacebar to
>>>>>>>>>> check/uncheck an
>>>>>>>>>> item's CheckBox. The problem is with input focus. I find that the
>>>>>>>>>> TreeViewItems want to take focus first, requiring me to
>>>>>>>>>> press an arrow key
>>>>>>>>>> twice to bring focus to the contained CheckBox. I tried
>>>>>>>>>> setting Focusable
>>>>>>>>>> on the ItemContainerStyle to false, but then the keyboard
>>>>>>>>>> navigation does
>>>>>>>>>> not work properly. I also tried writing some code that
>>>>>>>>>> handles GotFocus and
>>>>>>>>>> GotKeyboardFocus of all TreeViewItems and then use
>>>>>>>>>> FindName to get at the
>>>>>>>>>> CheckBox and give it focus. This doesn't work either,
>>>>>>>>>> because focus never
>>>>>>>>>> leaves the first CheckBox.
>>>>>>>>>> Anyone ever figured this out before? If so, what's the trick? This
>>>>>>>>>> seems like it should be a simple XAML-only solution, but I
>>>>>>>>>> can't figure it
>>>>>>>>>> out! :(
>>>>>>>>>> Thanks,
>>>>>>>>>> Josh
>>>>>>>>> --
>>>>>>>>> the approach, rather than the solution
>>>>>>>>> ...o0O0o...
>>>>>>>>> http://blog.pixelingene.com[1]
>>>>>>> --
>>>>>>> the approach, rather than the solution
>>>>>>> ...o0O0o...
>>>>>>> http://blog.pixelingene.com[2]
On Wed, Jul 30, 2008 at 8:29 PM, Dr. WPF <a...@drwpf.com> wrote: > Sorry I'm so late to the party, Josh.
> I faced the same issue a while back and actually implemented a solution in > which I used a static class called VirtualToggleButton to expose attached > properties that would turn any input element (a TreeViewItem, for > example) into a toggle button. In your case, the markup would look like > this:
> I guess the *en vogue* term for this type of thing is *"attached > behavior". *(Thank you Mr. Gossman... you've saved me from the overly > wordy description about leveraging an attached property to extend a class in > order to add support for yada yada yada...)
> When the IsVirtualToggleButton property is attached to the TreeViewItem and > set to true, the class monitors the TreeViewItem for input events (mouse > clicks or key presses) and responds to those events just like a toggle > button. A spacebar press or mouse click will update the attached IsChecked > property. It even supports the IsThreeState property and raises all the > expected toggle button events (Checked, Unchecked, and Indeterminate) on the > target element. (Although, it doesn't include the ButtonBase events or > properties... I'm too lazy for that.)
> You will still need to set Focusable to false on the CheckBox. Any > solution will likely require that because you'll never want the additional > navigation stop for the CheckBox.
> I'm happy to send you the code if you'd like. Just let me know and I'll > dig it up. :-)
> > I found a solution, but it sucks. I make the CheckBox Focusable=False, > hook > > up a custom command on my TreeView that is triggered via keygestures of > > Space and Enter, and the execution logic of that command gets the > > SelectedItem viewmodel object from the tree and toggles it's IsChecked > > property. YUCK!
> > On Wed, Jul 30, 2008 at 4:07 PM, Josh Smith <flappleja...@gmail.com> > wrote:
> >> It's all good, Pavan. Thanks for your help!!
> >> On Wed, Jul 30, 2008 at 4:07 PM, Pavan Podila <pavan.pod...@gmail.com > >wrote:
> >>> Sorry ...all yours :)) I am just equally curious as I know the amount > of > >>> time I wasted (researched)
> >>> On Wed, Jul 30, 2008 at 4:05 PM, Josh Smith <flappleja...@gmail.com > >wrote:
> >>>> Hey, you stole my role in this thread!! :D
> >>>> On Wed, Jul 30, 2008 at 4:04 PM, Pavan Podila > >>>> <pavan.pod...@gmail.com>wrote:
> >>>>> Let me know if you figure it out ... I'd love to hear !
> >>>>> On Wed, Jul 30, 2008 at 4:03 PM, Josh Smith > >>>>> <flappleja...@gmail.com>wrote:
> >>>>>> Yes I tried that, but that didn't work either. It is amazing how > >>>>>> difficult this is. It should be dead simple, in my opinion.
> >>>>>> On Wed, Jul 30, 2008 at 4:01 PM, Pavan Podila > >>>>>> <pavan.pod...@gmail.com>wrote:
> >>>>>>> BTW, did you try calling MoveFocus() on the element that has focus > >>>>>>> with a TraversalRequest of Down/Up. Keyboard.FocusedElement > >>>>>>> should get you > >>>>>>> the current element. This is a pretty manual way and not Xaml based > >>>>>>> (although if you can get this working you could make it into > >>>>>>> an attached > >>>>>>> property).
> >>>>>>> On Wed, Jul 30, 2008 at 3:46 PM, Josh Smith > >>>>>>> <flappleja...@gmail.com>wrote:
> >>>>>>>> Thanks Pavan. Of course, that isn't the answer I was hoping for! > >>>>>>>> :) Oh well, it seems I've got my work cut out for me (unless > >>>>>>>> someone can > >>>>>>>> come to the rescue...).
> >>>>>>>> josh
> >>>>>>>> On Wed, Jul 30, 2008 at 3:43 PM, Pavan Podila < > >>>>>>>> pavan.pod...@gmail.com> wrote:
> >>>>>>>>> Focus management with TreeView and List based controls is pretty > >>>>>>>>> tricky and one of the big pain points in WPF. I still don't > >>>>>>>>> have a good hold > >>>>>>>>> on this topic. I had done something similar earlier just > >>>>>>>>> that my template > >>>>>>>>> for the TreeViewItem was more complex and had more controls. > >>>>>>>>> However due to > >>>>>>>>> lack of time, we decided to provide only mouse support > >>>>>>>>> (Sucks .. but that > >>>>>>>>> was how it went).
> >>>>>>>>> On Wed, Jul 30, 2008 at 2:41 PM, Josh Smith < > flappleja...@gmail.com > >>>>>>>>> > wrote:
> >>>>>>>>>> Hey all,
> >>>>>>>>>> I have a WPF programming question for you all. I just can't > find a > >>>>>>>>>> way to do this, even after trying several hacks. Suppose I > >>>>>>>>>> have a TreeView > >>>>>>>>>> where items should all contain CheckBoxs. I want it so > >>>>>>>>>> that the user can > >>>>>>>>>> easily navigate through the tree and press Spacebar to > >>>>>>>>>> check/uncheck an > >>>>>>>>>> item's CheckBox. The problem is with input focus. I find that > the > >>>>>>>>>> TreeViewItems want to take focus first, requiring me to > >>>>>>>>>> press an arrow key > >>>>>>>>>> twice to bring focus to the contained CheckBox. I tried > >>>>>>>>>> setting Focusable > >>>>>>>>>> on the ItemContainerStyle to false, but then the keyboard > >>>>>>>>>> navigation does > >>>>>>>>>> not work properly. I also tried writing some code that > >>>>>>>>>> handles GotFocus and > >>>>>>>>>> GotKeyboardFocus of all TreeViewItems and then use FindName > >>>>>>>>>> to get at the > >>>>>>>>>> CheckBox and give it focus. This doesn't work either, > >>>>>>>>>> because focus never > >>>>>>>>>> leaves the first CheckBox.
> >>>>>>>>>> Anyone ever figured this out before? If so, what's the trick? > This > >>>>>>>>>> seems like it should be a simple XAML-only solution, but I > >>>>>>>>>> can't figure it > >>>>>>>>>> out! :(
> >>>>>>>>>> Thanks, > >>>>>>>>>> Josh
> >>>>>>>>> -- > >>>>>>>>> the approach, rather than the solution > >>>>>>>>> ...o0O0o... > >>>>>>>>> http://blog.pixelingene.com
> >>>>>>> -- > >>>>>>> the approach, rather than the solution > >>>>>>> ...o0O0o... > >>>>>>> http://blog.pixelingene.com
> >>>>> -- > >>>>> the approach, rather than the solution > >>>>> ...o0O0o... > >>>>> http://blog.pixelingene.com
> I guess the /en vogue/ term for this type of thing is /"attached
> behavior". /(Thank you Mr. Gossman... you've saved me from the overly
> wordy description about leveraging an attached property to extend a
> class in order to add support for yada yada yada...)
Any chance this difficulty might be ironed out in a subsequent release of platform? It's hard to believe that creating a TreeView with checkboxes in the items, which is easy to navigate via the keyboard and mouse, requires so much custom work. This should be dead simple, in my opinion. If it takes a Dr. WPF to figure it out, it's way too difficult! :)
On Wed, Jul 30, 2008 at 8:39 PM, JohnGossman <gossmans...@gmail.com> wrote:
> I'm there for you...
> Seriously though, that does seem to me to be the value of patterns: > you can tell somebody what the code does using fewer words.
> On Jul 30, 5:29 pm, "Dr. WPF" <a...@drwpf.com> wrote:
> > I guess the /en vogue/ term for this type of thing is /"attached > > behavior". /(Thank you Mr. Gossman... you've saved me from the overly > > wordy description about leveraging an attached property to extend a > > class in order to add support for yada yada yada...)
On Wed, Jul 30, 2008 at 10:25 PM, Josh Smith <flappleja...@gmail.com> wrote: > Hey John,
> Any chance this difficulty might be ironed out in a subsequent release of > platform? It's hard to believe that creating a TreeView with checkboxes in > the items, which is easy to navigate via the keyboard and mouse, requires so > much custom work. This should be dead simple, in my opinion. If it takes a > Dr. WPF to figure it out, it's way too difficult! :)
> Josh
> On Wed, Jul 30, 2008 at 8:39 PM, JohnGossman <gossmans...@gmail.com>wrote:
>> I'm there for you...
>> Seriously though, that does seem to me to be the value of patterns: >> you can tell somebody what the code does using fewer words.
>> On Jul 30, 5:29 pm, "Dr. WPF" <a...@drwpf.com> wrote:
>> > I guess the /en vogue/ term for this type of thing is /"attached >> > behavior". /(Thank you Mr. Gossman... you've saved me from the overly >> > wordy description about leveraging an attached property to extend a >> > class in order to add support for yada yada yada...)
Just in case anyone of is wondering how I finally implemented this hacky, ugly solution, I've attached the project. Remove the .DOC extension, and then unzip it. What a hack! Please tell me there's a much simpler, more elegant way!!
> On Wed, Jul 30, 2008 at 10:25 PM, Josh Smith <flappleja...@gmail.com>wrote:
>> Hey John,
>> Any chance this difficulty might be ironed out in a subsequent release of >> platform? It's hard to believe that creating a TreeView with checkboxes in >> the items, which is easy to navigate via the keyboard and mouse, requires so >> much custom work. This should be dead simple, in my opinion. If it takes a >> Dr. WPF to figure it out, it's way too difficult! :)
>> Josh
>> On Wed, Jul 30, 2008 at 8:39 PM, JohnGossman <gossmans...@gmail.com>wrote:
>>> I'm there for you...
>>> Seriously though, that does seem to me to be the value of patterns: >>> you can tell somebody what the code does using fewer words.
>>> On Jul 30, 5:29 pm, "Dr. WPF" <a...@drwpf.com> wrote:
>>> > I guess the /en vogue/ term for this type of thing is /"attached >>> > behavior". /(Thank you Mr. Gossman... you've saved me from the overly
>>> > wordy description about leveraging an attached property to extend a >>> > class in order to add support for yada yada yada...)
On Wed, Jul 30, 2008 at 10:57 PM, Josh Smith <flappleja...@gmail.com> wrote: > Just in case anyone of is wondering how I finally implemented this hacky, > ugly solution, I've attached the project. Remove the .DOC extension, and > then unzip it. What a hack! Please tell me there's a much simpler, more > elegant way!!
> Josh
>> On Wed, Jul 30, 2008 at 10:25 PM, Josh Smith <flappleja...@gmail.com>wrote:
>>> Hey John,
>>> Any chance this difficulty might be ironed out in a subsequent release of >>> platform? It's hard to believe that creating a TreeView with checkboxes in >>> the items, which is easy to navigate via the keyboard and mouse, requires so >>> much custom work. This should be dead simple, in my opinion. If it takes a >>> Dr. WPF to figure it out, it's way too difficult! :)
>>> Josh
>>> On Wed, Jul 30, 2008 at 8:39 PM, JohnGossman <gossmans...@gmail.com>wrote:
>>>> I'm there for you...
>>>> Seriously though, that does seem to me to be the value of patterns: >>>> you can tell somebody what the code does using fewer words.
>>>> On Jul 30, 5:29 pm, "Dr. WPF" <a...@drwpf.com> wrote:
>>>> > I guess the /en vogue/ term for this type of thing is /"attached >>>> > behavior". /(Thank you Mr. Gossman... you've saved me from the overly
>>>> > wordy description about leveraging an attached property to extend a >>>> > class in order to add support for yada yada yada...)
I agree that it would be nice if we could get this behavior by
simply styling the existing TreeView/TreeViewItem, but unfortunately,
without a multiselect TreeView, that’s not possible. (hint hint)
Just to follow up for the rest of the group, I've attached a
version of Josh’s sample that uses the VirtualToggleButton class that
I described earlier. After adding my existing class to the project,
it really was just a matter of pulling out the command bindings and
handlers and adding two lines of markup to the container style:
> I should point out, Dr. WPF's solution is definitely more *elegant*, but an
> order of magnitude more complicated. :)
> On Wed, Jul 30, 2008 at 10:57 PM, Josh Smith <flappleja...@gmail.com> wrote:
>> Just in case anyone of is wondering how I finally implemented this hacky,
>> ugly solution, I've attached the project. Remove the .DOC extension, and
>> then unzip it. What a hack! Please tell me there's a much simpler, more
>> elegant way!!
>> Josh
>>> On Wed, Jul 30, 2008 at 10:25 PM, Josh Smith <flappleja...@gmail.com>wrote:
>>>> Hey John,
>>>> Any chance this difficulty might be ironed out in a subsequent release of
>>>> platform? It's hard to believe that creating a TreeView with
>>>> checkboxes in
>>>> the items, which is easy to navigate via the keyboard and mouse,
>>>> requires so
>>>> much custom work. This should be dead simple, in my opinion.
>>>> If it takes a
>>>> Dr. WPF to figure it out, it's way too difficult! :)
>>>> Josh
>>>> On Wed, Jul 30, 2008 at 8:39 PM, JohnGossman <gossmans...@gmail.com>wrote:
>>>>> I'm there for you...
>>>>> Seriously though, that does seem to me to be the value of patterns:
>>>>> you can tell somebody what the code does using fewer words.
>>>>> On Jul 30, 5:29 pm, "Dr. WPF" <a...@drwpf.com> wrote:
>>>>> > I guess the /en vogue/ term for this type of thing is /"attached
>>>>> > behavior". /(Thank you Mr. Gossman... you've saved me from the overly
>>>>> > wordy description about leveraging an attached property to extend a
>>>>> > class in order to add support for yada yada yada...)
On Thu, Jul 31, 2008 at 7:42 AM, Dr. WPF <a...@drwpf.com> wrote:
> I agree that it would be nice if we could get this behavior by simply
> styling the existing TreeView/TreeViewItem, but unfortunately, without a
> multiselect TreeView, that's not possible. (hint hint)
> Just to follow up for the rest of the group, I've attached a version of
> Josh's sample that uses the VirtualToggleButton class that I described
> earlier. After adding my existing class to the project, it really was
> just a matter of pulling out the command bindings and handlers and adding
> two lines of markup to the container style:
> > I should point out, Dr. WPF's solution is definitely more *elegant*, but
> an
> > order of magnitude more complicated. :)
> > On Wed, Jul 30, 2008 at 10:57 PM, Josh Smith <flappleja...@gmail.com>
> wrote:
> >> Just in case anyone of is wondering how I finally implemented this
> hacky,
> >> ugly solution, I've attached the project. Remove the .DOC extension,
> and
> >> then unzip it. What a hack! Please tell me there's a much simpler,
> more
> >> elegant way!!
> >> Josh
> >>> On Wed, Jul 30, 2008 at 10:25 PM, Josh Smith <flappleja...@gmail.com
> >wrote:
> >>>> Hey John,
> >>>> Any chance this difficulty might be ironed out in a subsequent release
> of
> >>>> platform? It's hard to believe that creating a TreeView with
> >>>> checkboxes in
> >>>> the items, which is easy to navigate via the keyboard and mouse,
> >>>> requires so
> >>>> much custom work. This should be dead simple, in my opinion. If
> >>>> it takes a
> >>>> Dr. WPF to figure it out, it's way too difficult! :)
> >>>> Josh
> >>>> On Wed, Jul 30, 2008 at 8:39 PM, JohnGossman <gossmans...@gmail.com
> >wrote:
> >>>>> I'm there for you...
> >>>>> Seriously though, that does seem to me to be the value of patterns:
> >>>>> you can tell somebody what the code does using fewer words.
> >>>>> > I guess the /en vogue/ term for this type of thing is /"attached
> >>>>> > behavior". /(Thank you Mr. Gossman... you've saved me from the
> overly
> >>>>> > wordy description about leveraging an attached property to extend a
> >>>>> > class in order to add support for yada yada yada...)
OK, I'm sold. Your solution is both more elegant and simpler, considering
that it's "write once, use anywhere." Hey Doc, do you mind if I blog about
this, or perhaps write a CodeProject article that has both of us as the
authors?
On a side note, you might have noticed that I specifically set the theme of
this Window to Royale.NormalColor. The reason I did that is because there
is a bug in the CheckBox theme for Aero and Classic!! When a CheckBox goes
from 'indeterminate' state to 'checked' state in the Aero theme, you need to
mouse over the control for the indeterminate state visual to go away. Also,
when Windows is using the Classic theme, the Foreground of the CheckBox is
used for the checkmark, which means that you cannot see it when it is
selected (and using a light foreground for selection). That really sucks!!
If I can muster the enthusiasm, I'll log it on Connect...
On Thu, Jul 31, 2008 at 1:42 AM, Dr. WPF <a...@drwpf.com> wrote:
> I agree that it would be nice if we could get this behavior by simply
> styling the existing TreeView/TreeViewItem, but unfortunately, without a
> multiselect TreeView, that's not possible. (hint hint)
> Just to follow up for the rest of the group, I've attached a version of
> Josh's sample that uses the VirtualToggleButton class that I described
> earlier. After adding my existing class to the project, it really was
> just a matter of pulling out the command bindings and handlers and adding
> two lines of markup to the container style:
> > I should point out, Dr. WPF's solution is definitely more *elegant*, but
> an
> > order of magnitude more complicated. :)
> > On Wed, Jul 30, 2008 at 10:57 PM, Josh Smith <flappleja...@gmail.com>
> wrote:
> >> Just in case anyone of is wondering how I finally implemented this
> hacky,
> >> ugly solution, I've attached the project. Remove the .DOC extension,
> and
> >> then unzip it. What a hack! Please tell me there's a much simpler,
> more
> >> elegant way!!
> >> Josh
> >>> On Wed, Jul 30, 2008 at 10:25 PM, Josh Smith <flappleja...@gmail.com
> >wrote:
> >>>> Hey John,
> >>>> Any chance this difficulty might be ironed out in a subsequent release
> of
> >>>> platform? It's hard to believe that creating a TreeView with
> >>>> checkboxes in
> >>>> the items, which is easy to navigate via the keyboard and mouse,
> >>>> requires so
> >>>> much custom work. This should be dead simple, in my opinion. If
> >>>> it takes a
> >>>> Dr. WPF to figure it out, it's way too difficult! :)
> >>>> Josh
> >>>> On Wed, Jul 30, 2008 at 8:39 PM, JohnGossman <gossmans...@gmail.com
> >wrote:
> >>>>> I'm there for you...
> >>>>> Seriously though, that does seem to me to be the value of patterns:
> >>>>> you can tell somebody what the code does using fewer words.
> >>>>> > I guess the /en vogue/ term for this type of thing is /"attached
> >>>>> > behavior". /(Thank you Mr. Gossman... you've saved me from the
> overly
> >>>>> > wordy description about leveraging an attached property to extend a
> >>>>> > class in order to add support for yada yada yada...)
Hey Doc, I've been reviewing your solution more closely. This is
AWESOME!! We, I, or you need to publish this, if not only to show people
how powerful attached properties and routed events can be! Very nice...
On Thu, Jul 31, 2008 at 1:42 AM, Dr. WPF <a...@drwpf.com> wrote:
> I agree that it would be nice if we could get this behavior by simply
> styling the existing TreeView/TreeViewItem, but unfortunately, without a
> multiselect TreeView, that's not possible. (hint hint)
> Just to follow up for the rest of the group, I've attached a version of
> Josh's sample that uses the VirtualToggleButton class that I described
> earlier. After adding my existing class to the project, it really was
> just a matter of pulling out the command bindings and handlers and adding
> two lines of markup to the container style:
> > I should point out, Dr. WPF's solution is definitely more *elegant*, but
> an
> > order of magnitude more complicated. :)
> > On Wed, Jul 30, 2008 at 10:57 PM, Josh Smith <flappleja...@gmail.com>
> wrote:
> >> Just in case anyone of is wondering how I finally implemented this
> hacky,
> >> ugly solution, I've attached the project. Remove the .DOC extension,
> and
> >> then unzip it. What a hack! Please tell me there's a much simpler,
> more
> >> elegant way!!
> >> Josh
> >>> On Wed, Jul 30, 2008 at 10:25 PM, Josh Smith <flappleja...@gmail.com
> >wrote:
> >>>> Hey John,
> >>>> Any chance this difficulty might be ironed out in a subsequent release
> of
> >>>> platform? It's hard to believe that creating a TreeView with
> >>>> checkboxes in
> >>>> the items, which is easy to navigate via the keyboard and mouse,
> >>>> requires so
> >>>> much custom work. This should be dead simple, in my opinion. If
> >>>> it takes a
> >>>> Dr. WPF to figure it out, it's way too difficult! :)
> >>>> Josh
> >>>> On Wed, Jul 30, 2008 at 8:39 PM, JohnGossman <gossmans...@gmail.com
> >wrote:
> >>>>> I'm there for you...
> >>>>> Seriously though, that does seem to me to be the value of patterns:
> >>>>> you can tell somebody what the code does using fewer words.
> >>>>> > I guess the /en vogue/ term for this type of thing is /"attached
> >>>>> > behavior". /(Thank you Mr. Gossman... you've saved me from the
> overly
> >>>>> > wordy description about leveraging an attached property to extend a
> >>>>> > class in order to add support for yada yada yada...)
I've fixed up the implementation a bit, so the user can click on the text in
the treeviewitem and it won't modify the checkstate. I also optimized the
checkstate verification logic (FooViewModel's IsChecked #region). The
updated copy, which uses the Doc's VirtualToggleButton coolness, is
attached. Just waiting for the good Doctor to give me a thumbs-up to write
about this stuff..... ;)
On Thu, Jul 31, 2008 at 8:17 AM, Josh Smith <flappleja...@gmail.com> wrote:
> Hey Doc, I've been reviewing your solution more closely. This is
> AWESOME!! We, I, or you need to publish this, if not only to show people
> how powerful attached properties and routed events can be! Very nice...
> Josh
> On Thu, Jul 31, 2008 at 1:42 AM, Dr. WPF <a...@drwpf.com> wrote:
>> I agree that it would be nice if we could get this behavior by simply
>> styling the existing TreeView/TreeViewItem, but unfortunately, without a
>> multiselect TreeView, that's not possible. (hint hint)
>> Just to follow up for the rest of the group, I've attached a version of
>> Josh's sample that uses the VirtualToggleButton class that I described
>> earlier. After adding my existing class to the project, it really was
>> just a matter of pulling out the command bindings and handlers and adding
>> two lines of markup to the container style:
>> > I should point out, Dr. WPF's solution is definitely more *elegant*, but
>> an
>> > order of magnitude more complicated. :)
>> > On Wed, Jul 30, 2008 at 10:57 PM, Josh Smith <flappleja...@gmail.com>
>> wrote:
>> >> Just in case anyone of is wondering how I finally implemented this
>> hacky,
>> >> ugly solution, I've attached the project. Remove the .DOC extension,
>> and
>> >> then unzip it. What a hack! Please tell me there's a much simpler,
>> more
>> >> elegant way!!
>> >> Josh
>> >>> On Wed, Jul 30, 2008 at 10:25 PM, Josh Smith <flappleja...@gmail.com
>> >wrote:
>> >>>> Hey John,
>> >>>> Any chance this difficulty might be ironed out in a subsequent
>> release of
>> >>>> platform? It's hard to believe that creating a TreeView with
>> >>>> checkboxes in
>> >>>> the items, which is easy to navigate via the keyboard and mouse,
>> >>>> requires so
>> >>>> much custom work. This should be dead simple, in my opinion. If
>> >>>> it takes a
>> >>>> Dr. WPF to figure it out, it's way too difficult! :)
>> >>>> Josh
>> >>>> On Wed, Jul 30, 2008 at 8:39 PM, JohnGossman <gossmans...@gmail.com
>> >wrote:
>> >>>>> I'm there for you...
>> >>>>> Seriously though, that does seem to me to be the value of patterns:
>> >>>>> you can tell somebody what the code does using fewer words.
>> >>>>> > I guess the /en vogue/ term for this type of thing is
>> /"attached
>> >>>>> > behavior". /(Thank you Mr. Gossman... you've saved me from the
>> overly
>> >>>>> > wordy description about leveraging an attached property to extend
>> a
>> >>>>> > class in order to add support for yada yada yada...)
Doc, thats a fine use of Attached Properties! I was trying to abstract
this a little more for my own needs since I have a TreeViewItem that
has multiple controls, which may need focus.
In your implementation, you are setting Focusable=false and then using
Bindings to show the checked state. In other words we are implementing
a state-machine for each TreeViewItem. If I had to extrapolate for a
TreeViewItem that has multiple controls like a CheckBox + TextBox, how
would you suggest I go about. Right now I am trying to add more states
to my simple StateMachine for each TreeViewItem and forcing a focus()
on the TextBox ...
Would love to hear your views.
Once again, Great job!!
On Jul 31, 9:00 am, "Josh Smith" <flappleja...@gmail.com> wrote:
> I've fixed up the implementation a bit, so the user can click on the text in
> the treeviewitem and it won't modify the checkstate. I also optimized the
> checkstate verification logic (FooViewModel's IsChecked #region). The
> updated copy, which uses the Doc's VirtualToggleButton coolness, is
> attached. Just waiting for the good Doctor to give me a thumbs-up to write
> about this stuff..... ;)
> Josh
> On Thu, Jul 31, 2008 at 8:17 AM, Josh Smith <flappleja...@gmail.com> wrote:
> > Hey Doc, I've been reviewing your solution more closely. This is
> > AWESOME!! We, I, or you need to publish this, if not only to show people
> > how powerful attached properties and routed events can be! Very nice...
> > Josh
> > On Thu, Jul 31, 2008 at 1:42 AM, Dr. WPF <a...@drwpf.com> wrote:
> >> I agree that it would be nice if we could get this behavior by simply
> >> styling the existing TreeView/TreeViewItem, but unfortunately, without a
> >> multiselect TreeView, that's not possible. (hint hint)
> >> Just to follow up for the rest of the group, I've attached a version of
> >> Josh's sample that uses the VirtualToggleButton class that I described
> >> earlier. After adding my existing class to the project, it really was
> >> just a matter of pulling out the command bindings and handlers and adding
> >> two lines of markup to the container style:
> >> > I should point out, Dr. WPF's solution is definitely more *elegant*, but
> >> an
> >> > order of magnitude more complicated. :)
> >> > On Wed, Jul 30, 2008 at 10:57 PM, Josh Smith <flappleja...@gmail.com>
> >> wrote:
> >> >> Just in case anyone of is wondering how I finally implemented this
> >> hacky,
> >> >> ugly solution, I've attached the project. Remove the .DOC extension,
> >> and
> >> >> then unzip it. What a hack! Please tell me there's a much simpler,
> >> more
> >> >> elegant way!!
> >> >> Josh
> >> >>> On Wed, Jul 30, 2008 at 10:25 PM, Josh Smith <flappleja...@gmail.com
> >> >wrote:
> >> >>>> Hey John,
> >> >>>> Any chance this difficulty might be ironed out in a subsequent
> >> release of
> >> >>>> platform? It's hard to believe that creating a TreeView with
> >> >>>> checkboxes in
> >> >>>> the items, which is easy to navigate via the keyboard and mouse,
> >> >>>> requires so
> >> >>>> much custom work. This should be dead simple, in my opinion. If
> >> >>>> it takes a
> >> >>>> Dr. WPF to figure it out, it's way too difficult! :)
> >> >>>> Josh
> >> >>>> On Wed, Jul 30, 2008 at 8:39 PM, JohnGossman <gossmans...@gmail.com
> >> >wrote:
> >> >>>>> I'm there for you...
> >> >>>>> Seriously though, that does seem to me to be the value of patterns:
> >> >>>>> you can tell somebody what the code does using fewer words.
> >> >>>>> > I guess the /en vogue/ term for this type of thing is
> >> /"attached
> >> >>>>> > behavior". /(Thank you Mr. Gossman... you've saved me from the
> >> overly
> >> >>>>> > wordy description about leveraging an attached property to extend
> >> a
> >> >>>>> > class in order to add support for yada yada yada...)
