Application Settings: Don't get it!

[Hector Santos]

I am trying to use the library to set/get settings. Something that
normally isn't a hard concept when you using your own logic, but I'm
still learning the rich library and wish to use whats there.

But I don't get it. Following all examples, it doesn't seem to take.

To test, I created a Windows form with 3 check boxes and using the
Data Binding to set three corresponding settings:

option1
option2 default checked
option3

How do use this in code so that user changes stick on saving and loading?

Maybe I am seeing this wrong. Its only for the default settings?

I don't wish to hand code the load/saving for each control/option,
isn't that defeating the purpose of the "Data/Property Binding" using
its inherent enumeration interface?

Thanks

 

[Jackie]

I am trying to use the library to set/get settings. Something that
normally isn't a hard concept when you using your own logic, but I'm
still learning the rich library and wish to use whats there.

But I don't get it. Following all examples, it doesn't seem to take.

To test, I created a Windows form with 3 check boxes and using the Data
Binding to set three corresponding settings:

option1
option2 default checked
option3

How do use this in code so that user changes stick on saving and loading?

Maybe I am seeing this wrong. Its only for the default settings?

I don't wish to hand code the load/saving for each control/option, isn't
that defeating the purpose of the "Data/Property Binding" using its
inherent enumeration interface?

Thanks

Wouldn't it be better to use ApplicationSettings instead for that purpose?

 

[Peter Duniho]

I am trying to use the library to set/get settings. Something that
normally isn't a hard concept when you using your own logic, but I'm
still learning the rich library and wish to use whats there.

But I don't get it. Following all examples, it doesn't seem to take.

To test, I created a Windows form with 3 check boxes and using the Data
Binding to set three corresponding settings:

option1
option2 default checked
option3

How do use this in code so that user changes stick on saving and loading?

Maybe I am seeing this wrong. Its only for the default settings?

Without you posting actual code, it's not possible to know for sure what
help you need.

However, if you are talking about the Designer-provided "Settings"
class, which you retrieve from the "Default" property in the class, you
have to call the Save() method after changing any of the values.

If that's not what you're talking about, then you need to be less vague.
Post actual code, a concise-but-complete code example that reliably
demonstrates the problem.

Pete

 

[Hector Santos]

Wouldn't it be better to use ApplicationSettings instead for that purpose?

I would think so but it doesn't to take (stick) or I am missing something.

To test/explore the concept, I created a simple C# Windows Form
applications with five checkboxes and in via the Property Editor I
data bound them to

Option1 user setting, default false
Option2 user setting, default true
Option3 user setting, default false
Option4 app setting, default true
Option5 app setting, default false

Checking the project properties setting, matches the result.

I also added a "Save" button on the form.

in Program.cs, I have:

using System.Diagnostics;
using System.Text;
using System.Collections;
using System.Configuration;
using System.Windows.Forms;

namespace TextMFCApplicationSettings
{
public partial class Form1 : Form
{
Configuration config =
ConfigurationManager.OpenExeConfiguration(
ConfigurationUserLevel.None);
Properties.Settings settings = new Properties.Settings();

public void log(string fmt, params object[] v)
{
Debug.WriteLine(String.Format(fmt,v));
}

public Form1()
{
InitializeComponent();
log("== AFTER InitializeComponent() ===");
log("Option1={0}", settings.Option1);
log("Option2={0}", settings.Option2);
log("Option3={0}", settings.Option3);
log("Option4={0}", settings.Option4);
log("Option5={0}", settings.Option5);

}
private void btnSaveSettings_Click(object sender, EventArgs e)
{

config.Save(ConfigurationSaveMode.Modified);
//setting.Save(); // tried this too

log("== AFTER Save() ===");
log("Option1={0}", settings.Option1);
log("Option2={0}", settings.Option2);
log("Option3={0}", settings.Option3);
log("Option4={0}", settings.Option4);
log("Option5={0}", settings.Option5);
}
}
}

