As per Prerak K's update comment (since deleted):
I guess I have not presented the question properly.
Situation is this: I want to load data into a global variable based on the value of a control. I don't want to change the value of a control from the child thread. I'm not going to do it ever from a child thread.
So only accessing the value so that corresponding data can be fetched from the database.
The solution you want then should look like:
UserContrl1_LOadDataMethod()
{
string name = "";
if(textbox1.InvokeRequired)
{
textbox1.Invoke(new MethodInvoker(delegate { name = textbox1.text; }));
}
if(name == "MyName")
{
// do whatever
}
}
Do your serious processing in the separate thread before you attempt to switch back to the control's thread. For example:
UserContrl1_LOadDataMethod()
{
if(textbox1.text=="MyName") //<<======Now it wont give exception**
{
//Load data correspondin to "MyName"
//Populate a globale variable List<string> which will be
//bound to grid at some later stage
if(InvokeRequired)
{
// after we've done all the processing,
this.Invoke(new MethodInvoker(delegate {
// load the control with the appropriate data
}));
return;
}
}
}
Yes, it is important if your item will be used as a key in a dictionary, or HashSet<T>
, etc - since this is used (in the absence of a custom IEqualityComparer<T>
) to group items into buckets. If the hash-code for two items does not match, they may never be considered equal (Equals will simply never be called).
The GetHashCode() method should reflect the Equals
logic; the rules are:
- if two things are equal (
Equals(...) == true
) then they must return the same value for GetHashCode()
- if the
GetHashCode()
is equal, it is not necessary for them to be the same; this is a collision, and Equals
will be called to see if it is a real equality or not.
In this case, it looks like "return FooId;
" is a suitable GetHashCode()
implementation. If you are testing multiple properties, it is common to combine them using code like below, to reduce diagonal collisions (i.e. so that new Foo(3,5)
has a different hash-code to new Foo(5,3)
):
unchecked // only needed if you're compiling with arithmetic checks enabled
{ // (the default compiler behaviour is *disabled*, so most folks won't need this)
int hash = 13;
hash = (hash * 7) + field1.GetHashCode();
hash = (hash * 7) + field2.GetHashCode();
...
return hash;
}
Oh - for convenience, you might also consider providing ==
and !=
operators when overriding Equals
and GetHashCode
.
A demonstration of what happens when you get this wrong is here.
Best Solution
This is as designed. When you press F5 you are redoing what you just did which was a postback. To prevent this you have an endless amount of solutions such as:
Use a session variable on initial load and once it is posted the first time (saved), clear the value. Make sure you are checking for the presence of this value.
You could also do the check DB side and verify that you are not inserting identical data (which may not work as it could be valid in your scenario)
In the past I have prevented this with edits for example by storing a revision number and having it submit the revision number with the posted data. When saving, if the revision numbers don't match (since it is changed with each update and the check is done DB side) then the update fails and I would display a message.
For new data, you could also do a Response.Redirect to a 'complete' page which gives them updated information of success / failure. If they hit refresh, they will just be reloading the completed page and not the page that was doing the insert / updating.
Again there are so many different solutions. Nothing is perfect for every scenario so you will need to find out which works best for you.