So I've seen many questions that talk about the best method to store settings but haven't really seen any that deal with my situation.
Basically my app today has one settings tab with about 75 options/settings. A user is able to basically have different "copies" of these settings (think: dropdown that when you select it, all 75 options are set to whatever was in that associated .xml file).
Right now I just store settings using XML. The problem is that when my application needs to ACCESS a setting, it is literally accessing the UI directly (checkboxes, etc...)
My question: Should I basically created a "has changed" event for every control, and then update the appropriate setting structure (and only save when the user hits save)?
I'm worried that I shouldn't be accessing the UI directly, and it's doing that today ALL over the app. I want to be sure that my new solution is appropriate/how C# was designed.
Thanks in advance!
~ Josh
It sounds like you want to have a class that represents a configuration. Serializing to/from XML allows you to store it in a file or database.
A static singleton can provide the application with the currently active configuration's values. The application should not be checking the UI elements on a non-visible form to get the settings each time one is needed.
Designing the settings form so that it handles a instance of a configuration allows it to be used to display/update the active configuration or a saved configuration. It ought to simplify letting a user load a configuration, modify it, and save it as a new configuration.
And 75 is, as a rule, a lot of settings for a single tab to manage.
Related
When should I really call the Reload method of the Properties.Settings.Default? Every time when I want to access properties from the persistent storage? Is it really necessary?
Thanks in advance.
The documentation for ApplicationSettingsBase.Reload states:
Refreshes the application settings property values from persistent storage.
So yes, you should call it whenever you want to access properties from the persistent storage. What you didn't ask was:
Do I need to load settings from persistent storage every time I want the value?
The answer to that is no. The value will be cached in the application settings object, so you do not need to reload if you just want the cached value.
The real answer for me is I can't think of a reason to call it at all. I'll tell you why:
There are two types of settings. User settings and application settings. The user settings are changed on a per-user basis and most probably through a UI that belongs to your application itself. If you change the settings within your application, it already knows they have been changed - reload unnecessary.
The application settings should not change after the application has been installed. How should they? Only admins have access to the program files folders at all.
Applications that run outside user space (services) have no GUI and there's no good reason to use user settings for services. Normally you'll change the config file and then restart the service.
The settings are loaded once when the application is started. Should you re-read them every time before you access a setting? No - for the reasons I gave above.
Here is an example of when to use Reload() method:
I have built an editor for those property settings. It is a propertygrid control with a few buttons on a dialog form.
When the user clicks to invoke that editor then key/values from Properties.Settings.Default are shown in the propertygrid.
Now, users can change many properties but if they decide NOT to save those changes, settings have to be reloaded because they are now invalid!
And that is when I use:
((ApplicationSettingsBase)propertyGrid.SelectedObject).Reload();
I want to save state of lot of CheckBoxes (checked/unchecked) and some TextBoxes on a WPF screen in .settings file (As I do not want to use database/filing).
Whether I have to save all these checkboxes and textboxes in setings file or there is a better way to do it?
If this is to remember the state of controls in an application, I would definitely use user settings to store this. Creating a separate setting for each control can be time consuming initially, but it makes life a little easier later. However, if you don't want to do this, you can simply create a custom settings class with a public property for each control and then simply use an instance of that class as your one savable setting.
I have some global settings in my application that is going to be handled by the administrator and I store them in the database.
Settings like: board on/off, max items/page on different UserControls, language, hide/show modules.
What technique should I follow to read the values in the database and display the page or the application according to it .. Of course I could do it the easy way and fetch the required settings for each page in the Page_Load event handler but I think that will be a lot of database connection!
Is there is any better way to achieve this?
You probably want to load your settings into the Application state on Application_Start in your global.asax.
I am working in C#. I find myself creating dialogs for editing my application settings all the time. For every Control on the dialog I am reading the configuration file and set it accordingly. After pressing OK, I am reading all the controls and store the values in the configuration files or something similar again.
This seems to be very time consuming, simple and repetitive. Does anybody have an idea how to simplify this process? Code generation? Helper classes?
You can bind WinForms controls directly to application settings, which should make your life a lot easier for creating dialogs to manage them.
Just select a control and look for the (Application Settings) option under the Data group in the properties pane. I put up a screenshot here to illustrate.
Do these application settings dialogs need to be pretty or are they simply there for personal configuration? If it's the latter, read all the settings into a class and assign that class to a property editor.
Not recommended for a good-looking, final UI though.
Best bet would be to use the "Settings" that are included in the default template for a winforms rather than "configuration" it is easier and the settings can be bound to just about any property for a control or read independently. Once discovered they are well documented, easy to customise and easy to use.
If you need to use configuration then I'd look at using a custom configuration section and bind that to a property grid or control set for editing. The configuration makes it easy to read and write changes to the configuration.
My coworkers and I cannot seem to agree on a solution to the following issue:
We are working on moving our application to the .net framework. It will be a standalone application (not a web application) that will consist of many custom forms used for making changes to our extensive database. So, in summary, without a database connection, the application is pretty much useless. Oh--and there's no need to suggest making this a web application because there is really no choice in the matter.
I am responsible for building the "main menu"--I've decided on a tree structure that will list all the custom forms (categorized by team). It will also include a "My Forms" section and a "Recent Forms" section that will be changed by the user (my forms) and the system (recent forms) on a regular basis.
My question is this: what is the best place for storing these custom user-specific-settings? An XML file located locally or in tables located database? Maybe it's because I'm a former web app developer but I'm totally for having this stored on the database. What do y'all think?
Thanks for your opinions
If the user can function without the database they should be a local xml file. If the app requires the database to be functional, I'd add them to the database. Why add some new concept to the app, just keep storage of data in a single place. Your app will be able to run with lower privileges as well. If you're using the asp.net membership model (yes, for the desktop app) then you'll be able to take advantage of the profiling.
I vote database!
Another advantage of keeping them in the database is that when the user logs in to your application from another computer, all of their settings will be preserved. If they are stored on the local machine, moving to another machine would cause them to lose their settings.
It can be troublesome to mix user settings and user data in the same storage location.
This approach will basically double the number of times the database structure has to change.
If there is a bug in the settings code, there is a chance to corrupt/lose user data which is much more serious than corrupting/losing a user setting.
If the user wants to move or back up their data, the settings are also carried with it.
I would advise against keeping the settings in the database.