6

I have windows form. There are many controls present in form. All controls will fill with values when form load. All controls are editable say textbox, dropdownlist, radio buttons, etc. at bottom there is update button.

When user change value and press update button updated values will save.

But sometimes user haven't change any value and press update.

So now, How to know user not changed any value to update? Is there any standard way to know, user edited but not change any existing value?

Note: I don't want to check all values one by one.

Sam
  • 433
  • 1
  • 10
  • 26
  • Most controls raise a `Changed` event for each property (so `CheckedChanged` for a `CheckBox`, `ValueChanged` for a `DatePicker`, etc.) so you could listen for those events and set a flag accordingly, clearing it after setting values, or a successful update... – Rowland Shaw Jul 18 '14 at 11:07

3 Answers3

2

You need to add handlers for each control.

Please see this post for a nice example:

Have event fire whenever any changes made to textboxes, comboboxs, etc. inside form

Community
  • 1
  • 1
Beakie
  • 1,948
  • 3
  • 20
  • 46
1

I always checked, yes, the values one-by-one. You can do that, or you can map every TextChanged/SelectedIndexChanged/etc. to event methods and set some bool there to store that you know something has changed. But yeah, there's no really good or nice way I know of doing this. It's just kinda one of those tedious things that UIs require. At least as far as I know. I moved on, hesitantly for sure, from Windows Forms a while ago.

I'd personally be tempted, if I were writing something very seriously, to use the events approach. It just seems more prone to success, and you don't have to store the old values and compare them. Of course, it can be a little difficult to troubleshoot and debug, since the designer will be handling most of your code for you. So that has advantages and disadvantages to it. Given that, my one piece of advice should you elect to go the events route, register your events manually in the constructor and not the designer. I've just so many times seen the designer get confused after some change, or I forget to do something or not do something, and suddenly an event isn't linked and I don't test it for a while, then I'm confused when I do. Handling that aspect of the code yourself can be a good reminder, if nothing else. It might be a little messier, but I like to think of that as a good kind of mess, relatively speaking.

Note also, of course, that there's no need to have an event for each and every control of the same type. Keep it down to one and, if you need, check who the sender is. But I wouldn't even do that unless you have to. Just flag your bool HasChanged or whatever and look at that when you're looking for changes at the end.

Matthew Haugen
  • 12,916
  • 5
  • 38
  • 54
0

The controls should fire a value changed / text changed / selection changed event, which you can add handlers to. If users have edited something, such event(s) will fire and your handler can set a status so that the program knows the user has changed something or not when the user clicks on Update.

Xeon
  • 156
  • 8