3

Following CodeProject and StackOverflow.105932 (and a few others, e.g., StackOverflow.1873658 and MSDN articles) I have a main form whose Size, Location and WindowState are saved in and read from Properties.Settings.Default.<name>, e.g., Properties.Settings.Default.WindowState = WindowState; and this works great for this one form. EVERY code example I turn up seems to think there will be one and only one global setting for WindowState, none of them say how to distinguish these settings per instance.

However, I wrote the code in a superclass of the Form because I want all the Forms IN THIS APPLICATION to inherit from that class so they are all able to save/read their own size, location and state.

What I'd LIKE to do is simply replace the word "Default" in the key path above with the class name of the inheriting form. Here is pseudo code that would be great if it worked (it doesn't, and I cannot find a variation that does):

Properties.Settings[this.ToString()].WindowState = WindowState;

How can I do this correctly, reusably, maintainably, entropy-proof?

Edit: Would "config sections" be the answer? (Maybe create a section for each Form subclass?)

Edit: No, not config sections but I think this class must be part of the correct solution.

Community
  • 1
  • 1
user1944491
  • 559
  • 1
  • 8
  • 24
  • 1
    I think you need to take this to the Code Review site. – Brannon Jan 03 '13 at 03:27
  • 2
    I really wish that the folks here who seem hell-bent on simply down voting a new user's post, without providing at the very least, some pointers to the FAQ pages and such, do the site as a whole a disservice. – XIVSolutions Jan 03 '13 at 03:39
  • @user1944491 - Welcome to Stack Overflow! Your post should really take the form of a question. Be as specific as possible, and please try to avoid asking for "subjective" answers. See the FAQ Link at the top of the page for how to best use this site. As for your current post, Can you rephrase so that we know specifically what it is you need help with? Or, if you are simply seeking feedback about your solution to a problem, Brannon, above, may be correct. – XIVSolutions Jan 03 '13 at 03:41
  • @XIVSolutions - thank you! I really tried to be specific my first time out but upon reading I can see your point. The question is "how do I make user settings specific to a form?" - the code in my 2nd last paragraph is pseudo code - no worky - I am seeking the correct code. I will try to rephrase... – user1944491 Jan 03 '13 at 14:20
  • @user1944491 Asking a SO question that doesn't piss people off is an art form on it's own, I think you are doing a decent job. Don't be discouraged and welcome to SO :) – Rotem Jan 03 '13 at 14:39
  • NOTE: The reason that [Don Kirby's solution](http://stackoverflow.com/questions/105932/how-to-record-window-position-in-winforms-application-settings%20StackOverflow) doesn't apply is that it appears to require manually pre-configuring each form in the Settings designer, which I think just creates a maintenance issue. The class should (ideally) know how to add the keys for itself and then read them back out later, no human intervention needed. – user1944491 Jan 03 '13 at 20:56

1 Answers1

2

Well, at its core that's just not the way settings work in .NET by default. The settings file for settings with Scope = User are carefully hidden away in a private AppData folder with an unspeakable name. A name that's created by hashing various properties of the main EXE, including its name, location and [AssemblyVersion]. Important to prevent programs from overwriting each others settings file by accident. There is no documented way to get to that file from another program. Mostly because you have no good way to guess these property values for another program.

There are workarounds for that, instead of the default LocalFileSettingsProvider class you can create your own class derived from SettingsProvider. It's a bit painful, System.Configuration is not exactly the finest namespace in .NET. A good way to get started is by using the RegistrySettingsProvider SDK sample.

Or just punt the problem, just create your own XML file that you store in an AppData folder that you can always get to from any app. Which is in general a good idea because you'll tend to get burned by versioning problems when many apps share a common data file. You'll want to declare an XML-serializable class in its own assembly that stores these properties. With a heavy "Do not change without talking to me first" comment on top.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Hans, thanks for your time here. However, I don't want to use one file with many apps - I want this one app's user settings file to store 3 properties (WindowState, Location, Size) for every form that is used while it's running, and I want these settings to be unique to each window, and to persist so that next time the app is used each window can open in the state, location and size it had the last time. Because your answer assumes something so radically different, I'm not sure it even applies, sorry. – user1944491 Jan 03 '13 at 20:44
  • Well, I certainly got that wrong. I didn't envision an app with so many toplevel windows that this becomes unmanageable. I'll stick with the "serialize your own XML" solution though. A List will do. – Hans Passant Jan 03 '13 at 20:56