How can I track what properties the user has changed?

[Darryl Minard]

Hello,

I'm using simple data bindings to wire windows forms controls to the
properties of an object (the data source). I'd like to track which
properties have been modified by the user.

I'm looking for recommendations about how to do this in a generic
fashion. I'd like to avoid incorporating XXXChange events into all my
data source objects. I was hoping to find an appropriate binding
framework event to monitor, but I haven't had luck so far. I considered
monitoring the various XXXChange events on the controls but I'd need a
way to detect whether or not the change was caused by the user or by a
synchronization with the data source.

Suggestions would be appreciated.

Regards,

Darryl

tell me if it is possible to monitor the activities of the data binding
to tell which properties have been modified? I was hoping to find an
event

 

[Darryl Minard]

Hi Ying-Shen, Steve

Thank you both for your responses. In the end, I settled for monitoring
the Validation events emitted by the various controls.

I'm impressed at how quickly the binding framework allows one to develop
a working solution. However, I'm unimpressed by how difficult it is to
progress beyond the simple case.

Consider the task of adding undo/redo to an application. The undo/redo
action should allow user-initiated changes to be reversed and re-
applied. It is necessary to detect user-initiated changes to the
business object. It would be insufficient to monitor the various
property change events emitted by the business object because the event
handler would be unable to tell whether the change originated from the
UI. Furthermore, it would be insufficient to monitor the validated
event because this event provides no details about the binding activity
(before/after property values).

While it may be possible to use DataSets to isolate property changes,
unless DataSets are otherwise used by the app, that technique provides a
very round-about solution.

I wonder if it would be possible to accomplish my goals by extending or
decorating the PropertyManager...acting on Push/PullData()?

Regards,

Darryl

 

[David]

Followup-To: header set to
microsoft.public.dotnet.framework.windowsforms.databinding.

Hi Ying-Shen, Steve

Thank you both for your responses. In the end, I settled for
monitoring the Validation events emitted by the various controls.

I'm impressed at how quickly the binding framework allows one to
develop a working solution. However, I'm unimpressed by how difficult
it is to progress beyond the simple case.

Consider the task of adding undo/redo to an application. The
undo/redo action should allow user-initiated changes to be reversed
and re- applied. It is necessary to detect user-initiated changes to
the business object.

But that raises the question of which object should be handling this.
There's a few options. It's easy enough to handle it in the business
object, just implement IEditableObject. Or, the UI could handle it...

It would be insufficient to monitor the various property change events
emitted by the business object because the event handler would be
unable to tell whether the change originated from the UI.

Either don't throw the event on data synchronization, or don't subscribe
to the events until after initialization. In either case, every event
you catch is going to be UI-generated (or at least presentation
layer-generated, which should mean the same thing).

Furthermore, it would be insufficient to monitor the
validated event because this event provides no details about the
binding activity (before/after property values).

I'm not so sure I see what you mean here. If you want undo, somebody
has to store the original values. In the validated event, since you
already know the original value, you should be able to tell if the new
value is a change.

If you're looking specifically for an event that only occurs during
databinding, the Binding.Parse event is good for that.

While it may be possible to use DataSets to isolate property changes,
unless DataSets are otherwise used by the app, that technique provides
a very round-about solution.

Well, the DataSet solution seemed to just be a convenient place to hold
onto original/changed values in a generic way. Any kind of undo/redo
solution is going to require something like this.

I wonder if it would be possible to accomplish my goals by extending
or decorating the PropertyManager...acting on Push/PullData()?

I think it's an interesting problem, but while I understand what you're
after in a vague sense, I don't really understand the specifics.