{"id":751,"date":"2010-12-02T16:53:27","date_gmt":"2010-12-02T21:53:27","guid":{"rendered":"http:\/\/www.ikriv.com\/blog\/?p=751"},"modified":"2010-12-02T16:53:27","modified_gmt":"2010-12-02T21:53:27","slug":"wpf-passing-data-to-sub-views-via-datacontext-causes-trouble","status":"publish","type":"post","link":"https:\/\/ikriv.com\/blog\/?p=751","title":{"rendered":"WPF: Passing Data to Sub-Views via DataContext Causes Trouble"},"content":{"rendered":"

Imagine I have a main view that contains a number to sub-views. To be concrete, let’s assume that the sub-view is a user control of type PersonView<\/code> that displays person’s information.<\/p>\n

How do you tell the PersonView<\/code> what person to display? Passing it via DataContext<\/code> seems like a natural choice, so the XAML looks something liek this:<\/p>\n

<StackPanel ...>\n   <my:PersonView DataContext={Binding PersonA} \/>\n   <my:PersonView DataContext={Binding PersonB} \/>\n<\/StackPanel><\/code><\/pre>\n
This is all fine until I try to set other properties of PersonView<\/code>, e.g.<\/p>\n
<my:PersonView Visibility={Binding IsPersonAVisible} DataContext={Binding PersonA} \/><\/p>\n
The IsPersonAVisible<\/code> binding does not work. The system first binds the DataContext<\/code> property to the PersonA<\/code> object, and then all other bindings are processed against PersonA<\/code>. Since PersonA<\/code> does not have \"IsPersonAVisible\", the binding fails.<\/p>\n
Microsoft representatives confirm this and provide some explanation why it should be so<\/a>, but personally I think it does not sound very convincing.<\/p>\n
We can make the binding work by diverting it away from the redirected DataContext<\/code>, e.g. by specifying ElementName:<\/p>\n
<my:PersonView\n    Visibility={Binding DataContext.IsPersonAVisible, ElementName=MainWindow}\n    DataContext={Binding PersonA} \/><\/code><\/pre>\n
but it looks very ugly and long.<\/p>\n
We have two ways to avoid this ugliness:
\n- move the properties into the PersonA<\/code> object
\n- use property other than DataContext<\/code> to pass person information.<\/p>\n
The former does not really solve the problem. Even if we have PersonA.IsVisible<\/code>, it most likely will depend on some external data, and we will need to write code to set it duplicating the work the binding would do for us.<\/p>\n
The latter wrecks havoc in the bindings of the PersonView<\/code> itself, but this can be rectified. When we passed person information via DataContext<\/code>, the PersonView<\/code> looked probably something like this:<\/p>\n
<UserControl ...>\n    <StackPanel>\n        <TextBlock Text=\"{Binding FirstName}\" \/>\n        <TextBlock Text=\"{Binding LastName}\" FontWeight=\"Bold\" \/>\n    <\/StackPanel>\n<\/UserControl><\/code><\/pre>\n
If we now pass person information in control property like Person<\/code>, all bindings will stop working. We can fix it by setting DataContext<\/code> on the main visual, so it can done only once:<\/p>\n
<UserControl ...>\n    <StackPanel DataContext=\"{Binding Person, RelativeSource={RelativeSource AncestorType=UserControl}}\"<\/b>>\n        <TextBlock Text=\"{Binding FirstName}\" \/>\n        <TextBlock Text=\"{Binding LastName}\" FontWeight=\"Bold\" \/>\n    <\/StackPanel>\n<\/UserControl><\/code><\/pre>\n
Now, things are back to normal, and we have only one ugly binding. Note, that setting data context on the user control itself won't help, because it will lead to the same problem as before.
\nCodeProject<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
Imagine I have a main view that contains a number to sub-views. To be concrete, let’s assume that the sub-view is a user control of type PersonView that displays person’s […]<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"Layout":"","footnotes":""},"categories":[4,12],"tags":[],"class_list":["entry","author-ikriv","post-751","post","type-post","status-publish","format-standard","category-hack","category-wpf"],"_links":{"self":[{"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/751","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=751"}],"version-history":[{"count":0,"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/751\/revisions"}],"wp:attachment":[{"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=751"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=751"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=751"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}