Something wrong with the code

[David McCallum]

The object of the code snippet below is to save and restore a form's size
and location. The saveFormSettings() method is called when a form is closing
and restoreFormSettings() is called after InitializeComponent().

The problem is even though the settings appear to be being saved, the
strWidth variable is always null, so the settings are never restore.

Any clues as to what I'm doing wrong?

TIA

David McCallum

private static NameValueCollection appSettings =
ConfigurationManager.AppSettings;

/// <summary>
/// Restore a form's settings
/// </summary>
/// <param name="form">The form to restore</param>
public static void restoreFormSettings(Form form)
{
string strWidth = appSettings.Get(form.Name + "FormWidth");
if (strWidth != null)
{
string strHeight = appSettings.Get(form.Name + "FormHeight");
string strX = appSettings.Get(form.Name + "FormX");
string strY = appSettings.Get(form.Name + "FormY");
form.Size = new Size(Int32.Parse(strWidth), Int32.Parse(strHeight));
form.Location = new Point(Int32.Parse(strX), Int32.Parse(strY));
}
}

/// <summary>
/// Save a form's settings
/// </summary>
/// <param name="form">The form to save</param>
public static void saveFormSettings(Form form)
{
appSettings.Set(form.Name + "FormWidth", form.Size.Width.ToString());
appSettings.Set(form.Name + "FormHeight", form.Size.Height.ToString());
appSettings.Set(form.Name + "FormY", form.Location.Y.ToString());
appSettings.Set(form.Name + "FormX", form.Location.X.ToString());
}

 

[Kevin Spencer]

There is a much easier way to do this using Visual Studio. You can create
Application Settings and bind your Form properties to them. See the
following articles:

http://msdn2.microsoft.com/en-us/library/k4s6c3a0.aspx
http://msdn2.microsoft.com/en-us/library/0yyxh69h(VS.80).aspx

--
HTH,

Kevin Spencer
Microsoft MVP

Printing Components, Email Components,
FTP Client Classes, Enhanced Data Controls, much more.
DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net

 

[David McCallum]

There is a much easier way to do this using Visual Studio. You can create
Application Settings and bind your Form properties to them. See the
following articles:

http://msdn2.microsoft.com/en-us/library/k4s6c3a0.aspx
http://msdn2.microsoft.com/en-us/library/0yyxh69h(VS.80).aspx

I had a look at this, but as I understand application wide settings are
readonly, or am I mistaking.

Also forms will be created on the fly. How do I create settings, e.g. name1,
name2, name3......

TIA

David.

 

[Peter Duniho]

I had a look at this, but as I understand application wide settings are
readonly, or am I mistaking.

Define "application wide". It's true that settings in the "Application"
domain are read-only. However, for the example you've given here, it
appears that the settings would more appropriately belong in the "User"
domain. Why should window position saved for one user affect the window
position for a different user? "User" domain settings are read/write and
very convenient to use.

Also forms will be created on the fly. How do I create settings, e.g.
name1, name2, name3......

Well, I can assure you that you could get it to work with the .NET
Settings architecture. So that's more than I can say for the method
you're using now.

I admit, I don't know much about the ConfigurationManager.AppSettings
class, but as near as I can tell the AppSettings class offers only
read-only access to settings as well. From
http://msdn2.microsoft.com/en-us/library/system.configuration.configurationmanager.aspx:

"For some sections such as appSettings and connectionStrings,
use the AppSettings and ConnectionStrings classes. These members
perform read-only operations..."

I don't know how you have determined that "the settings appear to be being
saved", but the above quote suggests to me that they aren't in fact
saved. Which would explain why they always come back null.

It seems to me that you can either use the ConfigurationManager on a
custom "Configuration" object, which the docs say that you can use for
read/write access to settings, or you can update your technique and use
the regular Properties.Settings.Default that is provided for in .NET.

Back to the specific question about saving settings based on the specific
form name...

I'm not really clear on why you want to do this, assuming your forms'
names are set at design time. Even if the user can change the name of the
form at run-time, in most situations you would still have a consistent
internal variable name associated with each form that you could use to tie
specific settings to a specific form.

But let's assume that you've got one of those rare applications where the
user can create their own forms at run-time. Let's also assume that the
form name is a unique identifier useful for tying specific settings to a
specific form. Then one possibility is to create a Dictionary<> instance
that ties the form name to a struct containing the form position (for
example, a Rectangle) and store that in your settings.

Of course, you may find it easier at this point to continue using the
ConfigurationManager class. If so, I can't help much with that, since I
haven't used it myself. But you should definitely explore the possibility
that you're using it wrong and that it won't save the settings you assign
in the AppSettings class.

Pete

 

[David McCallum]

Define "application wide". It's true that settings in the "Application"

domain are read-only. However, for the example you've given here, it
appears that the settings would more appropriately belong in the "User"
domain. Why should window position saved for one user affect the window
position for a different user? "User" domain settings are read/write and
very convenient to use.

Granted in this case they would be user dependant, but I also have a setting
of data locations which will be set by the user. This will be the same for
each user.

I don't know how you have determined that "the settings appear to be being
saved", but the above quote suggests to me that they aren't in fact
saved. Which would explain why they always come back null.

What I meant was the method is executed.

David.

 

[Kevin Spencer]

These would be user-scoped, which means that they are read-write, and
specific to each logged-in user.

--
HTH,

Kevin Spencer
Microsoft MVP

Printing Components, Email Components,
FTP Client Classes, Enhanced Data Controls, much more.
DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net