What is DataContext for?
As a continuation of the question Linking DataContext with another property in WPF.
At the very end of the research I was very surprised to find out that when one writes something like that:
<Label Content="Binding Path=Name" />
The DataContext
against which the Content
property is binded is of the Label
control itself! The fact that it still works is due to the default inheritance of the DataContext value from the nearest parent.
But if you have this label wrapped in a custom control, and you don't want to bind your data to the DataContext
property of that control, you would more likely love to have:
<Controls:SearchSettings Settings="Binding Path=Settings" />
And here you are. Now you need to set Settings
as the DataContext
for the SearchSettings
control, for Label
inside to bind against, but you can't, because that will trigger re-binding of Settings
property.
I can't see the point in mixing binding properties using different sources: DataContext
, by ElementName
, etc.
So why would I ever use DataContext
?
wpf data-binding
add a comment |
As a continuation of the question Linking DataContext with another property in WPF.
At the very end of the research I was very surprised to find out that when one writes something like that:
<Label Content="Binding Path=Name" />
The DataContext
against which the Content
property is binded is of the Label
control itself! The fact that it still works is due to the default inheritance of the DataContext value from the nearest parent.
But if you have this label wrapped in a custom control, and you don't want to bind your data to the DataContext
property of that control, you would more likely love to have:
<Controls:SearchSettings Settings="Binding Path=Settings" />
And here you are. Now you need to set Settings
as the DataContext
for the SearchSettings
control, for Label
inside to bind against, but you can't, because that will trigger re-binding of Settings
property.
I can't see the point in mixing binding properties using different sources: DataContext
, by ElementName
, etc.
So why would I ever use DataContext
?
wpf data-binding
add a comment |
As a continuation of the question Linking DataContext with another property in WPF.
At the very end of the research I was very surprised to find out that when one writes something like that:
<Label Content="Binding Path=Name" />
The DataContext
against which the Content
property is binded is of the Label
control itself! The fact that it still works is due to the default inheritance of the DataContext value from the nearest parent.
But if you have this label wrapped in a custom control, and you don't want to bind your data to the DataContext
property of that control, you would more likely love to have:
<Controls:SearchSettings Settings="Binding Path=Settings" />
And here you are. Now you need to set Settings
as the DataContext
for the SearchSettings
control, for Label
inside to bind against, but you can't, because that will trigger re-binding of Settings
property.
I can't see the point in mixing binding properties using different sources: DataContext
, by ElementName
, etc.
So why would I ever use DataContext
?
wpf data-binding
As a continuation of the question Linking DataContext with another property in WPF.
At the very end of the research I was very surprised to find out that when one writes something like that:
<Label Content="Binding Path=Name" />
The DataContext
against which the Content
property is binded is of the Label
control itself! The fact that it still works is due to the default inheritance of the DataContext value from the nearest parent.
But if you have this label wrapped in a custom control, and you don't want to bind your data to the DataContext
property of that control, you would more likely love to have:
<Controls:SearchSettings Settings="Binding Path=Settings" />
And here you are. Now you need to set Settings
as the DataContext
for the SearchSettings
control, for Label
inside to bind against, but you can't, because that will trigger re-binding of Settings
property.
I can't see the point in mixing binding properties using different sources: DataContext
, by ElementName
, etc.
So why would I ever use DataContext
?
wpf data-binding
wpf data-binding
edited May 23 '17 at 11:47
Community♦
11
11
asked Aug 31 '11 at 19:10
Eugene StrizhokEugene Strizhok
5952919
5952919
add a comment |
add a comment |
4 Answers
4
active
oldest
votes
When you write
<Label name="myLabel" Content="Binding Path=Name" />
you are binding to myLabel.DataContext.Name
, and not myLabel.Name
.
The XAML in WPF is just a pretty user interface to display and interact with the actual data, otherwise known as the DataContext
. The purpose of other binding sources (RelativeSource
, ElementName
, etc) is to point to another property that doesn't exist in the current control's DataContext
So suppose you have a Window. Without setting the DataContext, the window still displays but there is no data behind it.
Now suppose to set myWindow.DataContext = new ClassA();
. Now the data that the window is displaying is ClassA
. If ClassA
has a property called Name
, I could write a label and bind it to Name
(such as your example), and whatever value is stored in ClassA.Name
would get displayed.
Now, suppose ClassA
has a property of ClassB
and both classes have a property called Name
. Here is a block of XAML which illustrates the purpose of the DataContext, and an example of how a control would refer to a property not in it's own DataContext
<Window x:Name="myWindow"> <!-- DataContext is set to ClassA -->
<StackPanel> <!-- DataContext is set to ClassA -->
<!-- DataContext is set to ClassA, so will display ClassA.Name -->
<Label Content="Binding Name" />
<!-- DataContext is still ClassA, however we are setting it to ClassA.ClassB -->
<StackPanel DataContext="Binding ClassB">
<!-- DataContext is set to ClassB, so will display ClassB.Name -->
<Label Content="Binding Name" />
<!-- DataContext is still ClassB, but we are binding to the Window's DataContext.Name which is ClassA.Name -->
<Label Content="Binding ElementName=myWindow, Path=DataContext.Name" />
</StackPanel>
</StackPanel>
</Window>
As you can see, the DataContext is based on whatever data is behind the UI object.
Update: I see this question so often from new WPF users that I expanded this answer into a post on my blog: What is this “DataContext” you speak of?
Hi! Thanks for the detailed answer. But. What I don't like in you example is that you binding the DataContext property itself. Most probably I would extract StackPanel in your example into a separate control. It makes sense if its DataContext is just aт isolated part of DataContext of its parent, doesn't it? And then I wouldn't bind the DataContext property of my user control, but would rather have a special property with self-descriptive name. (I mean what is a DataContext for a particular control? What should I pass in?) And this is there the things get complicated. [To be continued]
– Eugene Strizhok
Sep 1 '11 at 20:16
As I would not bind the DataContext property, it would be taken from a parent control. Which means I am not longer able to bind controls inside my custom control against DataContext, just because I don't know what's in there (the control can't control whose child it will be, and what DataContext it will receive). The solution could be to set DataContext from inside to control (using a value from that special property). [To be continued]
– Eugene Strizhok
Sep 1 '11 at 20:17
But this will break binding of control itself, because, as you pointed out, having writtenContent=Binding Name
one binds toLabel.DataContext.Name
and not toLabel.Parent.DataContext.Name
as I would expect it to do.
– Eugene Strizhok
Sep 1 '11 at 20:17
@Eugene You want to make a new UserControl (Or DataTemplate) if it is logical to do so. Quite often that is not the case, and it is easier to bind something's DataContext than to bind to the same property multiple times.
– Rachel
Sep 2 '11 at 1:50
4
@Eugene I would highly recommend you look into the MVVM Design Pattern. In my opinion it should be used with any WPF application, and you will get a better understanding of the DataContext and it's importance. Your visual controls are NOT your application - your DataContext (ViewModels) are. The visual controls (labels, buttons, textboxes, etc) are simply a nice UI that allows users to interact with your application.
– Rachel
Sep 2 '11 at 14:31
|
show 1 more comment
From CodeProject by kishore Gaddam:
DataContext
is one of the most fundamental concepts in Data Binding. The Binding object needs to get its data from somewhere, and there are a few ways to specify the source of the data like using Source property directly in the Binding, inheriting aDataContext
from the nearest element when traversing up in the tree, setting theElementName
andRelativeSource
properties in the Binding object.
Detailed example on CodeProject: http://www.codeproject.com/Articles/321899/DataContext-in-WPF
add a comment |
In that particular case, you could do:
<Controls:SearchSettings DataContext="Binding Path=Settings" Settings="Binding" />
Assuming you want everything that may be content of the SearchSettings to use Settings as it's data context. Basically, the DataContext affects the element itself an any descendants that don't explicitly override it.
add a comment |
In most cases you do want to bind to the DataContext, in some templates on ItemsControls it is the only way to bind to the currently templated item for example. Further bindings to the DataContext are nice to write and read as they are concise.
In your example you can still set the DataContext, you only need to modify the binding on the Settings respectively:
<Controls:SearchSettings DataContext="Binding Settings" Settings="Binding"/>
I thought of this approach, but it doesn't make sense. Why should I bind two properties, if I only need one?
– Eugene Strizhok
Sep 1 '11 at 20:21
@EugeneStrizhok: You do not only need one, this allows you to bind to the Settings in the child controls without setting a source because you now can use the DataContext.
– H.B.
Sep 1 '11 at 21:09
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f7262137%2fwhat-is-datacontext-for%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
When you write
<Label name="myLabel" Content="Binding Path=Name" />
you are binding to myLabel.DataContext.Name
, and not myLabel.Name
.
The XAML in WPF is just a pretty user interface to display and interact with the actual data, otherwise known as the DataContext
. The purpose of other binding sources (RelativeSource
, ElementName
, etc) is to point to another property that doesn't exist in the current control's DataContext
So suppose you have a Window. Without setting the DataContext, the window still displays but there is no data behind it.
Now suppose to set myWindow.DataContext = new ClassA();
. Now the data that the window is displaying is ClassA
. If ClassA
has a property called Name
, I could write a label and bind it to Name
(such as your example), and whatever value is stored in ClassA.Name
would get displayed.
Now, suppose ClassA
has a property of ClassB
and both classes have a property called Name
. Here is a block of XAML which illustrates the purpose of the DataContext, and an example of how a control would refer to a property not in it's own DataContext
<Window x:Name="myWindow"> <!-- DataContext is set to ClassA -->
<StackPanel> <!-- DataContext is set to ClassA -->
<!-- DataContext is set to ClassA, so will display ClassA.Name -->
<Label Content="Binding Name" />
<!-- DataContext is still ClassA, however we are setting it to ClassA.ClassB -->
<StackPanel DataContext="Binding ClassB">
<!-- DataContext is set to ClassB, so will display ClassB.Name -->
<Label Content="Binding Name" />
<!-- DataContext is still ClassB, but we are binding to the Window's DataContext.Name which is ClassA.Name -->
<Label Content="Binding ElementName=myWindow, Path=DataContext.Name" />
</StackPanel>
</StackPanel>
</Window>
As you can see, the DataContext is based on whatever data is behind the UI object.
Update: I see this question so often from new WPF users that I expanded this answer into a post on my blog: What is this “DataContext” you speak of?
Hi! Thanks for the detailed answer. But. What I don't like in you example is that you binding the DataContext property itself. Most probably I would extract StackPanel in your example into a separate control. It makes sense if its DataContext is just aт isolated part of DataContext of its parent, doesn't it? And then I wouldn't bind the DataContext property of my user control, but would rather have a special property with self-descriptive name. (I mean what is a DataContext for a particular control? What should I pass in?) And this is there the things get complicated. [To be continued]
– Eugene Strizhok
Sep 1 '11 at 20:16
As I would not bind the DataContext property, it would be taken from a parent control. Which means I am not longer able to bind controls inside my custom control against DataContext, just because I don't know what's in there (the control can't control whose child it will be, and what DataContext it will receive). The solution could be to set DataContext from inside to control (using a value from that special property). [To be continued]
– Eugene Strizhok
Sep 1 '11 at 20:17
But this will break binding of control itself, because, as you pointed out, having writtenContent=Binding Name
one binds toLabel.DataContext.Name
and not toLabel.Parent.DataContext.Name
as I would expect it to do.
– Eugene Strizhok
Sep 1 '11 at 20:17
@Eugene You want to make a new UserControl (Or DataTemplate) if it is logical to do so. Quite often that is not the case, and it is easier to bind something's DataContext than to bind to the same property multiple times.
– Rachel
Sep 2 '11 at 1:50
4
@Eugene I would highly recommend you look into the MVVM Design Pattern. In my opinion it should be used with any WPF application, and you will get a better understanding of the DataContext and it's importance. Your visual controls are NOT your application - your DataContext (ViewModels) are. The visual controls (labels, buttons, textboxes, etc) are simply a nice UI that allows users to interact with your application.
– Rachel
Sep 2 '11 at 14:31
|
show 1 more comment
When you write
<Label name="myLabel" Content="Binding Path=Name" />
you are binding to myLabel.DataContext.Name
, and not myLabel.Name
.
The XAML in WPF is just a pretty user interface to display and interact with the actual data, otherwise known as the DataContext
. The purpose of other binding sources (RelativeSource
, ElementName
, etc) is to point to another property that doesn't exist in the current control's DataContext
So suppose you have a Window. Without setting the DataContext, the window still displays but there is no data behind it.
Now suppose to set myWindow.DataContext = new ClassA();
. Now the data that the window is displaying is ClassA
. If ClassA
has a property called Name
, I could write a label and bind it to Name
(such as your example), and whatever value is stored in ClassA.Name
would get displayed.
Now, suppose ClassA
has a property of ClassB
and both classes have a property called Name
. Here is a block of XAML which illustrates the purpose of the DataContext, and an example of how a control would refer to a property not in it's own DataContext
<Window x:Name="myWindow"> <!-- DataContext is set to ClassA -->
<StackPanel> <!-- DataContext is set to ClassA -->
<!-- DataContext is set to ClassA, so will display ClassA.Name -->
<Label Content="Binding Name" />
<!-- DataContext is still ClassA, however we are setting it to ClassA.ClassB -->
<StackPanel DataContext="Binding ClassB">
<!-- DataContext is set to ClassB, so will display ClassB.Name -->
<Label Content="Binding Name" />
<!-- DataContext is still ClassB, but we are binding to the Window's DataContext.Name which is ClassA.Name -->
<Label Content="Binding ElementName=myWindow, Path=DataContext.Name" />
</StackPanel>
</StackPanel>
</Window>
As you can see, the DataContext is based on whatever data is behind the UI object.
Update: I see this question so often from new WPF users that I expanded this answer into a post on my blog: What is this “DataContext” you speak of?
Hi! Thanks for the detailed answer. But. What I don't like in you example is that you binding the DataContext property itself. Most probably I would extract StackPanel in your example into a separate control. It makes sense if its DataContext is just aт isolated part of DataContext of its parent, doesn't it? And then I wouldn't bind the DataContext property of my user control, but would rather have a special property with self-descriptive name. (I mean what is a DataContext for a particular control? What should I pass in?) And this is there the things get complicated. [To be continued]
– Eugene Strizhok
Sep 1 '11 at 20:16
As I would not bind the DataContext property, it would be taken from a parent control. Which means I am not longer able to bind controls inside my custom control against DataContext, just because I don't know what's in there (the control can't control whose child it will be, and what DataContext it will receive). The solution could be to set DataContext from inside to control (using a value from that special property). [To be continued]
– Eugene Strizhok
Sep 1 '11 at 20:17
But this will break binding of control itself, because, as you pointed out, having writtenContent=Binding Name
one binds toLabel.DataContext.Name
and not toLabel.Parent.DataContext.Name
as I would expect it to do.
– Eugene Strizhok
Sep 1 '11 at 20:17
@Eugene You want to make a new UserControl (Or DataTemplate) if it is logical to do so. Quite often that is not the case, and it is easier to bind something's DataContext than to bind to the same property multiple times.
– Rachel
Sep 2 '11 at 1:50
4
@Eugene I would highly recommend you look into the MVVM Design Pattern. In my opinion it should be used with any WPF application, and you will get a better understanding of the DataContext and it's importance. Your visual controls are NOT your application - your DataContext (ViewModels) are. The visual controls (labels, buttons, textboxes, etc) are simply a nice UI that allows users to interact with your application.
– Rachel
Sep 2 '11 at 14:31
|
show 1 more comment
When you write
<Label name="myLabel" Content="Binding Path=Name" />
you are binding to myLabel.DataContext.Name
, and not myLabel.Name
.
The XAML in WPF is just a pretty user interface to display and interact with the actual data, otherwise known as the DataContext
. The purpose of other binding sources (RelativeSource
, ElementName
, etc) is to point to another property that doesn't exist in the current control's DataContext
So suppose you have a Window. Without setting the DataContext, the window still displays but there is no data behind it.
Now suppose to set myWindow.DataContext = new ClassA();
. Now the data that the window is displaying is ClassA
. If ClassA
has a property called Name
, I could write a label and bind it to Name
(such as your example), and whatever value is stored in ClassA.Name
would get displayed.
Now, suppose ClassA
has a property of ClassB
and both classes have a property called Name
. Here is a block of XAML which illustrates the purpose of the DataContext, and an example of how a control would refer to a property not in it's own DataContext
<Window x:Name="myWindow"> <!-- DataContext is set to ClassA -->
<StackPanel> <!-- DataContext is set to ClassA -->
<!-- DataContext is set to ClassA, so will display ClassA.Name -->
<Label Content="Binding Name" />
<!-- DataContext is still ClassA, however we are setting it to ClassA.ClassB -->
<StackPanel DataContext="Binding ClassB">
<!-- DataContext is set to ClassB, so will display ClassB.Name -->
<Label Content="Binding Name" />
<!-- DataContext is still ClassB, but we are binding to the Window's DataContext.Name which is ClassA.Name -->
<Label Content="Binding ElementName=myWindow, Path=DataContext.Name" />
</StackPanel>
</StackPanel>
</Window>
As you can see, the DataContext is based on whatever data is behind the UI object.
Update: I see this question so often from new WPF users that I expanded this answer into a post on my blog: What is this “DataContext” you speak of?
When you write
<Label name="myLabel" Content="Binding Path=Name" />
you are binding to myLabel.DataContext.Name
, and not myLabel.Name
.
The XAML in WPF is just a pretty user interface to display and interact with the actual data, otherwise known as the DataContext
. The purpose of other binding sources (RelativeSource
, ElementName
, etc) is to point to another property that doesn't exist in the current control's DataContext
So suppose you have a Window. Without setting the DataContext, the window still displays but there is no data behind it.
Now suppose to set myWindow.DataContext = new ClassA();
. Now the data that the window is displaying is ClassA
. If ClassA
has a property called Name
, I could write a label and bind it to Name
(such as your example), and whatever value is stored in ClassA.Name
would get displayed.
Now, suppose ClassA
has a property of ClassB
and both classes have a property called Name
. Here is a block of XAML which illustrates the purpose of the DataContext, and an example of how a control would refer to a property not in it's own DataContext
<Window x:Name="myWindow"> <!-- DataContext is set to ClassA -->
<StackPanel> <!-- DataContext is set to ClassA -->
<!-- DataContext is set to ClassA, so will display ClassA.Name -->
<Label Content="Binding Name" />
<!-- DataContext is still ClassA, however we are setting it to ClassA.ClassB -->
<StackPanel DataContext="Binding ClassB">
<!-- DataContext is set to ClassB, so will display ClassB.Name -->
<Label Content="Binding Name" />
<!-- DataContext is still ClassB, but we are binding to the Window's DataContext.Name which is ClassA.Name -->
<Label Content="Binding ElementName=myWindow, Path=DataContext.Name" />
</StackPanel>
</StackPanel>
</Window>
As you can see, the DataContext is based on whatever data is behind the UI object.
Update: I see this question so often from new WPF users that I expanded this answer into a post on my blog: What is this “DataContext” you speak of?
edited Sep 19 '12 at 19:18
answered Aug 31 '11 at 19:26
RachelRachel
96.3k50245413
96.3k50245413
Hi! Thanks for the detailed answer. But. What I don't like in you example is that you binding the DataContext property itself. Most probably I would extract StackPanel in your example into a separate control. It makes sense if its DataContext is just aт isolated part of DataContext of its parent, doesn't it? And then I wouldn't bind the DataContext property of my user control, but would rather have a special property with self-descriptive name. (I mean what is a DataContext for a particular control? What should I pass in?) And this is there the things get complicated. [To be continued]
– Eugene Strizhok
Sep 1 '11 at 20:16
As I would not bind the DataContext property, it would be taken from a parent control. Which means I am not longer able to bind controls inside my custom control against DataContext, just because I don't know what's in there (the control can't control whose child it will be, and what DataContext it will receive). The solution could be to set DataContext from inside to control (using a value from that special property). [To be continued]
– Eugene Strizhok
Sep 1 '11 at 20:17
But this will break binding of control itself, because, as you pointed out, having writtenContent=Binding Name
one binds toLabel.DataContext.Name
and not toLabel.Parent.DataContext.Name
as I would expect it to do.
– Eugene Strizhok
Sep 1 '11 at 20:17
@Eugene You want to make a new UserControl (Or DataTemplate) if it is logical to do so. Quite often that is not the case, and it is easier to bind something's DataContext than to bind to the same property multiple times.
– Rachel
Sep 2 '11 at 1:50
4
@Eugene I would highly recommend you look into the MVVM Design Pattern. In my opinion it should be used with any WPF application, and you will get a better understanding of the DataContext and it's importance. Your visual controls are NOT your application - your DataContext (ViewModels) are. The visual controls (labels, buttons, textboxes, etc) are simply a nice UI that allows users to interact with your application.
– Rachel
Sep 2 '11 at 14:31
|
show 1 more comment
Hi! Thanks for the detailed answer. But. What I don't like in you example is that you binding the DataContext property itself. Most probably I would extract StackPanel in your example into a separate control. It makes sense if its DataContext is just aт isolated part of DataContext of its parent, doesn't it? And then I wouldn't bind the DataContext property of my user control, but would rather have a special property with self-descriptive name. (I mean what is a DataContext for a particular control? What should I pass in?) And this is there the things get complicated. [To be continued]
– Eugene Strizhok
Sep 1 '11 at 20:16
As I would not bind the DataContext property, it would be taken from a parent control. Which means I am not longer able to bind controls inside my custom control against DataContext, just because I don't know what's in there (the control can't control whose child it will be, and what DataContext it will receive). The solution could be to set DataContext from inside to control (using a value from that special property). [To be continued]
– Eugene Strizhok
Sep 1 '11 at 20:17
But this will break binding of control itself, because, as you pointed out, having writtenContent=Binding Name
one binds toLabel.DataContext.Name
and not toLabel.Parent.DataContext.Name
as I would expect it to do.
– Eugene Strizhok
Sep 1 '11 at 20:17
@Eugene You want to make a new UserControl (Or DataTemplate) if it is logical to do so. Quite often that is not the case, and it is easier to bind something's DataContext than to bind to the same property multiple times.
– Rachel
Sep 2 '11 at 1:50
4
@Eugene I would highly recommend you look into the MVVM Design Pattern. In my opinion it should be used with any WPF application, and you will get a better understanding of the DataContext and it's importance. Your visual controls are NOT your application - your DataContext (ViewModels) are. The visual controls (labels, buttons, textboxes, etc) are simply a nice UI that allows users to interact with your application.
– Rachel
Sep 2 '11 at 14:31
Hi! Thanks for the detailed answer. But. What I don't like in you example is that you binding the DataContext property itself. Most probably I would extract StackPanel in your example into a separate control. It makes sense if its DataContext is just aт isolated part of DataContext of its parent, doesn't it? And then I wouldn't bind the DataContext property of my user control, but would rather have a special property with self-descriptive name. (I mean what is a DataContext for a particular control? What should I pass in?) And this is there the things get complicated. [To be continued]
– Eugene Strizhok
Sep 1 '11 at 20:16
Hi! Thanks for the detailed answer. But. What I don't like in you example is that you binding the DataContext property itself. Most probably I would extract StackPanel in your example into a separate control. It makes sense if its DataContext is just aт isolated part of DataContext of its parent, doesn't it? And then I wouldn't bind the DataContext property of my user control, but would rather have a special property with self-descriptive name. (I mean what is a DataContext for a particular control? What should I pass in?) And this is there the things get complicated. [To be continued]
– Eugene Strizhok
Sep 1 '11 at 20:16
As I would not bind the DataContext property, it would be taken from a parent control. Which means I am not longer able to bind controls inside my custom control against DataContext, just because I don't know what's in there (the control can't control whose child it will be, and what DataContext it will receive). The solution could be to set DataContext from inside to control (using a value from that special property). [To be continued]
– Eugene Strizhok
Sep 1 '11 at 20:17
As I would not bind the DataContext property, it would be taken from a parent control. Which means I am not longer able to bind controls inside my custom control against DataContext, just because I don't know what's in there (the control can't control whose child it will be, and what DataContext it will receive). The solution could be to set DataContext from inside to control (using a value from that special property). [To be continued]
– Eugene Strizhok
Sep 1 '11 at 20:17
But this will break binding of control itself, because, as you pointed out, having written
Content=Binding Name
one binds to Label.DataContext.Name
and not to Label.Parent.DataContext.Name
as I would expect it to do.– Eugene Strizhok
Sep 1 '11 at 20:17
But this will break binding of control itself, because, as you pointed out, having written
Content=Binding Name
one binds to Label.DataContext.Name
and not to Label.Parent.DataContext.Name
as I would expect it to do.– Eugene Strizhok
Sep 1 '11 at 20:17
@Eugene You want to make a new UserControl (Or DataTemplate) if it is logical to do so. Quite often that is not the case, and it is easier to bind something's DataContext than to bind to the same property multiple times.
– Rachel
Sep 2 '11 at 1:50
@Eugene You want to make a new UserControl (Or DataTemplate) if it is logical to do so. Quite often that is not the case, and it is easier to bind something's DataContext than to bind to the same property multiple times.
– Rachel
Sep 2 '11 at 1:50
4
4
@Eugene I would highly recommend you look into the MVVM Design Pattern. In my opinion it should be used with any WPF application, and you will get a better understanding of the DataContext and it's importance. Your visual controls are NOT your application - your DataContext (ViewModels) are. The visual controls (labels, buttons, textboxes, etc) are simply a nice UI that allows users to interact with your application.
– Rachel
Sep 2 '11 at 14:31
@Eugene I would highly recommend you look into the MVVM Design Pattern. In my opinion it should be used with any WPF application, and you will get a better understanding of the DataContext and it's importance. Your visual controls are NOT your application - your DataContext (ViewModels) are. The visual controls (labels, buttons, textboxes, etc) are simply a nice UI that allows users to interact with your application.
– Rachel
Sep 2 '11 at 14:31
|
show 1 more comment
From CodeProject by kishore Gaddam:
DataContext
is one of the most fundamental concepts in Data Binding. The Binding object needs to get its data from somewhere, and there are a few ways to specify the source of the data like using Source property directly in the Binding, inheriting aDataContext
from the nearest element when traversing up in the tree, setting theElementName
andRelativeSource
properties in the Binding object.
Detailed example on CodeProject: http://www.codeproject.com/Articles/321899/DataContext-in-WPF
add a comment |
From CodeProject by kishore Gaddam:
DataContext
is one of the most fundamental concepts in Data Binding. The Binding object needs to get its data from somewhere, and there are a few ways to specify the source of the data like using Source property directly in the Binding, inheriting aDataContext
from the nearest element when traversing up in the tree, setting theElementName
andRelativeSource
properties in the Binding object.
Detailed example on CodeProject: http://www.codeproject.com/Articles/321899/DataContext-in-WPF
add a comment |
From CodeProject by kishore Gaddam:
DataContext
is one of the most fundamental concepts in Data Binding. The Binding object needs to get its data from somewhere, and there are a few ways to specify the source of the data like using Source property directly in the Binding, inheriting aDataContext
from the nearest element when traversing up in the tree, setting theElementName
andRelativeSource
properties in the Binding object.
Detailed example on CodeProject: http://www.codeproject.com/Articles/321899/DataContext-in-WPF
From CodeProject by kishore Gaddam:
DataContext
is one of the most fundamental concepts in Data Binding. The Binding object needs to get its data from somewhere, and there are a few ways to specify the source of the data like using Source property directly in the Binding, inheriting aDataContext
from the nearest element when traversing up in the tree, setting theElementName
andRelativeSource
properties in the Binding object.
Detailed example on CodeProject: http://www.codeproject.com/Articles/321899/DataContext-in-WPF
edited Jul 11 '15 at 12:53
BartoszKP
26.9k1067106
26.9k1067106
answered Oct 19 '13 at 19:56
Cornel MarianCornel Marian
1,7251526
1,7251526
add a comment |
add a comment |
In that particular case, you could do:
<Controls:SearchSettings DataContext="Binding Path=Settings" Settings="Binding" />
Assuming you want everything that may be content of the SearchSettings to use Settings as it's data context. Basically, the DataContext affects the element itself an any descendants that don't explicitly override it.
add a comment |
In that particular case, you could do:
<Controls:SearchSettings DataContext="Binding Path=Settings" Settings="Binding" />
Assuming you want everything that may be content of the SearchSettings to use Settings as it's data context. Basically, the DataContext affects the element itself an any descendants that don't explicitly override it.
add a comment |
In that particular case, you could do:
<Controls:SearchSettings DataContext="Binding Path=Settings" Settings="Binding" />
Assuming you want everything that may be content of the SearchSettings to use Settings as it's data context. Basically, the DataContext affects the element itself an any descendants that don't explicitly override it.
In that particular case, you could do:
<Controls:SearchSettings DataContext="Binding Path=Settings" Settings="Binding" />
Assuming you want everything that may be content of the SearchSettings to use Settings as it's data context. Basically, the DataContext affects the element itself an any descendants that don't explicitly override it.
answered Aug 31 '11 at 19:19
CodeNakedCodeNaked
34.9k691128
34.9k691128
add a comment |
add a comment |
In most cases you do want to bind to the DataContext, in some templates on ItemsControls it is the only way to bind to the currently templated item for example. Further bindings to the DataContext are nice to write and read as they are concise.
In your example you can still set the DataContext, you only need to modify the binding on the Settings respectively:
<Controls:SearchSettings DataContext="Binding Settings" Settings="Binding"/>
I thought of this approach, but it doesn't make sense. Why should I bind two properties, if I only need one?
– Eugene Strizhok
Sep 1 '11 at 20:21
@EugeneStrizhok: You do not only need one, this allows you to bind to the Settings in the child controls without setting a source because you now can use the DataContext.
– H.B.
Sep 1 '11 at 21:09
add a comment |
In most cases you do want to bind to the DataContext, in some templates on ItemsControls it is the only way to bind to the currently templated item for example. Further bindings to the DataContext are nice to write and read as they are concise.
In your example you can still set the DataContext, you only need to modify the binding on the Settings respectively:
<Controls:SearchSettings DataContext="Binding Settings" Settings="Binding"/>
I thought of this approach, but it doesn't make sense. Why should I bind two properties, if I only need one?
– Eugene Strizhok
Sep 1 '11 at 20:21
@EugeneStrizhok: You do not only need one, this allows you to bind to the Settings in the child controls without setting a source because you now can use the DataContext.
– H.B.
Sep 1 '11 at 21:09
add a comment |
In most cases you do want to bind to the DataContext, in some templates on ItemsControls it is the only way to bind to the currently templated item for example. Further bindings to the DataContext are nice to write and read as they are concise.
In your example you can still set the DataContext, you only need to modify the binding on the Settings respectively:
<Controls:SearchSettings DataContext="Binding Settings" Settings="Binding"/>
In most cases you do want to bind to the DataContext, in some templates on ItemsControls it is the only way to bind to the currently templated item for example. Further bindings to the DataContext are nice to write and read as they are concise.
In your example you can still set the DataContext, you only need to modify the binding on the Settings respectively:
<Controls:SearchSettings DataContext="Binding Settings" Settings="Binding"/>
answered Aug 31 '11 at 19:21
H.B.H.B.
121k22242322
121k22242322
I thought of this approach, but it doesn't make sense. Why should I bind two properties, if I only need one?
– Eugene Strizhok
Sep 1 '11 at 20:21
@EugeneStrizhok: You do not only need one, this allows you to bind to the Settings in the child controls without setting a source because you now can use the DataContext.
– H.B.
Sep 1 '11 at 21:09
add a comment |
I thought of this approach, but it doesn't make sense. Why should I bind two properties, if I only need one?
– Eugene Strizhok
Sep 1 '11 at 20:21
@EugeneStrizhok: You do not only need one, this allows you to bind to the Settings in the child controls without setting a source because you now can use the DataContext.
– H.B.
Sep 1 '11 at 21:09
I thought of this approach, but it doesn't make sense. Why should I bind two properties, if I only need one?
– Eugene Strizhok
Sep 1 '11 at 20:21
I thought of this approach, but it doesn't make sense. Why should I bind two properties, if I only need one?
– Eugene Strizhok
Sep 1 '11 at 20:21
@EugeneStrizhok: You do not only need one, this allows you to bind to the Settings in the child controls without setting a source because you now can use the DataContext.
– H.B.
Sep 1 '11 at 21:09
@EugeneStrizhok: You do not only need one, this allows you to bind to the Settings in the child controls without setting a source because you now can use the DataContext.
– H.B.
Sep 1 '11 at 21:09
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f7262137%2fwhat-is-datacontext-for%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown