What is DataContext for?










27














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?










share|improve this question




























    27














    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?










    share|improve this question


























      27












      27








      27


      16





      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?










      share|improve this question















      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






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited May 23 '17 at 11:47









      Community

      11




      11










      asked Aug 31 '11 at 19:10









      Eugene Strizhok

      5802919




      5802919






















          4 Answers
          4






          active

          oldest

          votes


















          85














          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?






          share|improve this answer






















          • 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 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






          • 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


















          2














          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 a DataContext from the nearest element when traversing up in the tree, setting the ElementName and RelativeSource properties in the Binding object.




          Detailed example on CodeProject: http://www.codeproject.com/Articles/321899/DataContext-in-WPF






          share|improve this answer






























            1














            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.






            share|improve this answer




























              1














              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"/>





              share|improve this answer




















              • 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










              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
              );



              );













              draft saved

              draft discarded


















              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









              85














              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?






              share|improve this answer






















              • 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 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






              • 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















              85














              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?






              share|improve this answer






















              • 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 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






              • 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













              85












              85








              85






              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?






              share|improve this answer














              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?







              share|improve this answer














              share|improve this answer



              share|improve this answer








              edited Sep 19 '12 at 19:18

























              answered Aug 31 '11 at 19:26









              Rachel

              94.9k50242405




              94.9k50242405











              • 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 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






              • 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










              • 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










              • @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













              2














              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 a DataContext from the nearest element when traversing up in the tree, setting the ElementName and RelativeSource properties in the Binding object.




              Detailed example on CodeProject: http://www.codeproject.com/Articles/321899/DataContext-in-WPF






              share|improve this answer



























                2














                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 a DataContext from the nearest element when traversing up in the tree, setting the ElementName and RelativeSource properties in the Binding object.




                Detailed example on CodeProject: http://www.codeproject.com/Articles/321899/DataContext-in-WPF






                share|improve this answer

























                  2












                  2








                  2






                  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 a DataContext from the nearest element when traversing up in the tree, setting the ElementName and RelativeSource properties in the Binding object.




                  Detailed example on CodeProject: http://www.codeproject.com/Articles/321899/DataContext-in-WPF






                  share|improve this answer














                  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 a DataContext from the nearest element when traversing up in the tree, setting the ElementName and RelativeSource properties in the Binding object.




                  Detailed example on CodeProject: http://www.codeproject.com/Articles/321899/DataContext-in-WPF







                  share|improve this answer














                  share|improve this answer



                  share|improve this answer








                  edited Jul 11 '15 at 12:53









                  BartoszKP

                  26.6k1065103




                  26.6k1065103










                  answered Oct 19 '13 at 19:56









                  Cornel Marian

                  1,6851426




                  1,6851426





















                      1














                      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.






                      share|improve this answer

























                        1














                        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.






                        share|improve this answer























                          1












                          1








                          1






                          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.






                          share|improve this answer












                          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.







                          share|improve this answer












                          share|improve this answer



                          share|improve this answer










                          answered Aug 31 '11 at 19:19









                          CodeNaked

                          34.6k689126




                          34.6k689126





















                              1














                              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"/>





                              share|improve this answer




















                              • 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















                              1














                              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"/>





                              share|improve this answer




















                              • 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













                              1












                              1








                              1






                              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"/>





                              share|improve this answer












                              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"/>






                              share|improve this answer












                              share|improve this answer



                              share|improve this answer










                              answered Aug 31 '11 at 19:21









                              H.B.

                              120k22240320




                              120k22240320











                              • 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











                              • @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

















                              draft saved

                              draft discarded
















































                              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.





                              Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


                              Please pay close attention to the following guidance:


                              • 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.




                              draft saved


                              draft discarded














                              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





















































                              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







                              這個網誌中的熱門文章

                              How to read a connectionString WITH PROVIDER in .NET Core?

                              In R, how to develop a multiplot heatmap.2 figure showing key labels successfully

                              Museum of Modern and Contemporary Art of Trento and Rovereto