I just to get the purpose of ApplicationSettings if you have to it
programmatically, which is no sweat, I can write a class to handle it
all very nicely, but if the .NET libraries can handle it, I want to at
least see how it works. All the docs, show how to make properties,
but is very short on the subject of loading and saving and making it
stick.

Note, I even did this, before the save() calls:

//ConfigurationManager.AppSettings["Option1"] =
checkBox1.Checked.ToString();
//ConfigurationManager.AppSettings["Option2"] =
checkBox2.Checked.ToString();
//ConfigurationManager.AppSettings["Option3"] =
checkBox3.Checked.ToString();
//ConfigurationManager.AppSettings["Option4"] =
checkBox4.Checked.ToString();
//ConfigurationManager.AppSettings["Option5"] =
checkBox5.Checked.ToString();

settings.Option1 = checkBox1.Checked;
settings.Option2 = checkBox2.Checked;
settings.Option3 = checkBox3.Checked;
//settings.Option4 = checkBox4.Checked; // not allowed
//settings.Option5 = checkBox5.Checked; // not allowed

to see if it the default can be saved, but that didn't work either.

I am definitely missing something. Whats the "Ah ha" here?

 

[Hector Santos]

Without you posting actual code, it's not possible to know for sure what
help you need.

However, if you are talking about the Designer-provided "Settings"
class, which you retrieve from the "Default" property in the class, you
have to call the Save() method after changing any of the values.

If that's not what you're talking about, then you need to be less vague.
Post actual code, a concise-but-complete code example that reliably
demonstrates the problem.

Pete

Right, See 2nd post.

I under the designer and default concept. I create UI components with
properties to make this work - to see DEFAULTS.

But I never wait further with real production effort to deal with
saving/reloading of stored properties. I was mostly "learning" the
object layout of the language.

I don't get how run time property change values are saved and reloaded
over the defaults.

The docs seem to suggest that you have to duplicate the coding, but
that doesn't seem right. But all I see are examples where you do have
to .Remove(), .Add() these property settings in code - thats redundant
to me because it means I can create a enumerator to do this, which
is also redundant.

So I am still missing something here.

Thanks

 

[Hector Santos]

I haven't coded this, but it seems to me you have to do:

On Loading:

Read section "CustomSettings", if any, otherwise use default.

On Saving:

Emumerate each key in Application Setting and get value from
form and Section under "CustomSettings"

But these all seem redundant.

Wouldn't it be better to use ApplicationSettings instead for that
purpose?

I would think so but it doesn't to take (stick) or I am missing something.

To test/explore the concept, I created a simple C# Windows Form
applications with five checkboxes and in via the Property Editor I data
bound them to

Option1 user setting, default false
Option2 user setting, default true
Option3 user setting, default false
Option4 app setting, default true
Option5 app setting, default false

Checking the project properties setting, matches the result.

I also added a "Save" button on the form.

in Program.cs, I have:

using System.Diagnostics;
using System.Text;
using System.Collections;
using System.Configuration;
using System.Windows.Forms;

namespace TextMFCApplicationSettings
{
public partial class Form1 : Form
{
Configuration config =
ConfigurationManager.OpenExeConfiguration(
ConfigurationUserLevel.None);
Properties.Settings settings = new Properties.Settings();

public void log(string fmt, params object[] v)
{
Debug.WriteLine(String.Format(fmt,v));
}

public Form1()
{
InitializeComponent();
log("== AFTER InitializeComponent() ===");
log("Option1={0}", settings.Option1);
log("Option2={0}", settings.Option2);
log("Option3={0}", settings.Option3);
log("Option4={0}", settings.Option4);
log("Option5={0}", settings.Option5);

}
private void btnSaveSettings_Click(object sender, EventArgs e)
{

config.Save(ConfigurationSaveMode.Modified);
//setting.Save(); // tried this too

log("== AFTER Save() ===");
log("Option1={0}", settings.Option1);
log("Option2={0}", settings.Option2);
log("Option3={0}", settings.Option3);
log("Option4={0}", settings.Option4);
log("Option5={0}", settings.Option5);
}
}
}

