Tech Off Thread

25 posts

Silverlight 4 : ItemSource vs DataContext

Back to Forum: Tech Off
  • User profile image
    turrican

    I tried to read about these two, ItemSource and DataContext but I still do not get it. Using Silverlight 4... having a custom control, a ListBox... When I attach some ObservableCollection<T> to the listBox1.ItemSource, it works and shows up.

    When I attach some ObservableCollection<T> to the listBox1.DataContext, it also works and shows up.

     

    So, which one should I use? o.O

     

    Thanks.

  • User profile image
    stevo_

    ItemsSource explains what the source of the items is, whilst DataContext is purely about the concept of given Data being bound against that item, that data may not be used specifically (or directly) as the items, it may be used to set other properties on the list control.

     

    Generally you would bind to the DataContext, and if required (not sure if ItemsSource has a default binding directly to the DataContext) use items source to bind to THE or part of the DataContext.

  • User profile image
    turrican

    stevo_ said:

    ItemsSource explains what the source of the items is, whilst DataContext is purely about the concept of given Data being bound against that item, that data may not be used specifically (or directly) as the items, it may be used to set other properties on the list control.

     

    Generally you would bind to the DataContext, and if required (not sure if ItemsSource has a default binding directly to the DataContext) use items source to bind to THE or part of the DataContext.

    I "think" I get it, hmm, could you show me some small sample line of code where you bind ItemSource to a "certain" part of the DataContext?

     

    Thanks.

  • User profile image
    vesuvius

    turrican said:
    stevo_ said:
    *snip*

    I "think" I get it, hmm, could you show me some small sample line of code where you bind ItemSource to a "certain" part of the DataContext?

     

    Thanks.

    You need to start using the MVVM design patern

  • User profile image
    turrican

    vesuvius said:
    turrican said:
    *snip*

    You need to start using the MVVM design patern

    How exactly will Model View ViewModel help me? Not sure I get what you mean here.

  • User profile image
    vesuvius

    turrican said:
    vesuvius said:
    *snip*

    How exactly will Model View ViewModel help me? Not sure I get what you mean here.

    You typically databind to the viewmodel (the datacontext for the window/page/pagefunction, and expose properties that are then bound to the controls like the listbox. The listbox finds the properies you expose in the view model using attached properties/routed events.

  • User profile image
    spivonious

    MVVM is a nice pattern for WPF/SL, but it has nothing to do with your question.

     

    Let's say I have an object, "myThingie" that has a couple collections inside of it, "Stuff", "Things", and "People".

     

    I have a form that has a Grid, "myGrid", with three ListBoxes, "lst1", "lst2", "lst3".

     

    Here's my XAML (with extraneous stuff removed):

     

    <Grid DataContext={StaticResource myThingie}>

    <ListBox ItemSource={Binding Stuff}/>

    <ListBox ItemSource={Binding Things}/>

    <ListBox ItemSource={Binding People}/>

    </Grid>

     

    Because there's no source defined in the Binding statements, the ListBoxes automatically look to the DataContext. They'll go up the tree until they find one that's defined.

     

    Without the DataContext, the ItemSource binding statements get much more complex, and if I ever need to change the source of the data, I'd have to update all of them, instead of the one DataContext.

     

    Frankly, I'm surprised that just setting the ListBox DataContext works. I would have thought you'd need a ItemSource={Binding} for that to work.

  • User profile image
    turrican

    spivonious said:

    MVVM is a nice pattern for WPF/SL, but it has nothing to do with your question.

     

    Let's say I have an object, "myThingie" that has a couple collections inside of it, "Stuff", "Things", and "People".

     

    I have a form that has a Grid, "myGrid", with three ListBoxes, "lst1", "lst2", "lst3".

     

    Here's my XAML (with extraneous stuff removed):

     

    <Grid DataContext={StaticResource myThingie}>

    <ListBox ItemSource={Binding Stuff}/>

    <ListBox ItemSource={Binding Things}/>

    <ListBox ItemSource={Binding People}/>

    </Grid>

     

    Because there's no source defined in the Binding statements, the ListBoxes automatically look to the DataContext. They'll go up the tree until they find one that's defined.

     

    Without the DataContext, the ItemSource binding statements get much more complex, and if I ever need to change the source of the data, I'd have to update all of them, instead of the one DataContext.

     

    Frankly, I'm surprised that just setting the ListBox DataContext works. I would have thought you'd need a ItemSource={Binding} for that to work.

    I see. Thanks for the clear help.

     

    I do have " ItemsSource="{Binding}"" in my XAML for the listBox1.

     

    A small question, "myThingies"... in my case, it's a ObservableCollection<T>, now, how can I have "Stuff","Things","People" in this? Do you mean 3 other ObservableCollection<T> inside that one with the name "Stuff","Things" and "People"?

     

    and if that is the case, so when I do the  ItemsSource="{Binding Stuff}" , it will automatically match it with it, right?

     

    What I mean is, I do understand what you said but I am unsure how I can have several collections in "one" and then attach it to the datacontext? Could you give me a small sample code on an observablecollection having "3" stuff in it?

     

    Thanks.

  • User profile image
    spivonious

    turrican said:
    spivonious said:
    *snip*

    I see. Thanks for the clear help.

     

    I do have " ItemsSource="{Binding}"" in my XAML for the listBox1.

     

    A small question, "myThingies"... in my case, it's a ObservableCollection<T>, now, how can I have "Stuff","Things","People" in this? Do you mean 3 other ObservableCollection<T> inside that one with the name "Stuff","Things" and "People"?

     

    and if that is the case, so when I do the  ItemsSource="{Binding Stuff}" , it will automatically match it with it, right?

     

    What I mean is, I do understand what you said but I am unsure how I can have several collections in "one" and then attach it to the datacontext? Could you give me a small sample code on an observablecollection having "3" stuff in it?

     

    Thanks.

    The DataContext can be whatever you want it to be.  It doesn't have to be a collection. The property is available on all WPF controls.

     

    In one of my WPF apps, I have the DataContext set to an instance of a DataSet, and the bindings refer to the tables inside.

  • User profile image
    vesuvius

    spivonious said:

    MVVM is a nice pattern for WPF/SL, but it has nothing to do with your question.

     

    Let's say I have an object, "myThingie" that has a couple collections inside of it, "Stuff", "Things", and "People".

     

    I have a form that has a Grid, "myGrid", with three ListBoxes, "lst1", "lst2", "lst3".

     

    Here's my XAML (with extraneous stuff removed):

     

    <Grid DataContext={StaticResource myThingie}>

    <ListBox ItemSource={Binding Stuff}/>

    <ListBox ItemSource={Binding Things}/>

    <ListBox ItemSource={Binding People}/>

    </Grid>

     

    Because there's no source defined in the Binding statements, the ListBoxes automatically look to the DataContext. They'll go up the tree until they find one that's defined.

     

    Without the DataContext, the ItemSource binding statements get much more complex, and if I ever need to change the source of the data, I'd have to update all of them, instead of the one DataContext.

     

    Frankly, I'm surprised that just setting the ListBox DataContext works. I would have thought you'd need a ItemSource={Binding} for that to work.

    I know that the question lacked a direct reference to the pattern but he inevitably will start to get his "knickers in a twist" if he does not start using it.

  • User profile image
    turrican

    spivonious said:
    turrican said:
    *snip*

    The DataContext can be whatever you want it to be.  It doesn't have to be a collection. The property is available on all WPF controls.

     

    In one of my WPF apps, I have the DataContext set to an instance of a DataSet, and the bindings refer to the tables inside.

    Yes, I understand, ok I'll have to test with the collection and see how it goes.

     

    On a sidenote, when doing "SELECT * FROM TABLE1 ; SELECT * FROM TABLE2" I can get two tables out. Is it possible to get those two in a DataSet somehow? ( bit offtopic question but I thought you might know it. )

  • User profile image
    turrican

    vesuvius said:
    spivonious said:
    *snip*

    I know that the question lacked a direct reference to the pattern but he inevitably will start to get his "knickers in a twist" if he does not start using it.

    Hm... I am still unclear... but... my XAML is almost totally separated from my code, except attaching a style and the only thing I do is to attach collections to it. Am I missing something here?

  • User profile image
    vesuvius

    turrican said:
    spivonious said:
    *snip*

    Yes, I understand, ok I'll have to test with the collection and see how it goes.

     

    On a sidenote, when doing "SELECT * FROM TABLE1 ; SELECT * FROM TABLE2" I can get two tables out. Is it possible to get those two in a DataSet somehow? ( bit offtopic question but I thought you might know it. )

    I would do a join in the SQL then populate a single DataTable, it's more efficient.

  • User profile image
    vesuvius

    turrican said:
    vesuvius said:
    *snip*

    Hm... I am still unclear... but... my XAML is almost totally separated from my code, except attaching a style and the only thing I do is to attach collections to it. Am I missing something here?

    This is very very very very very good to get to grips with MVVM.

  • User profile image
    turrican

    vesuvius said:
    turrican said:
    *snip*

    I would do a join in the SQL then populate a single DataTable, it's more efficient.

    I know that... but... can it be done? without the join... getting two tables from two selects at once?

  • User profile image
    turrican

    vesuvius said:
    turrican said:
    *snip*

    This is very very very very very good to get to grips with MVVM.

    Thanks, great video!

  • User profile image
    spivonious

    turrican said:
    vesuvius said:
    *snip*

    I know that... but... can it be done? without the join... getting two tables from two selects at once?

    If you can get two tables out of it, then you can add those tables to a dataset. But I agree with vesuvius. Modify the SQL to get what you're really after. Doing two select *s is horribly inefficient.

     

    Also, there's no point to a Dataset unless the tables are related in some way, or you want to pass them around as one object.

     

    For more on MVVM, check out Josh Smith's blog: http://joshsmithonwpf.wordpress.com/ Personally, I think the pattern is overkill since you end up duplicating your model in the viewmodel, but it definitely makes unit testing easier.

     

    The biggest change (IMO) is moving from Click event handlers to Commands. It lets you ignore the details of the UI, like enabling/disabling all of the ways to save if there aren't any changes, and just focus on the action.

  • User profile image
    turrican

    spivonious said:
    turrican said:
    *snip*

    If you can get two tables out of it, then you can add those tables to a dataset. But I agree with vesuvius. Modify the SQL to get what you're really after. Doing two select *s is horribly inefficient.

     

    Also, there's no point to a Dataset unless the tables are related in some way, or you want to pass them around as one object.

     

    For more on MVVM, check out Josh Smith's blog: http://joshsmithonwpf.wordpress.com/ Personally, I think the pattern is overkill since you end up duplicating your model in the viewmodel, but it definitely makes unit testing easier.

     

    The biggest change (IMO) is moving from Click event handlers to Commands. It lets you ignore the details of the UI, like enabling/disabling all of the ways to save if there aren't any changes, and just focus on the action.

    "...moving from Click event handlers to Commands..."

     

    Yes, that is REALLY hard for me to understand right now. Trying to find good resource on it to learn more. It's a big shift for me but a necessity to learn it I guess.

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.