No CheckBox.CheckedChanged?

It'd be nice if CheckBox had a CheckedChanged eventhandler instead of/in
addition to the two separate Checked and Unchecked events.

You can bind to the IsChecked property to get a method called with the
current value of the IsChecked property whenever it changes.

Michael
(C# / WPF MVP)
http://spaces.msn.com/members/michaellatta

"RyanLeeSchneider" <RyanLeeSchneider@discussions.microsoft.com> wrote in
message news:C74B1151-EE56-40BF-87CD-D91D3732DE27@microsoft.com...
>
> It'd be nice if CheckBox had a CheckedChanged eventhandler instead of/in
> addition to the two separate Checked and Unchecked events.

You lost me, wouldn't the binding go the other way? (e.g. if I changed the
bound property the checkbox's checked state would change)

"Michael Latta" wrote:

> You can bind to the IsChecked property to get a method called with the
> current value of the IsChecked property whenever it changes.
>
> Michael
> (C# / WPF MVP)
> http://spaces.msn.com/members/michaellatta
>
> "RyanLeeSchneider" <RyanLeeSchneider@discussions.microsoft.com> wrote in
> message news:C74B1151-EE56-40BF-87CD-D91D3732DE27@microsoft.com...
> >
> > It'd be nice if CheckBox had a CheckedChanged eventhandler instead of/in
> > addition to the two separate Checked and Unchecked events.
>
>
>

You can create a property that is bound to the IsChecked property of the
control. When the user checks the check box your property setter will be
invoked for bi-directional binding. You can place in the setter either your
logic or a call to a method that will respond to the changes in state.

Michael
(C#/WPF MVP)
http://spaces.msn.com/members/michaellatta

"RyanLeeSchneider" <RyanLeeSchneider@discussions.microsoft.com> wrote in
message news:A0AC8F75-F099-4E0A-B25A-15EF5A6ED928@microsoft.com...
>
> You lost me, wouldn't the binding go the other way? (e.g. if I changed the
> bound property the checkbox's checked state would change)
>
> "Michael Latta" wrote:
>
>> You can bind to the IsChecked property to get a method called with the
>> current value of the IsChecked property whenever it changes.
>>
>> Michael
>> (C# / WPF MVP)
>> http://spaces.msn.com/members/michaellatta
>>
>> "RyanLeeSchneider" <RyanLeeSchneider@discussions.microsoft.com> wrote in
>> message news:C74B1151-EE56-40BF-87CD-D91D3732DE27@microsoft.com...
>> >
>> > It'd be nice if CheckBox had a CheckedChanged eventhandler instead
>> > of/in
>> > addition to the two separate Checked and Unchecked events.
>>
>>
>>

What I don't like about that is then my data object has UI-specific code in
it.

In my scenario, I'm using checkboxes to 'select' nodes of a treeview for
batch-processing. The caveat is that the data objects I am bound to don't
(and cannot because they are used in other projects) have references to the
WinFX runtime.

I'd like to use style triggers to highlight the nodes (bold if all childern
are selected, italics if some, normal if none) ala the WPF folder picker
sample from okoboji. However, I don't want to clutter up my 'pure' data
objects with UI-specific properties.

What would people suggest in that scenario? Currently, I'm thinking of
having a 'shadow' heirarchical data object that contains the UI-specific
properties for my treeview, and use a separate datasource to bind things like
my checkbox to that. Sound reasonable?

"Michael Latta" wrote:

> You can create a property that is bound to the IsChecked property of the
> control. When the user checks the check box your property setter will be
> invoked for bi-directional binding. You can place in the setter either your
> logic or a call to a method that will respond to the changes in state.
>
> Michael
> (C#/WPF MVP)
> http://spaces.msn.com/members/michaellatta
>
> "RyanLeeSchneider" <RyanLeeSchneider@discussions.microsoft.com> wrote in
> message news:A0AC8F75-F099-4E0A-B25A-15EF5A6ED928@microsoft.com...
> >
> > You lost me, wouldn't the binding go the other way? (e.g. if I changed the
> > bound property the checkbox's checked state would change)
> >
> > "Michael Latta" wrote:
> >
> >> You can bind to the IsChecked property to get a method called with the
> >> current value of the IsChecked property whenever it changes.
> >>
> >> Michael
> >> (C# / WPF MVP)
> >> http://spaces.msn.com/members/michaellatta
> >>
> >> "RyanLeeSchneider" <RyanLeeSchneider@discussions.microsoft.com> wrote in
> >> message news:C74B1151-EE56-40BF-87CD-D91D3732DE27@microsoft.com...
> >> >
> >> > It'd be nice if CheckBox had a CheckedChanged eventhandler instead
> >> > of/in
> >> > addition to the two separate Checked and Unchecked events.
> >>
> >>
> >>
>
>
>

I think what Michael was suggesting was something like this:

class MyDataObject
{
public bool Selected
{
set { ... }
}
}

<CheckBox IsChecked="{Binding Path=Selected, Mode=OneWayToSource}" />

This doesn't place any dependencies to WPF in your model. But if you still
want to keep this out of the model, then yes creating a shadow model is common
practice. Effectively this is the ViewModel from the "Model View ViewModel"
pattern that a few people have been throwing around.

- Doug

> What I don't like about that is then my data object has UI-specific
> code in it.
>
> In my scenario, I'm using checkboxes to 'select' nodes of a treeview
> for batch-processing. The caveat is that the data objects I am bound
> to don't (and cannot because they are used in other projects) have
> references to the WinFX runtime.
>
> I'd like to use style triggers to highlight the nodes (bold if all
> childern are selected, italics if some, normal if none) ala the WPF
> folder picker sample from okoboji. However, I don't want to clutter
> up my 'pure' data objects with UI-specific properties.
>
> What would people suggest in that scenario? Currently, I'm thinking
> of having a 'shadow' heirarchical data object that contains the
> UI-specific properties for my treeview, and use a separate datasource
> to bind things like my checkbox to that. Sound reasonable?
>
> "Michael Latta" wrote:
>
>> You can create a property that is bound to the IsChecked property of
>> the control. When the user checks the check box your property setter
>> will be invoked for bi-directional binding. You can place in the
>> setter either your logic or a call to a method that will respond to
>> the changes in state.
>>
>> Michael
>> (C#/WPF MVP)
>> http://spaces.msn.com/members/michaellatta
>> "RyanLeeSchneider" <RyanLeeSchneider@discussions.microsoft.com> wrote
>> in message news:A0AC8F75-F099-4E0A-B25A-15EF5A6ED928@microsoft.com...
>>
>>> You lost me, wouldn't the binding go the other way? (e.g. if I
>>> changed the bound property the checkbox's checked state would
>>> change)
>>>
>>> "Michael Latta" wrote:
>>>
>>>> You can bind to the IsChecked property to get a method called with
>>>> the current value of the IsChecked property whenever it changes.
>>>>
>>>> Michael
>>>> (C# / WPF MVP)
>>>> http://spaces.msn.com/members/michaellatta
>>>> "RyanLeeSchneider" <RyanLeeSchneider@discussions.microsoft.com>
>>>> wrote in message
>>>> news:C74B1151-EE56-40BF-87CD-D91D3732DE27@microsoft.com...
>>>>
>>>>> It'd be nice if CheckBox had a CheckedChanged eventhandler instead
>>>>> of/in
>>>>> addition to the two separate Checked and Unchecked events.

This was the basic idea. If you do not need to persist the selection state,
then just use the UI elements directly. You can either use a specialization
of TreeViewItem or use a UI specific object that binds to the pure data
object. You can use a value converter to introduce the UI specific wrapper
object in the binding process then hang any properties you want off that
wrapper object. If you need to persist the wrapper objects, then it gets a
bit trickier, but you can still let the UI drive this. You just need to be
a bit trickier about hooking the wrapper objects up into a hierarchy as part
of your value converter.

Michael



"Douglas Stockwell" <doug@remove.11011.net> wrote in message
news:eca9ec38f16b18c7eed28e899960@news.microsoft.com...
>I think what Michael was suggesting was something like this:
>
> class MyDataObject
> {
> public bool Selected
> {
> set { ... }
> }
> }
>
> <CheckBox IsChecked="{Binding Path=Selected, Mode=OneWayToSource}" />
>
> This doesn't place any dependencies to WPF in your model. But if you still
> want to keep this out of the model, then yes creating a shadow model is
> common practice. Effectively this is the ViewModel from the "Model View
> ViewModel" pattern that a few people have been throwing around.
>
> - Doug
>
>> What I don't like about that is then my data object has UI-specific
>> code in it.
>>
>> In my scenario, I'm using checkboxes to 'select' nodes of a treeview
>> for batch-processing. The caveat is that the data objects I am bound
>> to don't (and cannot because they are used in other projects) have
>> references to the WinFX runtime.
>>
>> I'd like to use style triggers to highlight the nodes (bold if all
>> childern are selected, italics if some, normal if none) ala the WPF
>> folder picker sample from okoboji. However, I don't want to clutter
>> up my 'pure' data objects with UI-specific properties.
>>
>> What would people suggest in that scenario? Currently, I'm thinking
>> of having a 'shadow' heirarchical data object that contains the
>> UI-specific properties for my treeview, and use a separate datasource
>> to bind things like my checkbox to that. Sound reasonable?
>>
>> "Michael Latta" wrote:
>>
>>> You can create a property that is bound to the IsChecked property of
>>> the control. When the user checks the check box your property setter
>>> will be invoked for bi-directional binding. You can place in the
>>> setter either your logic or a call to a method that will respond to
>>> the changes in state.
>>>
>>> Michael
>>> (C#/WPF MVP)
>>> http://spaces.msn.com/members/michaellatta
>>> "RyanLeeSchneider" <RyanLeeSchneider@discussions.microsoft.com> wrote
>>> in message news:A0AC8F75-F099-4E0A-B25A-15EF5A6ED928@microsoft.com...
>>>
>>>> You lost me, wouldn't the binding go the other way? (e.g. if I
>>>> changed the bound property the checkbox's checked state would
>>>> change)
>>>>
>>>> "Michael Latta" wrote:
>>>>
>>>>> You can bind to the IsChecked property to get a method called with
>>>>> the current value of the IsChecked property whenever it changes.
>>>>>
>>>>> Michael
>>>>> (C# / WPF MVP)
>>>>> http://spaces.msn.com/members/michaellatta
>>>>> "RyanLeeSchneider" <RyanLeeSchneider@discussions.microsoft.com>
>>>>> wrote in message
>>>>> news:C74B1151-EE56-40BF-87CD-D91D3732DE27@microsoft.com...
>>>>>
>>>>>> It'd be nice if CheckBox had a CheckedChanged eventhandler instead
>>>>>> of/in
>>>>>> addition to the two separate Checked and Unchecked events.
>
>