[2005] How do you all maintain state of data on a form

I'm curious what tricks and techniques you all have developed for maintaining the state of data on a form.

In the case of lots of textboxes, for instance.

How do you track the values - such as the value from the DB, value of the textbox currently, value of the textbox after change. Value as typed - value as displayed with edit masks...

Whether the textbox currently contains invalid data - whether it's been changed...

Whatever you all need to track for state - how do you store and reference that.

I dont :D I just reference the DB value if I want to load something, or the textbox value if I want to save something to the DB. If I need something to happen such as a warning message appearing if the user has modified the textbox value without saving it to the DB then I just set a boolean like IsSaved to True when they click the Save button and then set it to false in the TextChanged event of any textboxes. Bound to be a better way but its always worked fine for me :)
Probably not the kind of answer you were looking for but oh well.

PS You could of replied to my PM about the MDI example you wanted creating!

I'll get back to the MDI thread - it got so little attention that it really didn't serve my purposes...

Back on topic - don't you ever find that you need to track some other fact about data state and find you are creating additional bools? How do you convert masked data - like phone's with ()-'s to just 10 digits for putting back in the DB?

What has converting a value when you save it to the database got to do with tracking the state of variables? Each time you came to save it, you would perform the same checks/conversion so I dont see how that relates to the data's state.
In answer to your question though - I havent ever needed to do anything more than what I mentioned in my last post. I guess you'll get a better answer from the people who have been programming for a lot longer than me :)

I would have a class that maintained the state. The controls could populate members of the class via properties, and a class instance could be passed to the form to fill all the controls. The class instance could also be passed to the DB wrapper and either be filled from the DB, or written to the DB. I have written many variations on this design, but that's the general plan.

That is what I assumed - would you mind showing some code on how you reference it from the form? Do you always create a new property for every "data element"? Just trying to get ideas on how people implement this...

I have no code handy, and won't for about five hours, by which time this may well be moot (wrong computer at the moment). When I have done this completely, there is generally one property for every data element, but certainly not one property per control. For instance, you might create a phone number with a textbox for the area code and another for the main number, or something like that. On the other hand, there are instances where I had more than one property for one data element. For instance, there were some sample numbers where half the number could be set for a session, such that the user only had to enter the second half of the number for each record. I maintained the two halves of the sample number as two members, and exposed properties that would allow access to the sample number, or either part of the sample number.

One of the advantages I found for doing this was that it was possible to have partial records. The user could enter a bunch of information for a new record, then decide to edit an existing record from a data table. The current class instance would remain in a partial state, a new class instance would be created to hold the data from the record to be edited, and all the controls would be populated from that new instance. Once the editing was done, the new instance would be passed to the DB class to be salted away, and the old, working instance, would be restored.

This was particularly useful for PDA apps where the controls for entering a record were spread across numerous panels (my stand-in for forms), so the user could, at any time, switch to a tabular view of existing data and begin editing a row. I needed to be able to save current state, re-populate with the new state until editing was finished, then restore the old state once editing was finished.

Look into the CSLA classes from Rocky Lhotka.... he has aLOT of that built right in... validation, state, etc... We used it as a starting point for our base Business class (so we have a BaseBisObject and a BaseBisList, and then BaseReadOnlyBisObject and BaseREadonlyBisList -- I'll let you figure out the diff between them.) from which all of our objects inherit.... the base classes hold all of the basic flag manipulations, tracks if it's a new object, a changes object, a deleted object, old values, new values (we actually have started to introduce an "oops! NO! Go back! GO BACK!" option to our newer screens. Anyways, we used it as Rocky intended, not as-is, but as a start point, adding in features we needed, while taking out some unimportant items we didn't need.

When you inherit the baseclass, there's a couple of functions that can be overridden, one of which is the validation. It allows you to specify that property X, has YYYYYY format.... or must be a number... or alpha only.... or is a date..... and so on. When something doesn't match, it fires off something, not sure what it is exactly, but then our UI detects it and uses the error provider to add a warning icon next to the bound control along with the error message. the next time I have an app that I need to edit the data, I plan to use it.... I probably should buy the book too.... might make a good reference.

-tg