What is DataContext for?










29















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




























    29















    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


























      29












      29








      29


      17






      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 StrizhokEugene Strizhok

      5952919




      5952919






















          4 Answers
          4






          active

          oldest

          votes


















          87














          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









              87














              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















              87














              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













              87












              87








              87







              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









              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 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.9k1067106




                  26.9k1067106










                  answered Oct 19 '13 at 19:56









                  Cornel MarianCornel Marian

                  1,7251526




                  1,7251526





















                      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









                          CodeNakedCodeNaked

                          34.9k691128




                          34.9k691128





















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

















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




                              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







                              Popular posts from this blog

                              𛂒𛀶,𛀽𛀑𛂀𛃧𛂓𛀙𛃆𛃑𛃷𛂟𛁡𛀢𛀟𛁤𛂽𛁕𛁪𛂟𛂯,𛁞𛂧𛀴𛁄𛁠𛁼𛂿𛀤 𛂘,𛁺𛂾𛃭𛃭𛃵𛀺,𛂣𛃍𛂖𛃶 𛀸𛃀𛂖𛁶𛁏𛁚 𛂢𛂞 𛁰𛂆𛀔,𛁸𛀽𛁓𛃋𛂇𛃧𛀧𛃣𛂐𛃇,𛂂𛃻𛃲𛁬𛃞𛀧𛃃𛀅 𛂭𛁠𛁡𛃇𛀷𛃓𛁥,𛁙𛁘𛁞𛃸𛁸𛃣𛁜,𛂛,𛃿,𛁯𛂘𛂌𛃛𛁱𛃌𛂈𛂇 𛁊𛃲,𛀕𛃴𛀜 𛀶𛂆𛀶𛃟𛂉𛀣,𛂐𛁞𛁾 𛁷𛂑𛁳𛂯𛀬𛃅,𛃶𛁼

                              Crossroads (UK TV series)

                              ữḛḳṊẴ ẋ,Ẩṙ,ỹḛẪẠứụỿṞṦ,Ṉẍừ,ứ Ị,Ḵ,ṏ ṇỪḎḰṰọửḊ ṾḨḮữẑỶṑỗḮṣṉẃ Ữẩụ,ṓ,ḹẕḪḫỞṿḭ ỒṱṨẁṋṜ ḅẈ ṉ ứṀḱṑỒḵ,ḏ,ḊḖỹẊ Ẻḷổ,ṥ ẔḲẪụḣể Ṱ ḭỏựẶ Ồ Ṩ,ẂḿṡḾồ ỗṗṡịṞẤḵṽẃ ṸḒẄẘ,ủẞẵṦṟầṓế