C# для профессионалов. Том II

 string [] LinesArray = new string[LinesCollection.Count];
 LinesCollection.CopyTo(LinesArray, 0);
 this.textBoxContents.Lines = LinesArray;
}

Второй параметр StringCollection.CopyTo указывает индекс в массиве назначения, где мы хотим начать размещение коллекции.

Теперь рассмотрим метод ReadFileIntoStringCollection. Мы используем StreamReader для считывания каждой строки. Основной трудностью является необходимость подсчитывать считанные символы, чтобы не превысить емкость текстового поля:

ArrayList ReadFileIntoStringCollection {
 const int MaxBytes = 65536;
 StreamReader sr = new StreamReader(ChosenFile);
 StringCollection Result = new StringCollection;
 int nBytesRead = 0;
 string NextLine;
 while ((NextLine = sr.ReadLine) != null) {
 nBytesRead += NextLine.Length;
 if (nBytesRead > MaxBytes) break;
 Result.Add(NextLine);
 }
 sr.Close;
 return Result;
}

Код завершен.

Если выполнить ReadWriteText — считать файл CivNegotiations и затем сохранить его, то файл будет иметь формат Unicode. Это невозможно для любого из обычных оконных приложений: Notepad, Wordpad и даже наш собственный пример ReadWriteText будут по-прежнему считывать файл и выводить его правильно в Windows NT/2000/XP, хотя, так как Windows 9х не поддерживает Unicode, приложения типа Notepad не смогут понять файл Unicode на этих платформах (Если загрузить пример с web-сайта издательства Wrox Press, то можно попробовать это сделать.) Однако, если попробовать вывести файл снова с помощью предыдущего примера ReadBinaryFile, то разница будет заметна немедленно, как на следующем экране. Два начальных файла указывают, что файл имеет формат Unicode, и поэтому мы видим, что каждый символ представлен двумя байтами. Этот последний факт вполне очевиден, поскольку старший байт каждого символа в данном конкретном файле равен нулю, поэтому каждый второй байт в этом файле выводится теперь как x00:

Чтение и запись в реестр

Во всех версиях Windows, начиная с Windows 95, реестр был центральным репозиторием всех конфигурационных данных, связанных с настройкой Windows, предпочтениями пользователя и установленным программным обеспечением и устройствами. Почти все коммерческое программное обеспечение сегодня использует реестр для хранения информации о себе, и компоненты COM должны помещать информацию о себе в реестр, чтобы клиент смог их вызвать. Платформа .NET и сопровождающая ее концепция о нулевом влиянии установки слегка уменьшили значение реестра для приложений в том смысле, что сборки являются полностью самодостаточными, поэтому никакая информация об определенных сборках не должна помещаться в реестр для сборок общего использования.

Тот факт, что приложения могут теперь устанавливаться с помощью программы установки Windows также освобождает разработчика от некоторых прямых манипуляций с реестром, которые обычно были связаны с установкой приложений. Однако, несмотря на это, при распространении любого законченного приложения вполне вероятно, что это приложение будет использовать реестр для хранения информации о своей конфигурации. Если приложение появляется в диалоговом окне Add/Remove Programs в панели управления, то создается соответствующая запись в реестре.

Как и можно было ожидать от такой всеобъемлющей библиотеки, как библиотека .NET, она содержит классы, которые предоставляют доступ к реестру. Имеются два класса, связанных с реестром, и оба находятся в пространстве имен Microsoft.Win32. Это классы Registry и RegistryKey. Прежде чем рассматривать их, кратко разберем структуру самого реестра.

Реестр

Реестр имеет иерархическую структуру, очень похожую на файловую систему. Обычно просмотр или изменение содержимого реестра выполняется с помощью одной из двух утилит — regedit или regedt32. regedit стандартно поставляется со всеми версиями Windows, начиная с Windows 95. Утилита regedt32 поставляется с Windows NT и Windows 2000 — она менее дружественна пользователю, чем regedit, но разрешает доступ к данным безопасности, которые regedit не может видеть. Здесь будет использоваться regedit, которую можно запустить, вводя regedit в диалоговом окне Run… или командной строке.

При первом запуске regedit появится примерно следующее изображение:

Regedit имеет интерфейс пользователя в стиле представлений дерева/списка, аналогичный Проводнику Windows, который соответствует иерархической структуре самого реестра. Однако, как мы скоро увидим, существуют некоторые различия.

В файловой системе узлами самого верхнего уровня можно считать разделы диска C:\, D:\ и т.д. В реестре эквивалентом разделу является улей реестра. Невозможно изменить существующие ульи, они являются фиксированными, и всего существует семь ульев (хотя с помощью regedit можно увидеть только пять):

□ HKEY_CLASSES_ROOT (HKCR) содержит данные о типах файлов в системе (.txt, .doc и т.д.) и приложениях, которые могут открывать файлы каждого типа. Включает также информацию о регистрации для всех компонентов COM (эта область является обычно наибольшей областью реестра, так как Windows сегодня поставляется с огромным числом компонентов COM).

□ HKEY_CURRENT_USER (HKCU) содержит данные о предпочтениях пользователя, который в данный момент зарегистрирован на машине.

□ HKEY_LOCAL_MACHINE (HKLM) является огромным ульем, который содержит данные обо всем программном обеспечении и оборудовании, установленном на машине. Он также содержит улей HKCR: HKCR в действительности не является независимым ульем со своими собственными правами, а является просто удобным отображением на ключ реестра HKLM/SOFTWARE/Classes.

□ HKEY_USERS (HKUSR) содержит данные о пользовательских предпочтениях всех пользователей. Как можно догадаться, он содержит также улей HKCU, который является отображением на один из ключей в HKEY_USERS).

□ HKEY_CURRENT_CONFIG (HKCF) содержит данные об оборудовании компьютера.

Оставшиеся два ключа содержат информацию, которая имеет временный характер и которая часто изменяется:

□ HKEY_DYN_DATA является общим контейнером для любых изменчивых данных, которые необходимо хранить где-то в реестре.

□ HKEY_PERFORMANCE_DATA содержит данные, связанные с производительностью выполняющихся приложений.

Внутри ульев находится древовидная структура ключей реестра. Каждый ключ является во многом аналогом папки или файла в файловой системе. Однако существует одно очень важное различие: файловая система различает файлы (которые предназначены для хранения данных) и папки (которые предназначены прежде всего для хранения других файлов или папок), но в реестре существуют только ключи. Ключ может содержать как данные, так и другие ключи.

Если ключ содержит данные, то они будут представлены как последовательность значений (можно привести доводы, что эти значения и есть грубые эквиваленты файлов в файловой системе). Каждое значение будет иметь имя, тип данных и значение. Кроме того, ключ может иметь значение по умолчанию, не имеющее имени.

Эту структуру можно увидеть, используя regedit для проверки ключей реестра. На экране показано содержимое ключа HKCU/Control Panel/Appearance, в котором находятся данные выбранной цветовой схемы зарегистрированного в данный момент пользователя. regedit показывает, какой ключ проверяется, выводя его с изображением открытой папки в древовидном представлении: