Метод ReadSettings() немного длиннее, так как каждое считанное значение нужно также проинтерпретировать, чтобы вывести значение в окне списка и сделать подходящие изменения в соответствующем свойстве основной формы. ReadSettings() выглядит следующим образом:
bool ReadSettings() {
RegistryKey SoftwareKey = Registry.LocalMachine.OpenSubKey('Software'));
RegistryKey WroxKey = SoftwareKey.OpenSubKey('WroxPress');
if (WroxKey == null) return false;
RegistryKey SelfPlacingWindowKey = WroxKey.OpenSubKey('SelfPlacingWindow');
if (SelfPlacingWindowKey == null) return false;
else
listBoxMessages.Items.Add('Successfully opened key ' + SelfPlacingWindowKey.ToString ());
int RedComponent = (int)SelfPlacingWindowKey.GetValue('Red');
int GreenComponent = (int)SelfPlacingWindowKey.GetValue('Green');
int BlueComponent = (int)SelfPlacingWindowKey.GetValue('Blue');
BackColor = Color.FromArgb(RedComponent, GreenComponent, BlueComponent);
listBoxMessages.Items.Add('Background color: ' + BackColor.Name);
int X = (int(SelfPlacingWindowKey.GetValue('X');
int Y = (int)SelfPlacingWindowKey.GetValue('Y');
DesktopLocation = new Point(X, Y);
listBoxMessages.Items.Add('Desktop location: ' + DesktopLocation.ToString());
Height = (int)SelfPlacingWindowKey.GetValue('Height');
Width = (int)SelfPlacingWindowKey.GetValue('Width');
listBoxMessages.Items.Add('Size: ' + new Size(Width, Height).ToString());
string InitialWindowState = (string)SelfPlacingWindowKey.GetValue('WindowState');
listBoxMessages.Items.Add('Window State: ' + InitialWindowState);
WindowState =
(FormWindowState)FormWindowState.Parse(WindowState.GetType() , InitialWindowState)
return true;
}
В ReadSettings() мы должны сначала перейти в ключ реестра HKLM/Software/WroxPress/SelfPlacingWindow. При этом, однако, мы надеемся найти ключ, чтобы его можно было прочитать. Если его нет, то, вероятно, пример выполняется в первый раз. В этом случае мы хотим прервать чтение ключей, и, конечно, не желаем создавать какие-либо ключи. Теперь мы все время используем метод RegistryKey.OpenSubkey(). Если на каком-то этапе OpenSubkey() возвращает ссылку null, то мы знаем, что ключ реестра отсутствует, и можем вернуть значение false в вызывающий код.
В реальности для считывания ключей используется метод RegistryKey.GetValue(), который определен как возвращающий объектную ссылку, это означает, что такой метод может на самом деле вернуть экземпляр практически любого класса, который он выберет подобно SetValue(), он возвращает класс объекта, соответствующий типу данных, которые он найдет в ключе. Поэтому можно предполагать, что ключ REG_SZ будет выдан как строка, а другие ключи — как int. Мы также преобразуем соответственно возвращаемую из SetValue() ссылку. При возникновении исключения, если кто-то делал какие-то манипуляции с реестром и исказил типы данных, наше преобразование породит исключение, которое будет перехватываться обработчиком в конструкторе Form1.
Остальная часть кода использует еще один тип данных, структуру Size, выглядящую пока незнакомой, потому что она будет рассматриваться только в главе GDI+. Структура Size аналогична Point, но используется для представления размеров, а не координат. Она имеет два свойства члена — Width и Height, и мы используем структуру Size в данном случае просто как удобный способ представления размера формы для вывода в поле списка.
Заключение
В этой главе было рассмотрено использование базовых классов .NET для доступа к реестру и файловой системе из кода C#. Мы видели, что базовые классы предоставляют достаточно мощные и при этом доступные объектные модели для создания, модификации или чтения ключей в случае реестра, а в случае файловой системы — для копирования файлов, перемещения, создания и удаления файлов и папок, а так же для чтения и записи текстовых или двоичных файлов.
В этой главе предполагалось, что код должен выполняться с помощью учетной записи, которая имеет необходимые полномочия доступа для выполнения действий, требуемых кодом. Очевидно, что вопрос безопасности является важным вопросом там, где дело касается доступа к файлам, и эта область будет рассмотрена в главе 25.
Глава 15
Мы получаем активный каталог (Active Directory) как часть Windows 2000 Server. Активный каталог является службой каталога, где может храниться информация о пользователях, принтерах, службах и обычные данные. Exchange Server 2000 компании Microsoft интенсивно использует его для хранения общедоступных папок и другой информации. Мы также можем хранить в активном каталоге определяемые нами данные. В файловой системе каталог хранит файлы, телефонный каталог хранит телефонные номера и имена. Служба каталога делает доступной информацию в каталоге. С помощью Проводника можно, например, находить файлы.
До появления ADS сервер Exchange мог использовать активный каталог для хранения своих объектов. Системным администраторам приходилось конфигурировать два идентификатора пользователя для одного человека: учетную запись пользователя в домене Windows NT, чтобы можно было зарегистрироваться в системе, и пользователя в Exchange Directory. Это было необходимо, так как для пользователей требовалась дополнительная информация (такая как адреса e-mail, телефонные номера и так далее), а данные о пользователях домена NT были нерасширяемыми, что не позволяло поместить туда требуемую информацию. Теперь системному администратору достаточно сконфигурировать только одного пользователя для человека в активном каталоге, данные объекта пользователя можно расширять, чтобы удовлетворить требованиям Exchange Server. Мы можем также расширить эту информацию.
Рассмотрим менеджера проекта в большой компании, который ищет с помощью Active Directory разработчика, способного создать приложения с помощью C#. Было бы неплохо, если бы менеджер мог сделать простой запрос для получения списка всех разработчиков, удовлетворяющих его требованиям. Такую возможность предоставляет активный каталог, в котором объект пользователя дополняется списком навыков.
