Is there a simple way to have a bindinglist composed of several bindinglists? i.e. that is the "view" of the lists.
That is to say: I have 3 lists (list1,list2,list3). I want a list that is always the union of the 3 listx (we can suppose that no object is contained in 2 different lists).
Certainly, I can succeed in using the ListChange property but maybe there is a smarter way to do this?
To do this you would need to create your own type, implement IList, IBindingList (and ideally IBindingListView), and optionally ICancelAddNew and IRaiseItemChangedEvents. You'd also need either a public non-object indexer (public T this[int index] {get;}) or ITypedList.
From having done things similar to this, I strongly advise you; don't, unless this is really important. It would be more pragmatic to copy the references into a new BindingList<>.
Also; with new items; which list would it go into?
Have you looked into the CompositeCollection class?
Depending on what you're trying to do, it might help: its purpose is to combine multiple collections into a single collection (typically for display/binding purposes). So, you could create a CompositeCollection and add your three BindingList instances to it. The CompositeCollection will automatically update to include the members of the "child" lists.
Related
I have lots of entities with nested List<> in each.
For example, I have BaseEntity which has List<ColumnEntity>.
ColumnEntity class has List<Info> and so on.
We are working with a WPF UI, and we need to track all changes in every List of BaseEntity. It is implemented by instantiating a new ObservableCollection based on the needed list, and with binding to that ObservableCollection.
What are the pros and cons changing all these nested Lists to ObservableCollections? So we can track all changes in BaseEntity itself without reassigning each list of BaseEntity to modified bound ObservableCollection?
Assuming that methods specific to List are never used.
Interesting question, considering that both List and ObservableCollection implement IList<T> there isn't much of a difference there, ObservableCollection also implements INotifyCollectionChanged interface, which allows WPF to bind to it.
One of the main differences is that ObservableCollection does not have AddRange method, which might have some implications.
Also, I would not use ObservableCollection for places where I know I would not be binding to, for this reason, it is important to go over your design and make sure that you are taking the correct approach in separating layers of concern.
As far as the differences between Collection<T> and List<T> you can have a look here
Generic Lists vs Collection
It depends on exactly what you mean by this:
we need to track all changes in every List of BaseEntity
Would it be enough to track changes to objects already in the list? Or do you need to know when objects are removed from/are added to/change positions within the list?
If a list will contain the same items for their whole lifetime, but the individual objects within that list will change, then it's enough for just the objects to raise change notifications (typically through INotifyPropertyChanged) and List<T> is sufficient. But if the list will contain different objects from time to time, or if the order changes, then you should use ObservableCollection<T>.
So while the differences may be interesting (and a previous poster has already covered those), typically you won't have that much of a choice - either you need ObservableCollection<T> or you don't.
List represents a strongly typed list of objects that can be accessed by index. It provides methods to search, sort, and manipulate lists. The List class is the generic equivalent of the ArrayList class. It implements the IList generic interface using an array whose size is dynamically increased as required.
ObservableCollection is a generic dynamic data collection that uses an interface "INotifyCollectionChanged" to provide notifications when items get added, removed, or when the whole collection is refreshed.
Read more about it in this link: http://www.codeproject.com/Articles/42536/List-vs-ObservableCollection-vs-INotifyPropertyCha
One more important difference is you can access ObservableCollection only from thread on which it was created where as list can be accessed fromany thread.
I see no problem with that, other than a very marginal performance overhead.
Note that if you modify the internal Lists directly, you are not notified about changes. Also if the objects which are contained in the ObservableCollection are modified you are not notified. Notification occurs only, if elements are added, replaced, removed or moved.
I have a predefined data format, which requires me to have an object like this:
settings:{
settingA:'someValueFromSql',
settingB:'someValueFromAD'
settingC:'someValueFromConfigFile',
settingD:'someValueFromReflection',
settingE:42,
...
}
This settings object is in fact a huge mess of data stitched together from many different sources, but this is how the data is expected by the frontend. I'd like to put the "get/process all data from one source" in a function each, and tape the object together in the end.
So I would have one object
sqlSettings:{
settingA:'someValueFromSql',
settingG:'someOtherValueFromSql',
...
}
returned by function a, and an object
adSettings:{
settingB:'someValueFromAD',
settingV:'someOtherValueFromAD',
...
}
returned by function b, and an object
settings includes adSettings, sqlSettings
where, with at most two simple steps, I can "join together" both objects into a flat third object.
Is this possible with fixed-size objects, without using a generic Dictionary, or am I barking up the wrong tree?
(I'm sure this question was already asked on SO, but I guess I don't find the right words)
It's not possible with a "normal" object, but you can do it with an ExpandoObject and the dynamic keyword. But you need at least .net 4.0
dynamic settings = new ExpandoObject();
//If you try to assign a property that doesn't exist, it is added to the object.
settings.SettingA="sfgd"
Anyway I discourage using this approach. why you don't want to use a IDictionary<string, object> or better a IDictionary<string, MyCustomSettingObject>
--------------------UPDATE---------------------
if the only thing that stops you from using a dictionary is the serialization you can implement the IXmlSerializable Interface and ouput the xml you like:
Proper way to implement IXmlSerializable?
If those partial setting objects have fixed size (meaning fixed number of properties), then you can definitely create a flat object with e.g. only properties to fit all the values in. Then to ease your work, you can try to use Automapper to map the partial objects to the "grouped" object.
http://automapper.codeplex.com/
Otherwise, you will have to stick with the dictionary.
I have a custom type that knows how to compare with others (it implements IComparable), it is working great stored inside an ObservableList.
However there is still somethings lacking in the collection. I am in need of 4 features. A collection that :
Detects duplicates and prevents insertions.
Automatically sorts on every successful insert.
Is observable &
If batches of items are inserted only notifies once the batch is
inserted.
I would like tips on how to make such a collection, what I will need to research/implement etc. I am not looking for code but if you can give that its a bonus.
What I have thought about doing :
Inheriting from ObservableCollection, overriding the add method, checking if the item already exists, if it does ignoring it.
Or
Implementing my own observable collection based off a more generic type like List.
Since you you want to prevent duplicate insertions and you want sorting, a SortedSet might be a good starting position. Since you want notifications, you'll have to extend the standard SortedSet and implement INotifyCollectionChanged and INotifyPropertyChanged. There's an example here and another one here which uses a HashSet instead (which is unordered, but you can easily replace with a SortedSet).
The alternative, which is just as valid, is to go with you first suggestion and extend ObservableCollection.
I'm looking for a collection to manage and merge list of objects using C# ? Do you know where I can find a good tutorial abour collections ?
Actally I'm looking to merge two or three list of objects/entities. These lists can contains the same object (identical id). The merged list should contain only one version of each object/entities. Then I should order the list on a property.
Depending on how you want to merge your collections, you could use any collection that implements IEnumerable<T>, as this interface provides the Union(IEnumerable<T>) method that "merges" and removes duplicates.
You then might want to implement IEqualityComparer<T> to compare your objects using their identity (ID) property.
You could use a HashSet<T> with a custom IEqualityComparer<T>. Or you could use a Dictionary<T1, T2> where T1 is your ID.
I need to sort the data in a Hashtable by a property of the object added to the collection. how to do that? my project uses .NET 2.0, so I can't use any features that do not work by default in .NET 2.0 runtime (I may be able to use some of the C# 3.0 features that will work on .NET 2.0 without adding references to any new dlls). all the objects added to hashtable are of the same type. If I use SortedList and pass Hashtable to it (through constructor), then it sorts only by keys, is there a way to pass custom sorting logic to it?
if you are bound to .NET 2.0 you can use IComparer.
http://codebetter.com/davidhayden/2005/02/27/implementing-icomparable-for-sorting-custom-objects/
a Hashtable is definetly the wrong datastructure if you want to sort something.
#Snoopy said IComparer, that is indeed what you need. Take a look at SortedDictionary.
Take a look at the drawbacks of a hash table. Then look at the advantages and determine if you are using the right data structure. If you very rarely sort, then you may be using the right data structure. In this case, sorting will require you enumerate the values and put them into a list. If sort if frequent, consider moving to a different data structure, like a search tree. If you rarely do lookups/searches, I would consider using an ordinary list.
One option, if you want to stick to creating a sorted list from the contents of a Hashtable, is to write a subclass of IComparer, overload the Compare method as needed, and create a Sorted list using:
SortedList s = new SortedList( new MyIComparer() );
Then add the elements of your Hashtable to the list accordingly.