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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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

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?

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.

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.

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?

vesuvius said:

turrican said:

*snip*

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

Thanks, great video!

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.

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.

turrican said:

spivonious said:

*snip*

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

Commands are very easy to understand, in MS word you have a cut/copy/paste commands  (it is a design pattern) that can be called from a toolbar button, context menu or menu option. Rather than having three seperate click events you have the notion of a command, that can be called from any place.

Try get a copy of the Adam Nathan book as that is very good for people that are coming to WPF from ASP.NET or winforms. The hard part is getting to create delegate/relay commands, that video I have just linked to has all this information.

vesuvius said:

turrican said:

*snip*

Commands are very easy to understand, in MS word you have a cut/copy/paste commands  (it is a design pattern) that can be called from a toolbar button, context menu or menu option. Rather than having three seperate click events you have the notion of a command, that can be called from any place.

 

Try get a copy of the Adam Nathan book as that is very good for people that are coming to WPF from ASP.NET or winforms. The hard part is getting to create delegate/relay commands, that video I have just linked to has all this information.

Yeah... I see.

That video helped a lot. I'll try to buy a copy of his book later.

turrican said:

vesuvius said:

*snip*

Yeah... I see.

 

That video helped a lot. I'll try to buy a copy of his book later.

Also feel free to have a look at these pretty popular tutorials from moi if you really want to know how to do this properly.

vesuvius said:

turrican said:

*snip*

Also feel free to have a look at these pretty popular tutorials from moi if you really want to know how to do this properly.

Coooooooooool!

One issue though, in that video... they use 3rd party libraries / DLLs ... which is not too good for me imho. I usually never use 3rd party stuff in order to not be dependant on others.

turrican said:

vesuvius said:

*snip*

Coooooooooool!

 

One issue though, in that video... they use 3rd party libraries / DLLs ... which is not too good for me imho. I usually never use 3rd party stuff in order to not be dependant on others.

Well, any dependency you have such as .NET framework DLL's are still a dependency.. you should get over this, I don't think there's a single project I work on that doesn't use 3rd party libs of some sort.

If you try and recreate everything, you'll create unfortunately inferior results (not specifically through lack of ability), that took longer to make.

Like anything, the lesson is 'balance'..

stevo_ said:

turrican said:

*snip*

Well, any dependency you have such as .NET framework DLL's are still a dependency.. you should get over this, I don't think there's a single project I work on that doesn't use 3rd party libs of some sort.

 

If you try and recreate everything, you'll create unfortunately inferior results (not specifically through lack of ability), that took longer to make.

 

Like anything, the lesson is 'balance'..

The more suppliers, the more complicated, the more dependant. At some places, using more than one supplier isn't even allowed.

I do not disagree that they can do things better since they specialize on it... but I still dislike using 3rd party stuff. Weird thing is that Microsoft been spending money on crappy stuff, they should gobble up some of these great libs and put it into .NET or something. It would help .NET and also help the people who made these things... and also benefit developers. win win win.

...maybe I'm a dreamer.

turrican said:

spivonious said:

*snip*

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

A book that I got a lot out of is Pro WPF in C# 2008 from Apress. If you're doing SL, you may want to see if they have a book on SL, but a lot of WPF knowledge is directly applicable to SL.

As far as Commands, I use Josh Smith's RelayCommand class to define a method for what the command should do and a method to determine if the command can be run. Then I bind an instance of that command to any object in the interface that uses it. With this approach it's possible to have a completely empty code-behind, which makes maintenance of the interface a lot easier because it is now completely visual. All of the functionality is contained in other classes.

I tend to avoid third-party libraries too, unless I need something that I couldn't throw together myself. For me, it's easier to work with objects I designed rather than hope the library works with the specific case I need it for.