Looking for a Tools-Options dialog example

  • Thread starter Thread starter Bradford
  • Start date Start date
B

Bradford

Hi,

I am developing a Windows application in C# and I'd like the user be able to view or adjust some application settings which will be 'remembered' the next time the application starts. I'd like to have a dialog that looks and works like typical MSOffice dialogs you see when opening the Tools menu > Options.

I prefer to create only an executable file that can be run without installing, so I think writing to the registry is overkill. I looked into using .config files, but it sounds like the values they store are read-only to the application user (i.e. the values must be changed by the programmer in xml format).

Can anyone point me in the right direction?
 
Bradford,

the easiest way to let the user change some settings is using the
propertygrid control. (theres sample code for that control
up on msdn).

i'm not sure what you think is special about the office options
dialog... its just a simple dialog with tabs. you can do the
same using a windows.forms.form and a tab control on that
form.

the framework doesn't actually provide any means for storing
settings 'as such'. the easiest way is to simply use the binary or
the soap formatter to simply serialize your settings object to
a file in the users data directory. information about the location
of that directory is a property of the Application class.

WM_HOPETHISHELPS
thomas woelfer
http://www.die.de/blog



Hi,

I am developing a Windows application in C# and I'd like the user be able to view or adjust some application settings which will be
'remembered' the next time the application starts. I'd like to have a dialog that looks and works like typical MSOffice dialogs you
see when opening the Tools menu > Options.

I prefer to create only an executable file that can be run without installing, so I think writing to the registry is overkill. I
looked into using .config files, but it sounds like the values they store are read-only to the application user (i.e. the values
must be changed by the programmer in xml format).

Can anyone point me in the right direction?
 
Thomas,
The more I think about it, I realize that a stand-alone .exe file couldn't
store settings changes in itself. It sounds like serializing the settings
and saving them to a file is the way to go.
Thanks very much for the advice.
Bradford
 
Actually, using Reflection.Emit, the application could almost store the
settings in itself. You could store the settings directly in executable
format, anyway. It would be a lot more work than the other solutions
proposed on this thread, it wouldn't be a "standard" solution, and I
wouldn't really recommend doing it this way, but if you really wanted to you
could keep the settings in a DLL:

1. The DLL could contain a single "settings" class to hold the settings,
with a methods for returning the individual values.
2. At app load time, you load the DLL create a new instance of the settings
class, and read the values from it.
3. When the user changes the settings, you dynamically re-generate the code
for the settings class, and using the Reflection.Emit class you compile it
on the fly and save the result back to your DLL.

I haven't played with this stuff in a long time, but I think you may have
some issues around being able to write to the DLL while the application is
loaded; at application load time, you may have to load the DLL in a separate
app domain, and then unload that whole domain before attempting to re-write
and re-load the DLL.

At any rate, I would suggest that you use one of the more standard methods.
Chris Sells' book "Windows Forms Programming in C#" contains an excellent
discussion of the various kinds of storage available for application
settings (everything from .config files to the registry to Isolated
storage). If you're still unclear about the tradeoffs with different types
of settings mechanisms, I would highly recommend reading that part of Chris'
book.

Isolated Storage is a particularly attractive option, because it combines
most of the benefits of the other options in a way that doesn't lock you in
to any particular implementation. Future versions of .NET are free to
change the way that Isolated Storage is implemented without breaking your
code (I would expect, actually, to see a new implementation as soon as the
WinFS file system is released, that takes advantage of new WinFS features.
But I don't work on the .NET framework team, so don't quote me on that.)

--
 
Back
Top