Как в C # отличить пользовательские настройки по имени?

После CodeProject < / em> и StackOverflow.105932 (и несколько других, например, StackOverflow .1873658 и статьи MSDN) У меня есть основная форма, размер, расположение и WindowState которой сохраняются и читаются из Properties.Settings.Default.<name>, например, Properties.Settings.Default.WindowState = WindowState;, и это отлично подходит для этой формы. В КАЖДОМ примере кода, который я приводил, кажется, что будет одна и только одна глобальная настройка для WindowState, ни один из них не говорит, как различать эти настройки для каждого экземпляра.

Однако я написал код в суперклассе формы, потому что я хочу, чтобы все формы В ЭТОМ ПРИЛОЖЕНИИ унаследовались от этого класса, чтобы все они могли сохранять / читать свой собственный размер, местоположение и состояние.

Я бы хотел просто заменить слово «Default» в указанном выше ключевом пути на имя класса наследующей формы. Вот псевдокод, который был бы отличным, если бы он работал (это не так, и я не могу найти вариант, который работает):

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

Как я могу сделать это правильно, многоразово, обслуживаемое, энтропийное?

Изменить: будут ли "разделы конфигурации" ответом? (Может быть, создать раздел для каждого подкласса формы?)

Изменить: Нет, не разделы конфигурации, но я думаю этот класс должен быть частью правильного решения.


windows c# winforms settings settings.settings
person user1944491    schedule 03.01.2013    source источник
comment
Я думаю, вам нужно отнести это на сайт Code Review.   -  person Brannon    schedule 03.01.2013
comment
Я действительно желаю, чтобы люди здесь, которые, кажется, одержимы простым голосованием за сообщение нового пользователя, не предоставляя хотя бы некоторых указателей на страницы часто задаваемых вопросов и тому подобное, оказали сайту в целом медвежью услугу.   -  person XIVSolutions    schedule 03.01.2013
comment
@ user1944491 - Добро пожаловать в Stack Overflow! Ваш пост действительно должен иметь форму вопроса. Будьте как можно более конкретными и постарайтесь не спрашивать субъективных ответов. См. Ссылку на часто задаваемые вопросы вверху страницы, чтобы узнать, как лучше всего использовать этот сайт. Что касается вашего текущего сообщения, можете ли вы перефразировать, чтобы мы знали, в чем конкретно вам нужна помощь? Или, если вы просто ищете отзывы о своем решении проблемы, Браннон, приведенный выше, может быть прав.   -  person XIVSolutions    schedule 03.01.2013
comment
@XIVSolutions - спасибо! Я действительно старался быть конкретным в свой первый раз, но, прочитав, я могу понять вашу точку зрения. Вопрос в том, как сделать индивидуальные пользовательские настройки для формы? - код в моем 2-м последнем абзаце - псевдокод - не работает - я ищу правильный код. Попробую перефразировать ...   -  person user1944491    schedule 03.01.2013
comment
@ user1944491 Задавать ТАК вопрос, который не бесит людей, - это само по себе искусство, я думаю, вы делаете достойную работу. Не расстраивайтесь и добро пожаловать в SO :)   -  person Rotem    schedule 03.01.2013
comment
ПРИМЕЧАНИЕ. Причина, по которой решение Дона Кирби не применяется, так как это, по-видимому, требует ручной предварительной настройки каждой формы в конструкторе настроек, что, как мне кажется, просто создает проблемы с обслуживанием. Класс должен (в идеале) знать, как добавить ключи для себя, а затем прочитать их позже, без вмешательства человека.   -  person user1944491    schedule 04.01.2013

Ответы (1)


arrow_upward
2
arrow_downward

Ну, по сути, в .NET настройки по умолчанию работают не так. Файл настроек для настроек с Scope = User тщательно спрятан в частной папке AppData с невыразимым именем. Имя, которое создается путем хеширования различных свойств основного EXE, включая его имя, расположение и [AssemblyVersion]. Важно, чтобы программы не могли случайно перезаписать файлы настроек друг друга. Нет задокументированного способа доступа к этому файлу из другой программы. В основном потому, что у вас нет хорошего способа угадать значения этих свойств для другой программы.

Для этого есть обходные пути, вместо класса LocalFileSettingsProvider по умолчанию вы можете создать свой собственный класс, производный от SettingsProvider. Это немного болезненно, System.Configuration не совсем лучшее пространство имен в .NET. Хороший способ начать - использовать RegistrySettingsProvider Образец SDK.

Или просто решите проблему, просто создайте свой собственный XML-файл, который вы храните в папке AppData, к которой вы всегда можете получить доступ из любого приложения. В общем, это хорошая идея, потому что вы будете гореть из-за проблем с версией, когда многие приложения используют общий файл данных. Вы захотите объявить сериализуемый XML-класс в своей собственной сборке, в которой хранятся эти свойства. С тяжелым комментарием «Не меняйся, не поговорив сначала со мной».

person Hans Passant    schedule 03.01.2013
comment
Ханс, спасибо, что уделили время здесь. Однако я не хочу использовать один файл со многими приложениями - я хочу, чтобы в файле пользовательских настроек этого приложения хранились 3 свойства (WindowState, Location, Size) для каждой формы, которая используется во время ее работы, и я хочу, чтобы эти настройки были быть уникальным для каждого окна и сохраняться, чтобы при следующем использовании приложения каждое окно могло открываться в том состоянии, расположении и размере, которое было в последний раз. Поскольку ваш ответ предполагает нечто совершенно иное, я не уверен, что это вообще применимо, извините. - person user1944491; 04.01.2013
comment
Что ж, я определенно ошибся. Я не представлял себе приложение с таким количеством окон верхнего уровня, что это становится неуправляемым. Однако я буду придерживаться сериализации вашего собственного XML-решения. Подойдет список. - person Hans Passant; 04.01.2013