Application settings do not save

  • Thread starter Thread starter DoB
  • Start date Start date
D

DoB

Hi,

I am using the application settings bound to windows forms controls (edit
and check boxes). My intuition was that the changes to the values of the
controls will be persistent, e.g. when I change the text in an edit box and
close the form (the main form of the application) then the change will be
reflected in the settings file and used on the next run.

But it is not working this way: the changes are lost. What am I doing wrong?

Regards,
DoB
 
DoB said:
Hi,

I am using the application settings bound to windows forms controls (edit
and check boxes). My intuition was that the changes to the values of the
controls will be persistent, e.g. when I change the text in an edit box
and close the form (the main form of the application) then the change will
be reflected in the settings file and used on the next run.

But it is not working this way: the changes are lost. What am I doing
wrong?

Regards,
DoB
I use VS 2008 Professional Edition on a daily basis for several different
project types, and for Windows Forms, VS behaves for me as you believe it
should. Given all the different project types available in VS, my experience
means nothing if you are using different templates.
So, lets start with the basics. What version and edition of Visual Studio
are you using, and which project type(s) fail to save property settings in
what kind(s) of control(s)?
 
So, lets start with the basics. What version and edition of Visual Studio
are you using, and which project type(s) fail to save property settings in
what kind(s) of control(s)?

VS 2005 Professional, windows forms application, the controls are text boxes
and checkboxes bound to application settings of type String and bool.

DoB
 
Hi,
Do you ever call the Save() method on your Settings object? If not, then
I'd say that's it. :)

That was also my wild guess, but adding such a line:
Properties.Settings.Default.Save();
on FormClosing event did not help. The settings are not saved :-/.

DoB
 
Are you sure the FormClosing event is being raised? Depending on how your
application is shutdown, it might not be.

Hmmmm... I checked with the debugger. It IS raised and the Save() IS
executed :-|.
BTW: what other entry point do you suggest for calling Save()?

If you are sure that the call to Save() is being executed, then absent a
concise-but-complete code sample, I think the odds of someone providing
the answer are low.

The problem is that there is almost no code to be shown.

I was binding the controls to the application settings using this tutorial:
http://msdn.microsoft.com/en-us/library/0yyxh69h(VS.80).aspx
The only code I actually wrote myself was the call to Settings.Save().

DoB.
 
OK... it started working when
(1) I changed all "application settings" to "user settings",
(2) I added the code that assigns the values of controls to the settings
properties before the code executing Save()

Frankly speaking, I thought that (2) is done automatically ;-).

DoB
 
For (1), it really should not affect things being saved, but you need to
think whether the settings are really machine or user dependent.
For (2), it depends on how the data bindings were set up, I believe.
 
OK... it started working when
For (1), it really should not affect things being saved, but you need to
think whether the settings are really machine or user dependent.

When the setting is an "Application setting" then the generated member
property is read-only, thus the "(2)" code does not compile.

For (2), it depends on how the data bindings were set up, I believe.

I set it up this way:
http://msdn.microsoft.com/en-us/library/0yyxh69h(VS.80).aspx


The another question is... where does the application save the settings?
I thought it is done in the <appname>.settings file, but when I copied the
executable to a new location, executed it and changed the settings, the
config file was not created in the new directory. On the other hand, the
settings were saved somewhere, because they were preserved between the
application runs.

Regards,
DoB
 
Back
Top