Click here to Skip to main content
Click here to Skip to main content

Using GetHashCode correctly

, 3 Oct 2011
Rate this:
Please Sign up or sign in to vote.
It may not always be obvious what makes a good source for a HashCode.
This one has caught me out badly and I have posted to a number of forums over the years trying to solve it, but I have finally found the answer.
 
I used to think that overriding GetHashCode was only required to provide a unique identifying key for each instance in a custom collection, and that selecting a subset of the properties (such as would be used for a primary key) would be sufficient. And mostly it is. Where I came unstuck was not realizing that should the user change any of the values making up this "primary key", which typically happens when a user edits the properties of a new instance, the HashCode would also alter for that instance, and that any controls bound to the collection containing that instance would no longer be able to locate it.
 
For me, this was evidenced in the selected items collection of a ListView or ListBox control losing track of the instance that was altered, and not being able to remove it from that collection resulting in more than one row being visibly selected when the user clicked on any other row.
 
To put this into perspective, I often create WPF forms that contain a ListView over a particular collection, and a set of controls where the user can manipulate the properties of the selected instance in the collection. Added to this a button to allow creating a new instance, and one for deleting an existing instance, and you have a very powerful yet simple way of managing data manipulation on one form, without all the hassles of DataGrids or having to resort to sub forms.
 
For adding a new item, the user clicks the New button and the code behind goes about creating the new instance adding it to the collection, and selecting it. If the collection is Observable, and is bound to the ListView, all the other data entry controls only need to bind to the object properties, and then you group them with a DataContext and bind that to the current row in the ListView, and you have your data entry form.
 
But, once the user starts entering data, should they modify any property taking part in identifying the new instance to the ListView, things start going pear shaped. The difficulty I have had in identifying exactly what was going on has been that nowhere have I seen it referenced that UI controls, like ListView, depended on the GetHashCode method of the collections type, and there is no way to debug this problem.
 
What I do now, to get around this specific problem, is to always use a Random number for my HashCode source. You don't have to persist the number, but you do have to make sure the number is generated by the ctor, and that it is only used by the GetHashCode method.
 
I hope this post helps others out there who might be experiencing similar problems.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

About the Author

Rossl321
Web Developer
Australia Australia
No Biography provided

Comments and Discussions

 
GeneralReason for my vote of 2 you say "correctly" means make a ra... Pinmemberjohannesnestler14-Oct-11 1:39 
GeneralFor reference types, you can get the same behaviour by not o... PinmemberRichard Deeming15-Sep-11 8:52 
QuestionUse Interlocked.Increment PinmemberPaulo Zemek5-Sep-11 12:45 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web02 | 2.8.140721.1 | Last Updated 3 Oct 2011
Article Copyright 2011 by Rossl321
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid