How would I tell when a winform is "dirty"?

[David C]

I need to know if at least one of the winform's controls have been
edited by the user. Controls can have textboxes, combo boxes,
datagrid, etc.

If any one of the forms have been touched and the user hits the exit
button, I want the form to ask if the changes should be saved to the
database.

So what I am looking for is really simple. Thanks.

 

[Paul Werkowitz]

Am 28 Feb 2007 02:19:56 -0800 schrieb David C:

I need to know if at least one of the winform's controls have been
edited by the user. Controls can have textboxes, combo boxes,
datagrid, etc.

WinForms does not have any notion of "dirtyness". That means: you have to
do it yourself.

You have many possibilities. E.G. you can
- intercept the message flow and look at each message and each target
whether it will cause dirtyness
- have each control report a TextChanged-Event (or whatever) to a
controller. This controller then provides clean/dirty states to clients.

I need such a functionality in nearly every form I have. Therefore I wrote
a fairly complex controller that does it all by itself (yes, uses
reflection). My controler also provides information about the controls that
have changed since the last database-update and it can make the needed
SQL-statements for load and save.

If any one of the forms have been touched and the user hits the exit
button, I want the form to ask if the changes should be saved to the
database.

Look at the onClose-Event of the form etc. Ask the controller(s) whether
something is dirty, and react accordingly.

So what I am looking for is really simple. Thanks.

Simple - yes. But tedious.



My 2 cents....
Paule

 

[David C]

Simple - yes. But tedious.

That is what I was hoping to avoid for the sake of maintainability as
well as my sanity.....having to write an event for each element, and
since each element fires a different event when gets "dirty," I'd have
to take all those things into consideration.

TextBoxes and Combos are pretty simple, but then I have some third
party controls as well.

 

[RobinS]

If you are binding your controls to a datasource, you can put a
bindingsource between the two, and then only look for one event. You bind
your BindingSource to your DataTable or DataSet or List, then bind the
controls to the BindingSource.

myBindingSource.DataSource = myTable
myDGV.DataSource = myBindingSource
CustomerTextBox.DataBindings.Add("Text", myBindingSource, _
"CustomerName", True)
(etc)

Then try attaching an event to myBindingSource.ListChanged. I know this is
fired whenever a record is added, modified, or deleted. I'm hoping it's not
fired when all they are doing is changing position.

Robin S.
-----------------------------------

 

[Paul Werkowitz]

Am 1 Mar 2007 11:16:55 -0800 schrieb David C:

That is what I was hoping to avoid for the sake of maintainability as
well as my sanity.....having to write an event for each element, and
since each element fires a different event when gets "dirty," I'd have
to take all those things into consideration.

TextBoxes and Combos are pretty simple, but then I have some third
party controls as well.

C'mon! Its not so difficult. For example, in the Controller you can make a
function to iterate over all controls in the form. For each control you
determine the type and hook up the appropriate event that signals a state
change. Of course, all these event handlers are in the Controller class and
simply set dirty member of the controller to true.

Yes, there are different if-the-else for Comboboxes, Textboxes, Checkboxes
etc. And if your custom controls provide any means to signal a data change,
put the needed code to set up the event wiring in another else-if-part.

As I said: tedious, yes, but you have to do it only once for all software
you'll ever write.

A slightly more professional version would have adapter classes for each
control. Advantage is that you can intercept when certain things happen.
Just derive a special adapter..

One also can derive from the controls and make them implement an
appropriate interface. The controller then deals in terms of the interface
only.

I also looked into data binding, which I found was not useable for larger
apps.

My 2 cents
Paule