Prev: Convert and ConvertBack Methods
Next: Transparent form with hourglass?
From: Hector Santos on 30 May 2010 00:46
Peter Duniho wrote:

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

--
HLS
 | 
Pages: 1
Prev: Convert and ConvertBack Methods
Next: Transparent form with hourglass?