Restoring Initial UI State
-
Thank you, I'll give this a try. Very simple and seems like it should do exactly what I need. :)
djj55: Nice but may have a permission problem Pete O'Hanlon: He has my permission to run it.
The only problem with doing that is that if your form code maintains a state it's not going to get reset. It'll only destroy and recreate the controls to however you had them set in the Form Designer and property settings.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
The applications I write typically involve a lot of data entry, for use in a warehouse/manufacturing environment. Sometimes there can be many different fields, sometimes not so much. But I've always found it a bit tedious and time consuming to restore the UI to its initial state when the user saves an entry, for example. I mean, a form could have buttons that are disabled initially, a few entry fields that are disabled at first waiting for other input, several input fields that need to be cleared, etc. What is the best method to go about resetting a form once the user is done? I've always just used "thisField.Enabled = false;" and "thatField.Text = string.Empty;" and so on. But is there a more efficient method for achieving this?
djj55: Nice but may have a permission problem Pete O'Hanlon: He has my permission to run it.
Matt U. wrote:
But I've always found it a bit tedious and time consuming to restore the UI to its initial state when the user saves an entry, for example.
// Dirty hack
Form.Controls.Clear();
InitializeComponent();Alternatively, loop all controls using reflection (no, it ain't that slow, just a bit of an exercise to get recursion working) and clear them. How do your edit-forms look like? Mine could be explained as a
PropertyGridon a dialog-form. It has an extra button called "reset", which just reloads a cloned object into the propertygrid. It's not a real property-grid anymore; it's a custom control that behaves in a similar way (in code), but that renders a more 'traditional' winform. I choose this architecture out of convenience; a single modification in the object, and it's pushed to a Memento-pattern (undo/redo stack). When closing, the content of both get serialized and saved. When loaded, both are restored - it makes users happy when they find out that they can "undo" yesterday's changes, even if the PC was turned of in the mean time.Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
Oh duh... OK... You can reset a form...
myForm.Controls.Clear();
myForm.InitializeComponent();While it's a good idea :thumbsup:, I'd still call it a hack, unless xml-documentation is included with some explanation like Dave posted. Private members would not be reset, and the "OnCreate" event wouldn't fire on it's own. It might contain some "form magic" for setting the form up as well.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
Matt U. wrote:
But I've always found it a bit tedious and time consuming to restore the UI to its initial state when the user saves an entry, for example.
// Dirty hack
Form.Controls.Clear();
InitializeComponent();Alternatively, loop all controls using reflection (no, it ain't that slow, just a bit of an exercise to get recursion working) and clear them. How do your edit-forms look like? Mine could be explained as a
PropertyGridon a dialog-form. It has an extra button called "reset", which just reloads a cloned object into the propertygrid. It's not a real property-grid anymore; it's a custom control that behaves in a similar way (in code), but that renders a more 'traditional' winform. I choose this architecture out of convenience; a single modification in the object, and it's pushed to a Memento-pattern (undo/redo stack). When closing, the content of both get serialized and saved. When loaded, both are restored - it makes users happy when they find out that they can "undo" yesterday's changes, even if the PC was turned of in the mean time.Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
Eddy Vluggen wrote:
they can "undo" yesterday's changes
THAT, is hard freeking core, dude. I like it :) As noted before though, I think the only way to make it behave like a 'new' form is to have it be a new form... but if it's your main form or something, that might require hacking program.cs.
-
The only problem with doing that is that if your form code maintains a state it's not going to get reset. It'll only destroy and recreate the controls to however you had them set in the Form Designer and property settings.
A guide to posting questions on CodeProject[^]
Dave KreskowiakBut isn't that what he wants? Instead of "clearing" everything, which sets textboxes to empty string and whatnot, I thought he wants the "default" values from the form designer to show up - otherwise, yeah, you only need to Form.Controls.Clear() and call it good.
-
But isn't that what he wants? Instead of "clearing" everything, which sets textboxes to empty string and whatnot, I thought he wants the "default" values from the form designer to show up - otherwise, yeah, you only need to Form.Controls.Clear() and call it good.
I don't let the controls determine the status of any state machine I've got behind the forms. The state machine determines the state of the controls and the controls reflect that. I know there are plenty of cases where the app or form is so simple that there is no state machine behind it, but there are too many noobs out there who rely on the controls to "store" data and determine the state of a form or app based on, say, the text of a button, or if it's enabled or not. That's not the proper way to do it.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
The applications I write typically involve a lot of data entry, for use in a warehouse/manufacturing environment. Sometimes there can be many different fields, sometimes not so much. But I've always found it a bit tedious and time consuming to restore the UI to its initial state when the user saves an entry, for example. I mean, a form could have buttons that are disabled initially, a few entry fields that are disabled at first waiting for other input, several input fields that need to be cleared, etc. What is the best method to go about resetting a form once the user is done? I've always just used "thisField.Enabled = false;" and "thatField.Text = string.Empty;" and so on. But is there a more efficient method for achieving this?
djj55: Nice but may have a permission problem Pete O'Hanlon: He has my permission to run it.
If you are using wpf with MVVM then all you have to do is make the VM serializable, and save it.
-
Eddy Vluggen wrote:
they can "undo" yesterday's changes
THAT, is hard freeking core, dude. I like it :) As noted before though, I think the only way to make it behave like a 'new' form is to have it be a new form... but if it's your main form or something, that might require hacking program.cs.
-
While it's a good idea :thumbsup:, I'd still call it a hack, unless xml-documentation is included with some explanation like Dave posted. Private members would not be reset, and the "OnCreate" event wouldn't fire on it's own. It might contain some "form magic" for setting the form up as well.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
Well, I used the "hack" and it works just fine. I'm still going to experiment with other options based on everyone's input. But for my purposes, the "hack" gets the job done for now at least. :-D
djj55: Nice but may have a permission problem Pete O'Hanlon: He has my permission to run it.
-
I don't let the controls determine the status of any state machine I've got behind the forms. The state machine determines the state of the controls and the controls reflect that. I know there are plenty of cases where the app or form is so simple that there is no state machine behind it, but there are too many noobs out there who rely on the controls to "store" data and determine the state of a form or app based on, say, the text of a button, or if it's enabled or not. That's not the proper way to do it.
A guide to posting questions on CodeProject[^]
Dave KreskowiakYeah definitely incorrect designs would make it more tricky, but I get the impression this particular form doesn't have any initial state other than what was set in the designer...