[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework

Application settings do not save

DoB

10/21/2008 3:12:00 PM

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


10 Answers

PvdG42

10/21/2008 4:08:00 PM

0


"DoB" <DoB@dob.com> wrote in message
news:u6nNU94MJHA.260@TK2MSFTNGP05.phx.gbl...
> 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)?

Peter Duniho

10/21/2008 5:41:00 PM

0

On Tue, 21 Oct 2008 08:11:42 -0700, DoB <DoB@dob.com> wrote:

> 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?

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

Pete

DoB

10/22/2008

0

> 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


DoB

10/22/2008 12:03:00 AM

0

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


Peter Duniho

10/22/2008 12:11:00 AM

0

On Tue, 21 Oct 2008 17:02:43 -0700, DoB <DoB@dob.com> wrote:

> 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 :-/.

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

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.

Pete

DoB

10/22/2008 9:30:00 AM

0

> 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/librar...(VS.80).aspx
The only code I actually wrote myself was the call to Settings.Save().

DoB.


DoB

10/22/2008 10:05:00 AM

0

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


Family Tree Mike

10/22/2008 11:32:00 AM

0

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.


"DoB" <DoB@dob.com> wrote in message
news:Onmfe2CNJHA.5696@TK2MSFTNGP03.phx.gbl...
> 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
>

DoB

10/22/2008 3:51:00 PM

0

>> 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 ;-).


> 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/librar...(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


Peter Duniho

10/22/2008 6:08:00 PM

0

On Wed, 22 Oct 2008 08:50:53 -0700, DoB <DoB@dob.com> wrote:

> [...]
> 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.

The settings are stored in the user's "Documents and Settings" store,
under the "Local Settings\Application Data" path. Each application will
have its own sub-directory there, containing individual folders for each
version of the application's user settings.

And yes, as you have found, only the user-level settings can be saved.
The application-level settings are read-only.

Binding the property as you did should have updated the settings, assuming
you were binding to a writeable setting of course. I've done just that
myself in the past and it works fine.

As far as posting code goes, it's not true that there's no code to post.
All of this is done in code. It is true that if you use the Designer to
set things up, then the bulk of the code will be found in the
*.Designer.cs file(s) for your program. But the code is in fact there.

Pete