none
IBindingList - AddIndex/RemoveIndex ??? RRS feed

  • Question

  • Okay,

    What precisely are these for?  I mean, I've looked at all the examples (most of which do not support sorting or searching, so they are of no help) but even the few instances that aren't as insanely complex as a DataView, seem to indicate (de facto by code) that AddIndex is superfluous.  ApplySort() takes the sortProperty's PropertyDescriptor and the SortDirection and implements the sort by way of a single item property.  If we expand out to IBindingLIstView, with Advanced Sorting, the ApplySort() method for that interface provides an array of PropertyDescriptors, by which to sort by multiple properties.  the IBindingList.Find() method simply provides a PropertyDescriptor and an object value to search for.  THis simply is as easier as iterating through a list and using reflection from the PropertyDescriptor, comparing the value of the individual items until you find the one that equals the object key provided by the find method. 

    So if ApplySort() (for both IBindingList & IBindingListView) handles the sorting, and IBindingList.Find() handles the searching, what is the purpose of AddIndex() and RemoveIndex()

    Thanks

    Jaeden "Sifo Dyas" al'Raec Ruiner


    "Never Trust a computer. Your brain is smarter than any micro-chip."
    PS - Don't mark answers on other people's questions. There are such things as Vacations and Holidays which may reduce timely activity, and until the person asking the question can test your answer, it is not correct just because you think it is. Marking it correct for them often stops other people from even reading the question and possibly providing the real "correct" answer.
    Monday, April 26, 2010 5:50 AM

Answers

  • Hi,

    IBindingList.AddIndex adds the PropertyDescriptor to the indexes used for searching.

    Now, I agree with you that this formulation is very lax, but hey, this is simply a description of an interface method, and an interface has no ideea of its specific implementation, it's simply a contract based upon some general semantics.

    Internally, DataView keeps a Dictionary<string, Index> object to keep track of the columns currently indexed without the need to iterate through the table's indexes again and again. When IBindingList.AddIndex(PropertyDescriptor property) is called, the method first identifies the index of the DataColumn associated with PropertyDescriptor.Name. Then it updates the Dictionary<string, Index> with the found index, and calls index.AddRef() to add the index to the table's list of indexes if the index does not yet exist. As a result, now both the dictionary and the list of indexes associated with the DataTable have a new entry which will be later used when performing operations like searching records.

    Marcel

    • Marked as answer by JaedenRuiner Wednesday, April 28, 2010 6:06 PM
    Monday, April 26, 2010 11:04 AM

All replies

  • Hi,

    IBindingList.AddIndex adds the PropertyDescriptor to the indexes used for searching.

    Now, I agree with you that this formulation is very lax, but hey, this is simply a description of an interface method, and an interface has no ideea of its specific implementation, it's simply a contract based upon some general semantics.

    Internally, DataView keeps a Dictionary<string, Index> object to keep track of the columns currently indexed without the need to iterate through the table's indexes again and again. When IBindingList.AddIndex(PropertyDescriptor property) is called, the method first identifies the index of the DataColumn associated with PropertyDescriptor.Name. Then it updates the Dictionary<string, Index> with the found index, and calls index.AddRef() to add the index to the table's list of indexes if the index does not yet exist. As a result, now both the dictionary and the list of indexes associated with the DataTable have a new entry which will be later used when performing operations like searching records.

    Marcel

    • Marked as answer by JaedenRuiner Wednesday, April 28, 2010 6:06 PM
    Monday, April 26, 2010 11:04 AM
  • So they are basically associated with search (Find() method) but designed as a precursor, or "optimization" of sorts.  That basically, AddIndex is called when the user attempts to perform a search, and if the index doesn't previously exist, it adds one, so future searches are more streamlined?

    If that's the case, since i'm adding this functionality to a Generic Collection, there doesn't seem to be any need for me to implement it.

    *shrug*

    Thanks

    Jaeden "Sifo Dyas" al"Raec Ruiner


    "Never Trust a computer. Your brain is smarter than any micro-chip."
    PS - Don't mark answers on other people's questions. There are such things as Vacations and Holidays which may reduce timely activity, and until the person asking the question can test your answer, it is not correct just because you think it is. Marking it correct for them often stops other people from even reading the question and possibly providing the real "correct" answer.
    Monday, April 26, 2010 1:44 PM
  • Hi,

    Well, if you need to search effectively over large data, indexing is generally a good idea, since it will speed up the retrieval. Normally, you will not have to implement a collection supporting IBindingList from the scratch, you can simply use BindingList<T>.

    Take a look at the chapter Understanding Data-Binding Interfaces from Brian Noyes's Data Binding with Windows Forms 2.0 for in-deep explanations.

    Marcel

    Monday, April 26, 2010 5:07 PM
  • Yea,

    As with many things .Net in origin, i do find myself reinventing the wheel, mostly because the first wheel is chipped, rough, and not fully fleshed out.  I've revamped the Dataset/DataTable/TableAdapter to be fully asynchronous and with page based loading for larger databases and written a generator for it, I've revamped the ApplicationSettings, to provide run-time dynamic setting creation and saving, which if you've ever delved into the ApplicationSettings class, adding a settings property is a royal pain.  And one of my first was creating my own collection library, because I could have A type collection, B type collection, or C type collection, but I couldn't easily have both, or all three in one.  So, my collection base already incorporates sorting and list change awareness as part of the default, and the Keyed collection inherits from this so I have an indexed, sortable collection, where I can also look up items by a key. Overall, i figured it was only a small step to adding binding list support, and i've fully now, written in BindingList, and BindingLIstView (for advanced sorting) and once this is set up and tested, I'll be investigating adding the Filter support as well, which means I'll be back on that one, with a different query on how filtering is traditionally handled. 

    In the long run, my collection library is far superior to the default .net one, and as with many of my creations, i take the concept and make it complete from the get go.  I don't like writing code twice, and many of the features I've built in to this library i use and require so often that i would be reimplementing it every time i tried to use a Collection(of T), and then i'd have to implemented again if I wanted to use a BindingList(of t) as well, not to mention adding keyed support to the bindinglist(of t), etc, etc, etc.

    Thanks for the pointers though, they've been quite helpful in my re-engineered design.

    J"SD"a'RR


    "Never Trust a computer. Your brain is smarter than any micro-chip."
    PS - Don't mark answers on other people's questions. There are such things as Vacations and Holidays which may reduce timely activity, and until the person asking the question can test your answer, it is not correct just because you think it is. Marking it correct for them often stops other people from even reading the question and possibly providing the real "correct" answer.
    Wednesday, April 28, 2010 6:05 PM