I just to get the purpose of ApplicationSettings if you have to it
programmatically, which is no sweat, I can write a class to handle it
all very nicely, but if the .NET libraries can handle it, I want to at
least see how it works. All the docs, show how to make properties, but
is very short on the subject of loading and saving and making it stick.

Note, I even did this, before the save() calls:

//ConfigurationManager.AppSettings["Option1"] =
checkBox1.Checked.ToString();
//ConfigurationManager.AppSettings["Option2"] =
checkBox2.Checked.ToString();
//ConfigurationManager.AppSettings["Option3"] =
checkBox3.Checked.ToString();
//ConfigurationManager.AppSettings["Option4"] =
checkBox4.Checked.ToString();
//ConfigurationManager.AppSettings["Option5"] =
checkBox5.Checked.ToString();

settings.Option1 = checkBox1.Checked;
settings.Option2 = checkBox2.Checked;
settings.Option3 = checkBox3.Checked;
//settings.Option4 = checkBox4.Checked; // not allowed
//settings.Option5 = checkBox5.Checked; // not allowed

to see if it the default can be saved, but that didn't work either.

I am definitely missing something. Whats the "Ah ha" here?

 

[Peter Duniho]

[...]
namespace TextMFCApplicationSettings
{
public partial class Form1 : Form
{
Configuration config =
ConfigurationManager.OpenExeConfiguration(
ConfigurationUserLevel.None);

You should not need the above statement.

Properties.Settings settings = new Properties.Settings();

Here, you should be using Properties.Settings.Default, not creating a
new instance.

[...]
private void btnSaveSettings_Click(object sender, EventArgs e)
{

config.Save(ConfigurationSaveMode.Modified);
//setting.Save(); // tried this too

Here, you should be calling Properties.Settings.Default.Save().

Note that whether you call Save() or not, the property values in your
Settings object will in fact be updated. But they are not persisted to
the disk unless and until you call Save(). If you do call Save(), they
they are stored on the disk, and the next time the application runs, the
updated values will be there.

Note also that when running your program from the IDE, unless you've
disabled it the Visual Studio debugger will actually run your program
within a *.vshost.exe program. Since the configuration file location
depends on the .exe name, this means that settings stored while running
with the debugger only are seen when running with the debugger, and
settings stored when running the program without the debugger are seen
only when running the program without the debugger.

IMHO, the "Default" property of Properties.Settings is poorly named,
because it seems to imply that it retrieves only the default values for
your application settings. Instead, it is the default _instance_ of
your Properties.Settings, and is the one you should always be using.

Pete

 

[Hector Santos]

Thanks Pete, I believe I tried your suggestion, but don't recall
because I had too many things on my mind of what to try.

So I need to read more your response and couple it with other
readings, but let me ask you this:

Do I need to follow this:

http://msdn.microsoft.com/en-us/library/ms973902.aspx

Or am I reading too much into it, and its more simple?

Again, the 'objects' are already defined somewhere, in this case the
form., and the goal is not to duplicate each item in code. The idea is
that when I need to add a new setting, I simply add it to the form,
bind it and thats it. No need to add a specific Read/Save for each item.

They are bounded via the Property editor and have Properties in the
designer code with attributes. I understand the default attribute is
for the Property Editor.

If I use a cloned 2nd section under a different section name
"CustomSettings" and I could use the applicationSettings as a "Reset"
concept to read the default design values.

But in lieu of that "reset" offering, using the applicationSettings
section only, I don't see to see how to save this at run time.

Yes, I disabled the vshost and also ran it from disk, monitoring the
applet.exe.config to see if it changed or not. The only way I can get
it to save or take action is when I use the ForceALL save parameter,
which writes "all sections" to disk.

Anyway, let my try your suggestions.

[...]
namespace TextMFCApplicationSettings
{
public partial class Form1 : Form
{
Configuration config =
ConfigurationManager.OpenExeConfiguration(
ConfigurationUserLevel.None);

You should not need the above statement.

Properties.Settings settings = new Properties.Settings();

Here, you should be using Properties.Settings.Default, not creating a
new instance.

[...]
private void btnSaveSettings_Click(object sender, EventArgs e)
{

config.Save(ConfigurationSaveMode.Modified);
//setting.Save(); // tried this too

Here, you should be calling Properties.Settings.Default.Save().

Note that whether you call Save() or not, the property values in your
Settings object will in fact be updated. But they are not persisted to
the disk unless and until you call Save(). If you do call Save(), they
they are stored on the disk, and the next time the application runs, the
updated values will be there.

Note also that when running your program from the IDE, unless you've
disabled it the Visual Studio debugger will actually run your program
within a *.vshost.exe program. Since the configuration file location
depends on the .exe name, this means that settings stored while running
with the debugger only are seen when running with the debugger, and
settings stored when running the program without the debugger are seen
only when running the program without the debugger.

IMHO, the "Default" property of Properties.Settings is poorly named,
because it seems to imply that it retrieves only the default values for
your application settings. Instead, it is the default _instance_ of
your Properties.Settings, and is the one you should always be using.

Pete

 

[Hector Santos]

Ok using

Properties.Settings.Default.Save()

Seem to work but its not using the applet.exe.config. It must be
using a user.config setting under the user's document folder.

I have to thing about this, but I need it to save the to the
applet.exe.config files.

Is this where to to basically use a customSettings section if I want
it to go to the exe.config as opposed to the user.config?

--

Thanks Pete, I believe I tried your suggestion, but don't recall because
I had too many things on my mind of what to try.

So I need to read more your response and couple it with other readings,
but let me ask you this:

Do I need to follow this:

http://msdn.microsoft.com/en-us/library/ms973902.aspx

Or am I reading too much into it, and its more simple?

Again, the 'objects' are already defined somewhere, in this case the
form., and the goal is not to duplicate each item in code. The idea is
that when I need to add a new setting, I simply add it to the form, bind
it and thats it. No need to add a specific Read/Save for each item.

They are bounded via the Property editor and have Properties in the
designer code with attributes. I understand the default attribute is for
the Property Editor.

If I use a cloned 2nd section under a different section name
"CustomSettings" and I could use the applicationSettings as a "Reset"
concept to read the default design values.

But in lieu of that "reset" offering, using the applicationSettings
section only, I don't see to see how to save this at run time.

Yes, I disabled the vshost and also ran it from disk, monitoring the
applet.exe.config to see if it changed or not. The only way I can get
it to save or take action is when I use the ForceALL save parameter,
which writes "all sections" to disk.

Anyway, let my try your suggestions.

[...]
namespace TextMFCApplicationSettings
{
public partial class Form1 : Form
{
Configuration config =
ConfigurationManager.OpenExeConfiguration(
ConfigurationUserLevel.None);

You should not need the above statement.

Properties.Settings settings = new Properties.Settings();

Here, you should be using Properties.Settings.Default, not creating a
new instance.

[...]
private void btnSaveSettings_Click(object sender, EventArgs e)
{

config.Save(ConfigurationSaveMode.Modified);
//setting.Save(); // tried this too

Here, you should be calling Properties.Settings.Default.Save().

Note that whether you call Save() or not, the property values in your
Settings object will in fact be updated. But they are not persisted
to the disk unless and until you call Save(). If you do call Save(),
they they are stored on the disk, and the next time the application
runs, the updated values will be there.

Note also that when running your program from the IDE, unless you've
disabled it the Visual Studio debugger will actually run your program
within a *.vshost.exe program. Since the configuration file location
depends on the .exe name, this means that settings stored while
running with the debugger only are seen when running with the
debugger, and settings stored when running the program without the
debugger are seen only when running the program without the debugger.

IMHO, the "Default" property of Properties.Settings is poorly named,
because it seems to imply that it retrieves only the default values
for your application settings. Instead, it is the default _instance_
of your Properties.Settings, and is the one you should always be using.

Pete

 

[Hector Santos]

I think I "get it" now:

App Settings is for the exe.config file
User Settings is for the user's desktop location user.config file.

Properties.Settings.Default.Save() is for the user.config file only.

It will not save properties bound to the application settings.

Thats what I am figuring out now.

--

 

[Hector Santos]

I think I have a basic handle of this. A confirmation or enlightenment
would be appreciated.

Saving properties to the "user.config" - self-trusted concept is
allowed, but saving to the application.exe.config requires another
level of "trust" work. I am successful in saving properties to the
user's user.config file which is probably ok, but I need understanding
and more program control options for scenarios where I want
application level options save to the application.exe.config file.

How do you save to the application.exe.config file?

 

[Peter Duniho]

Ok using

Properties.Settings.Default.Save()

Seem to work but its not using the applet.exe.config. It must be using
a user.config setting under the user's document folder.

I have to thing about this, but I need it to save the to the
applet.exe.config files.

There's no "applet.exe.config". I assume you're talking about the
app.config file, which contains application-level settings, rather than
user-level settings.

Using the Designer-provided class, the application-level settings are
read-only. You can edit them in the Designer, but at run-time they
cannot be saved.

This is, by the way, at least in part in order to encourage people to
write better programs. It is a bad idea to maintain application-level
settings that can be modified by individual users, at least through the
main application.

If you want for users to be able to modify application-level settings
(i.e. settings that will apply to every user using the program), you
should provide a separate program that allows for the modification of
the first program's application-level settings, or at least provide a
very clear UI completely separated from the main UI in the original program.

And yes, to modify the application-level settings in the app.config file
you'll have to use the ConfigurationManager support directly, rather
than through the Designer-provided class. It will be somewhat more
involved than dealing with the user-level settings, and this is to at
least some extent an intentional design.

Pete

 

[Hector Santos]

This is, by the way, at least in part in order to encourage people to
write better programs. It is a bad idea to maintain application-level
settings that can be modified by individual users, at least through the
main application.

If it can't be controlled, its a bad theory. Another school of
thought is to lower support cost to deal with issues where "options"
are buried somewhere *most* don't know how/where to find it. So 6 in
1, 1/2 dozen... In our products, we prefer full control and
consolidation if all possible.

Thanks for your opinion though on that.

If you want for users to be able to modify application-level settings
(i.e. settings that will apply to every user using the program), you
should provide a separate program that allows for the modification of
the first program's application-level settings, or at least provide a
very clear UI completely separated from the main UI in the original
program.

Opinion on design here doesn't apply, is not being sort Pete. Not to
say you are right or wrong either way. Its just an design approach and
it really all depends on the application and/or framework.

And yes, to modify the application-level settings in the app.config file
you'll have to use the ConfigurationManager support directly, rather
than through the Designer-provided class. It will be somewhat more
involved than dealing with the user-level settings, and this is to at
least some extent an intentional design.

I can see the clear distinction now. I have to note that in my
experience with more and more .NET application, they often require
direct *applet*.exe.config editing for one thing or another.

I guess since the infrastructure does allow for separation, it can be
utilized more. But it will depend on the *applet* <g>. In our case,
server oriented applications need more concentration, while end user
or one where different profiles may exist, a user.config may apply.

Now that I understand it better, I will be writing a class that will
make it easier for implement exe.config usage.

I can see where .NET strong cross-network trust issues plays can play
a role. Thats probably a strong incentive to use local "Applet"
settings via user settings. I guess its similar to separating a local
versus remote registry or both design.

I guess the point is, at least for us, we need both. Using the
Properties.Settings.Default was WAY too easy (thanks for the pointer
there) but it can promote a bad design in itself when a design may
ultimately call for a separation.

The IDE does allow you do this separation easily and the .net classes
do separate and protect the Application properties setting, so its
just a matter now of have an enhanced class, so you can do:

Properties.Settings.AllSettings.Save(SecurityOptions);

and it will do both savings.

Thanks for your input.