Handlers for Form Changes

[Liz]

I have a form with about 25-30 TextBoxes, ComboBoxes, etc; if the user does
not make any changes to the form I don't want to post a "Cancel Changes?"
dialog when they exit the form ... so this is what I'm doing to detect
changes:
// this gets called from the Form_Load event handler

private void SetFormStateChangeHandlers(Control parent) // on 1st
entry, "this" is passed to the method
{
foreach (Control control in parent.Controls)
{
if (control is TextBox || control is ComboBox)
{
control.TextChanged += new
EventHandler(controlStateChanged);
}

// handle container controls which might have child controls
if (control.Controls.Count 0)
{
SetFormStateChangeHandlers(control);
}
}
}

// set the class-level var to be tested on form exit
void controlStateChanged(object sender, EventArgs e)
{
FormHasChanged = true;
}
This *does* work, but there is at least one shortcoming, which is that if
the user changes a control and then undoes the change, I'm not detecting
that ... also, I'm just wondering if there's a better, more straightforward
way of handling the issue ... any other ideas out there?

TIA
Liz

[Peter Duniho]

Liz wrote:

[...]
This *does* work, but there is at least one shortcoming, which is that if
the user changes a control and then undoes the change, I'm not detecting
that ... also, I'm just wondering if there's a better, more straightforward
way of handling the issue ... any other ideas out there?

Personally, I think the way you're doing it now is actually reasonably
elegant. It's not uncommon at all for a UI to consider any change, even
if it's eventually manually reversed by the user, to be considered a
"change".

That said, it appears to me that you're only actually look at changes to
text fields. So what you're really interested in is whether the text in
the text field is the same.

It seems to me that this would not actually be difficult to implement.
After all of the fields have been initialized, just add all of the
values to a Dictionary<object, stringwhere the control reference is
the key and the Text property value is the value.

Then when you are making the decision as to whether to prompt the user
to discard their changes, run through all the controls again except this
time compare the value in the dictionary with the current value.

If none of the text values are different, then you can safely suppress
the prompt.

Pete

[Liz]

"Peter Duniho" <Np*********@NnOwSlPiAnMk.comwrote in message
news:13*************@corp.supernews.com...

Liz wrote:

Personally, I think the way you're doing it now is actually reasonably
elegant. It's not uncommon at all for a UI to consider any change, even
if it's eventually manually reversed by the user, to be considered a
"change".

which probably makes sense; if they "fooled with it" maybe they should
confirm ...

That said, it appears to me that you're only actually look at changes to
text fields. So what you're really interested in is whether the text in
the text field is the same.

actually there are some CheckBoxes my code sample didn't expose in the
interest of keeping it brief... but I guess I could handle those as well; I
was initially concerned about a performance hit; I don't have a code
profiler but I put a crude timer on the event handler fixups and it looks
like they're handled quite quickly .. which makes sense if you stop looking
at code and start thinking about machine instructions instead

It seems to me that this would not actually be difficult to implement.
After all of the fields have been initialized, just add all of the values
to a Dictionary<object, stringwhere the control reference is the key and
the Text property value is the value.

Then when you are making the decision as to whether to prompt the user to
discard their changes, run through all the controls again except this time
compare the value in the dictionary with the current value.

makes sense ... might try that .... thanks, Peter ...

L

[Peter Duniho]

Liz wrote:

[...]
actually there are some CheckBoxes my code sample didn't expose in the
interest of keeping it brief... but I guess I could handle those as well; I
was initially concerned about a performance hit; I don't have a code
profiler but I put a crude timer on the event handler fixups and it looks
like they're handled quite quickly .. which makes sense if you stop looking
at code and start thinking about machine instructions instead

Exactly. Compared to all the other work your computer has to do to
handle just one user-input action, the act of calling an event handler
is a minuscule effort. Even if you did that on every single control in
the form.

Of course, if you are saving all the values to start with and then just
checking them at the end, that's even less of a performance hit than the
implementation you've got now (with handling the TextChanged event),
since it only happens once at the beginning and once at the end.

Not that it should really matter either way. I think in this case,
neither method is going to be a problem performance-wise, so you should
just implement the design that you think makes the most sense for your
users.

Pete