2

How do I go about saving dynamically added WinForms controls?

My application should be able to do this for the following: TabPage, GroupBox, RadioButton, and CheckBox. The RadioButton and CheckBox both correspond to a block of text that will be outputted when selected. I understand the process would consist of creating the controls first and storing them, but I am unsure whether what I have found so far (listed below) are the most apt ways to go about doing so.

Creating the Controls

The topic I linked suggested the use of objects that inherit from specific controls. This means I should just instantiate such objects as needed and assign the dynamic values accordingly. It appears to be the easiest way to do this step unless someone suggests otherwise.

Storing Controls

For this part, I was thinking of:

A. Database

My application uses SQLite to save the text and the control properties could also be saved into and retrieved from it via a method from the aforementioned classes.

B. XML

Perhaps a configuration file that I will make myself to write and read from? Tutorials seem aplenty on how to process XML, which makes it doable for me. I am unsure, however, whether storing lengthy text is advisable here, and likewise for what follows.

C. Serialization

Researching got me 3 results--JSON, XmlSerializer, and BinaryFormatter--all of which I have not had experience with as far C# is concerned. There seems to be difficulty in deserializing controls, and each control needs to be serialized differently.

D. UserSetting

This appears to be similar to XML, only that it uses StringCollection or Settings.setting instead.

Suggestions, recommendations, or corrections anyone?

Community
  • 1
  • 1
styx
  • 87
  • 7
  • Why would you save the control itself? Wouldn't it be better to save the content that the controls represent/display? – Xiaoy312 Aug 24 '15 at 16:42
  • This seems to be a http://meta.stackexchange.com/questions/66377/what-is-the-xy-problem – Xiaoy312 Aug 24 '15 at 16:43
  • 1
    Controls behave as any other instance/variable. In the most logical scenario, you would be storing them in memory (unless wanting thousands of controls and/or having to be used accross different executions of the application). The whole point of a control in a winforms application is being shown in the GUI and thus you would have to add the given control(s) to the corresponding container (control). You can exclusively rely on these containers for storage purposes or also account for further structures (i.e., arrays of controls) to ease certain actions. – varocarbas Aug 24 '15 at 16:43
  • The few properties you need to save are identical to those you needed to create them dynamically. In fact using the same routines sounds natural, so use whatever way to save fits your other needs best.. – TaW Aug 24 '15 at 16:44
  • @Xiaoy312 It appears to be so, lol. To answer my question, then, I simply need to store the properties. Which one of the above would you recommend using? – styx Aug 24 '15 at 16:49
  • @varocarbas I see. I seem to have assumed there is a difference between controls already on the form, and the ones I create "later", forgetting that they are all created at run-time anyway. – styx Aug 24 '15 at 16:56
  • @TaW Is it more "traditional" to save these properties via the database or...? – styx Aug 24 '15 at 16:56
  • These are all valid options. It is really depends on your requirements. Without any context, my answer will be just personal preferences. And btw, you will need to use a combination of your options. A&D are ways of storing, and B&C are just way of serializing. – Xiaoy312 Aug 24 '15 at 16:59
  • 1
    Since your UI is dynamic, I would suggest you to use xml. You can define your custom version of it, kind of like HTML or XAML. – Xiaoy312 Aug 24 '15 at 17:01
  • Imagine that you want to create 3 numericUpDowns at runtime located in different places of the main form. Right after defining them, you would have to do something like this.Controls.Add(num1); this.Controls.Add(num2) and this.Controls.Add(num3). Additionally to be shown in your form, now all of them are stored in the global collection this.Controls. On the other hand, there are quite a few scenarios where you might prefer to create your own collections to perform certain actions easier; exactly the same than what happens with other variables (included in various collections at the same time). – varocarbas Aug 24 '15 at 17:03
  • @Xiaoy312 Would I be correct in saying that going with the database would skip serialization and deserialization? I mean, I can just use database attributes to save and retrieve properties for each control e.g. x_value, y_value. – styx Aug 24 '15 at 17:08
  • The processing of converting an object to data(binary/text) is called serialization. http://stackoverflow.com/questions/633402/what-is-serialization – Xiaoy312 Aug 24 '15 at 17:11
  • 1
    @varocarbas At least I think I got that part down pat fortunately, lol. Thank you, I appreciate your time and input! – styx Aug 24 '15 at 17:14
  • 1
    You can't serialize the UI. Instead, you need to serialize/store your **data**. The main problem with winforms is that it doesn't encourage the proper separation of these concepts. I suggest you leave archaic technology behind and use a proper declarative UI and databinding, which are properly supported by modern UI frameworks such as WPF. – Federico Berasategui Aug 24 '15 at 17:14
  • @Xiaoy312 Thank you so much. I believe I already know what I should be _actually_ doing. – styx Aug 24 '15 at 17:18
  • @HighCore Thanks for your suggestion! I'm looking into it, and I think this phrase has never been more attractive: "separation of designer code and logic." – styx Aug 24 '15 at 17:26
  • I can't recommend either way as I don't know anything about your application's setup. If it is DB centric anyway then, yes saving to the DB is fine.. – TaW Aug 24 '15 at 17:42
  • @TaW You're right, thanks! – styx Aug 25 '15 at 14:59

0 Answers0