Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I'm a beginner with wpf app building and entity framework.
I'm building my first wpf app, I found out I should have replaced my auto-generated ICollection with ObservableCollection.
The problem is that I already did most of my code so far but am having some issues with INotifyPropertyChanged. I see all the codes about INotifyPropertyChanged use ObservableCollection.
Is it bad if I go to my auto-generated code now and replace the ICollection with ObservableCollection? Will it mess up my app?
ObservableCollection is only useful if you want to add items to a collection at some point, and have a UI control automatically update to display the added / deleted items. ObservableCollection also has potential threading issues - any change to the collection must be done on the same thread as it was created on.
It has nothing to do with reflecting changes to properties of individual elements within the collection - that is what INotifyPropertyChanged is for.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I'm new to WPF and MVVM pattern. I've been reading about it and I come to a little doubt.
I'll build an WPF application that mainly does access to a database (oracle), but this access is done by an WebService (DataService). My question is in the Model part.
Should I create a class to each table on the database, on my Model, or should I just use the entities that the service provides me?
My guess is use the entities of the service, and then just do the CRUD operations in my application. But I want your opinion.
Thanks in advance.
It is always a good practice to use your own Models. That way, if the Service changes the structure, you will only need to change one point (where you map the item to your own entity), else you would have to change your whole application
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
As you can see in this image:
It's a table containing different controls(e.g. button, list, text) on the columns that can be sorted and each row is unique to each other. Any help or starting point would be greatly appreciated.
You would typically have an Observable Collection which holds the objects of interest (i.e. in your screenshot you have a person with a name, age, etc), so it could potentially be an ObservableCollection of Person objects.
Once you have that, you can build up your view in XAML. Typically you'd have some sort of list control (list view, list box, etc) that binds to the collection, and you create a data template in order to customise the look and feel of the control to match how it looks in the screenshot.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Is it common to store "non-model" classes (maybe helper classes) that I don't wanna use in a ViewModel inside Model directory in MVVM project?
For example:
Models\SongModel
Models\ID3TagReader
ViewModels\SongViewModel
If no, how should I encapsulate these classes?
In this design, the views know of the ViewModel and bind to its data, to be able to reflect any changes in it. The ViewModel has no reference to the views—it holds only a reference to the model.
For the views, the ViewModel acts both as a façade to the model, but also as a way to share state between views (selectedContacts in the example). In addition, the ViewModel often exposes commands that the views can bind to and trigger.
refer to the link..
http://blogs.msdn.com/b/ivo_manolov/archive/2012/03/17/10284665.aspx
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Assuming I was writing my own version of .Net :)
What would be the downside of such a setup?
Yes, I am talking about a new anti-pattern here to avoid creating endless tuples and EventArgs. I think such a setup would have made coding a lot cleaner.
No. The Tag property has history, it was important in VB6 and Winforms was meant to replace it. It needed to be added to make porting code relatively simple.
It is entirely unnecessary in .NET. It supports implementation inheritance, a feature that VB6 didn't have. So if you want to add extra properties then you just derive a class and add them. And you'll be able to give them a good name and a type so you don't have to cast every time you read the property. This works just as well with Winforms controls.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
VB6 had a fileListBox with .path property and I am trying to add that property to regular listbox.
ListBox myfilelistbox = new ListBox();
and the one generated with XAML.
I think what you want is Attached Properties
ListBox is a generic control which displays list of items in a linear manner. What you wish to do is to display a hierarchy of items, not a list of them.
There are no such built in controls and you will have to build one for yourself or find some that others have implemented.
Check more information on this other Stack Overflow thread Is there a WPF control which will show a list of files in an Explorer-like view?.
The following article on CodeProject could help you: A WPF File ListView and ComboBox