Пространство System.IO предлагает четыре типа, позволяющие как обработку отдельных файлов, так и взаимодействие со структурой каталогов машины. Первые два из этих типов – Directory и File – с помощью различных статических членов позволяют выполнение операций создания, удаления, копирования и перемещения файлов. Родственные типы FileInfo и DirectoryInfo предлагают аналогичные возможности в виде методов экземпляра (который, таким образом, необходимо будет создать). На рис. 16.1 показана схема зависимости типов, связанных с обработкой каталогов и файлов. Обратите внимание на то, что типы Directory и File расширяют непосредственно System.Object, в то время как DirectoryInfo и FileInfo получаются из абстрактного типа FileSystemInfo.

Рис. 16.1. Типы, обеспечивающие работу с каталогами и файлами

Вообще говоря, FileInfо и DirectoryInfо являются лучшим выбором для рекурсивных операций (таких как, например, составление перечня всех подкаталогов с данным корнем), поскольку члены классов Directory и File обычно возвращает строковые значения, а не строго типизированные объекты.

 

Абстрактный базовый класс FileSystemInfo

Типы DirectoryInfo и FileInfo во многом наследуют свое поведение от абстрактного базового класса FileSystemInfo. По большей части члены класса FileSystemInfo используются для получения общих характеристик (таких как, например, время создания, различные атрибуты и т.д.) соответствующего файла иди каталога. В табл. 16.2 описаны свойства FileSystemInfo, представляющие наибольший интерес.

Таблица 16.2. Свойства FileSystemInfo

Тип FileSystemInfo определяет также метод Delete(). Этот метод реализуется производными типами для удаления данного файла или каталога с жесткого диска. Кроме того, перед получением информации атрибута может вызываться Refresh(), чтобы гарантировать то, что информация о текущем файле (или каталоге) не будет устаревшей.

 

Первым из рассматриваемых в нашем обсуждении типов, связанных с реализацией ввода-вывода и допускающих создание экземпляров, будет класс DirectoryInfo. Этот класс предлагает набор членов, используемых для создания, перемещения, удаления и перечисления каталогов и подкаталогов. Кроме функциональных возможностей, обеспеченных базовым классом (FileSystemInfo), класс DirectoryInfo предлагает и свои члены, описанные в табл. 16.3.

Таблица 16.3. Основные члены типа DirectoryInfo

Мы начнем работу с типом DirectoryInfo с попытки указать конкретный путь каталога для использования в качестве параметра конструктора. Чтобы получить доступ к текущему каталогу приложения (т.е. к каталогу приложения, выполняющегося в данный момент), используйте обозначение ".". Вот подходящие примеры.

// Привязка к текущему каталогу приложения.

DirectoryInfo dir1 = new DirectoryInfo(".");

// Привязка к C:\Windows с помощью строки,

// для которой указано "дословное" применение.

DirectoryInfo dir2 = new DirectoryInfo(@"C:\Windows");

Во втором примере предполагается, что передаваемый конструктору путь (путь C:\Windows) уже существует на данной физической машине. Если вы попытаетесь взаимодействовать с несуществующим каталогом, будет сгенерировано исключение System.IO.DirectoryNotFoundException (каталог не найден). Поэтому если вы укажете каталог, который еще не создан, то перед его использованием вам придется сначала вызвать метод Create().

// Привязка к несуществующему каталогу с последующим его созданием.

DirectoryInfo dir3 = new DirectoryInfo(@"C:\Window\Testing");

dir3.Create();

После создания объекта DirectoryInfo вы можете исследовать содержимое соответствующего каталога с помощью свойств, унаследованных от FileSystemInfo. Например, следующий класс создает новый объект DirectoryInfo, связанный с C:\Windows (при необходимости измените этот путь в соответствии с установками системы на вашей машине) и отображающий ряд интересных статистических данных об указанном каталоге (рис. 16.2).

class Program {

 static void Main(string[] args) {

  Console.WriteLine("* **** Забавы с Directory(Info) *****\n");

  DirectoryInfo dir = new DirectoryInfo(@"C:\Windows");

  // Информация о каталоге.

  Console.WriteLine("***** Информация о каталоге *****");

  Console.WriteLine("Полное имя: {0} ", dir.FullName);

  Console.WriteLine("Имя: {0} ", dir.Name);

  Console.WriteLine("Родитель: {0} ", dir.Parent);

  Console.WriteLine("Создан: {0} " , dir.CreationTime);

  Console.WriteLine("Атрибуты: {0} ", dir.Attributes);

  Console.WriteLine("Корневой каталог: {0}", dir.Root);

  Console.WriteLine("********************************\n");

 }

}

Рис. 16.2. Информация о каталоге Windows

 

Перечень FileAttributes

Свойство Attributes, предоставленное объектом FileSystemInfо, обеспечивает получение различной информации о текущем каталоге или файле, и вся она содержится в перечне FileAttributes. Имена полей этого перечня говорят сами за себя, но некоторые менее очевидные имена здесь сопровождаются комментариями (подробности вы найдете в документации .NET Framework 2.0 SDK).

public enum FileAttributes {

 ReadOnly,

 Hidden,

 // Файл, являющийся частью операционной системы или используемый

 // исключительно операционной системой.

 System,

 Directory,

 Archive,

 // Это имя зарезервировано для использования в будущем.

 Device,

 // Файл является 'нормальным' (если не имеет других

 // установленных атрибутов),

 Normal,

 Temporary,

 // Разреженные файлы обычно являются большими файлами,

 // данные которых по большей части – нули.

 SparseFile,

 // Блок пользовательских данных, связанных с файлом или каталогом.

 ReparsePoint,

 Compressed,

 Offline,

 // Файл, который не будет индексирован службой индексации

 // содержимого операционной системы.

 NotContentIndexed,

 Encrypted

}

 

Перечисление файлов с помощью DirectoryInfo

Вдобавок к получению базовой информации о существующем каталоге, вы можете добавить в пример несколько вызовов методов типа DirectoryInfo. Сначала используем метод GetFiles(), чтобы получить информацию обо всех файлах *.bmp, размещенных каталоге C:\Windows. Этот метод возвращает массив типов FileInfo, каждый из которых сообщает подробности о конкретном файле (подробности о самом типе FileInfo будут представлены в этой главе немного позже).

class Program {

 static void Main(string[] args) {

  Console.WriteLine("***** Забавы с Directory(Info) *****\n");

  DirectoryInfo dir = new DireetoryInfо(@"C:\Windows");

  // Получение всех файлов с расширением bmp.

  FileInfo[] bitmapFiles = dir.GetFiles("*.bmp");

   // Сколько их всего?

  Console.WriteLine("Найдено {0} файлов *.bmp\n", bitmapFiles.Length);

  // Вывод информации о файлах.

  foreach (FileInfo f in bitmapFiles) {

   Console.WriteLine("***************************\n");

   Console.WriteLine("Имя: {0} ", f.Name);

   Console.WriteLine("Размер: {0} ", f.Length);

   Console.WriteLine("Создан: {0} ", f.CreationTime);

   Console.WriteLine("Атрибуты: {0} ", f.Attributes);

   Console.WriteLine("***************************\n");

  }

 }

}

Запустив это приложение, вы увидите список, подобный показанному на рис. 16.3 (ваши результаты могут быть другими!).

Рис. 16.3. Информация о файлах с точечными изображениями

 

Создание подкаталогов с помощью DirectoryInfo

Вы можете программно расширить структуру каталога, используя метод DirectoryInfo.CreateSubdirectory(). Этот метод с помощью одного обращения к функции позволяет создать как один подкаталог, так и множество вложенных подкаталогов. Для примера рассмотрите следующий блок программного кода, расширяющий структуру каталога C:\Windows путем создания нескольких пользовательских подкаталогов.

class Program {

 static void Main(string[] args) {

  Console.WriteLine("***** Забавы с Directory(Info) *****\n");

  DirectoryInfo dir = new DirectoryInfo(@"C:\Windows");

  …

  // Создание \MyFoo в исходном каталоге.

  dir.CreateSubdirectory("MyFoo");

  // Создание \MyBar\MyQaaz в исходном каталоге

  dir.CreateSubdirectory(@"MyBar\MyQaaz");

 }

}

Если теперь проверить каталог Windows в окне программы Проводник, вы увидите там новые подкаталоги (рис. 16.4).

Рис. 16.4. Создание подкаталогов

Хотя вы и не обязаны использовать возвращаемое значение метода CreateSubdirectory(), полезно знать, что в случае успешного выполнения тип DirectoryInfo возвращает созданный элемент.

// CreateSubdirectory() возвращает объект DirectoryInfo,

// представляющий новый элемент.

DirectoryInfo d = dir.CreateSubdirectory("MyFoo");

Console.WriteLine("Создан: {0} ", d.FullName);

d = dir.CreateSubdirectory(@"MyBar\MyQaaz");

Console.WriteLine("Создан: {0} ", d.FullName);

 

Как показывает пример MyDirectoryApp, класс FileInfo позволяет получить подробные сведения о файлах, имеющихся на вашем жестком диске (время создания, размер, атрибуты и т.д.), а также помогает создавать, копировать, перемещать и уничтожать файлы. Вдобавок к набору функциональных возможностей, унаследованных от FileSystemInfо, класс FileInfo имеет свои уникальные члены, и некоторые из них описаны в табл. 16.4.

Таблица 16.4. Наиболее важные элементы FileInfo

Важно понимать, что большинство членов класса FileInfo возвращает специальный объект ввода-вывода (FileStream, StreamWriter и т.д.), который позволит начать чтение или запись данных в соответствующем файле в самых разных форматах. Мы исследуем указанные типы чуть позже, а пока что давайте рассмотрим различные способы получения дескриптора файла с помощью типа класса FileInfo.

 

Метод FileInfо.Create()

Первая возможность создания дескриптора файла обеспечивается методом FileInfo.Create().

public class Program {

 static void Main(string[] args) {

  // Создание нового файла на диске C.

  FileInfo f = new FileInfо(@"C:\Test.dat");

  FileStream fs = f.Create();

  // Использование объекта FileStream.…

  // Закрытие файлового потока.

  fs.Close();

 }

}

Обратите внимание на то, что метод FileInfo.Create() возвращает тип FileStream, который, в свою очередь, предлагает набор синхронных и асинхронных операций записи/чтения для соответствующего файла. Объект FileStream, возвращенный методом FileInfo.Create(), обеспечивает полный доступ чтения/записи всем пользователям.

 

Метод FileInfo.Open()

Метод FileInfо.Open() можно использовать для того, чтобы открывать существующие файлы и создавать новые с более точными характеристиками, чем при использовании FileInfo.Create(). В результате вызова Open() возвращается объект FileStream. Рассмотрите следующий пример.

static void Main(string[] args) {

 …

 // Создание нового файла с помощью FileInfo.Open().

 FileInfo f2 = new FileInfo(@"C:\Test2.dat");

 FileStream fs2 = f2.Open(FileMode.OpenOrCreate, FileAccess.ReadWrite, FileShare.None);

 // Использование объекта FileStream.…

 // Закрытие файлового потока.

 fs2.Close();

}

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

public enum FileMode {

 // Дает операционной системе указание создать новый файл.

 // Если файл уже существует, генерируется System.IO.IOException.

 CreateNew,

 // Дает операционной системе указание создать новый файл,

 // Если файл уже существует, он будет переписан.

 Create,

 Open,

 // Дает операционной системе указание открыть файл,

 // если он существует, иначе следует создать новый файл.

 OpenOrCreate,

 Truncate,

 Append

}

Второй параметр, значение из перечня FileAccess, используется для определения характеристик чтения/записи в соответствующем потоке.

public enum FileAccess {

 Read,

 Write,

 ReadWrite

}

Наконец, третий параметр, FileShare, указывает возможности совместного использования файла другими дескрипторами файла. Вот как выглядит соответствующий перечень.

public enum FileShare {

 None,

 Read,

 Write,

 ReadWrite

}

 

Методы FileInfo.OpenRead() и FileInfo.OpenWrite()

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

Подобно FileInfo.Create() и FileInfo.Open(), методы OpenRead() и OpenWrite() возвращают объект FileStream.

static void Main(string[] args) {

 …

 // Получение объекта FileStream с доступом только для чтения.

 FileInfo f3 = new FileInfo(@"C:\Test3.dat");

 FileStream readOnlyStream = f3.OpenRead();

 // Использование объекта FileStream…

 readOnlyStream.Close();

 // Получение объекта FileStream с доступом только для записи.

 FileInfо f4 = new FileInfo(@"C:\Test4.dat");

 FileStream writeOnlyStream = f4.OpenWrite();

 // Использование объекта FileStream…

 writeOnlyStream.Close();

}

 

Метод FileInfo.OpenText()

Другим членом типа FileInfo, связанным с открытием файлов, является OpenText(). В отличие от Create(), Open(), OpenRead() и OpenWrite(), метод OpenText() возвращает экземпляр типа StreamReader, а не типа FileStream.

static void Main(string[] args) {

 …

 // Получение объекта StreamReader.

 FileInfo f5 = new FileInfо(@"C:\boot.ini");

 StreamReader sreader = f5.OpenText();

 // Использование объекта StreamReader.…

 sreader.Close();

}

Чуть позже вы увидите, что тип StreamReader обеспечивает возможность чтения символьных данных из соответствующего файла.

 

Методы FileInfo.CreateText() и FileInfo.AppendText()

И последними интересующими нас на этот момент методами будут CreateText() и AppendText(), которые возвращают ссылку на StreamWriter, как показано ниже.

static void Main(string[] args) {

 …

 FileInfo f6 = new FileInfo(@"C:\Test5.txt");

 StreamWriter swriter = f6.CreateText();

 // Использование объекта StreamWriter….

 swriter.Close();

 FileInfo f7 = new FileInfo(@"C:\FinalTest.txt");

 StreamWriter swriterAppend = f7.AppendText();

 // Использование объекта StreamWriter…

 swriterAppend.Close();

}

Вы должны догадаться сами, что тип StreamWriter предлагает способ записи символьных данных в соответствующий файл.

 

Тип File предлагает функциональные возможности, почти идентичные возможностям типа FileInfo, но с помощью ряда статических членов. Подобно FileInfo, тип File предлагает методы AppendText(), Create(), CreateText(), Open(), OpenRead(), OpenWrite() и OpenText(). Во многих случаях типы File и

FileStream оказываются взаимозаменяемыми. Так, в каждом из предыдущих примеров вместо FileStream можно использовать тип File.

static void Main(string[] args) {

 // Получение объекта FileStream с помощью File.Create() .

 FileStream fs = File.Create(@"C:\Test.dat");

 fs.Close();

 // Получение объекта FileStream с помощью File.Open().

 FileStream fs2 = File.Open(@"C:\Test2.dat", FileMode.OpenOrCreate, FileAccess.ReadWrite, FileShare.None);

 fs2.Close();

 // Получение объекта FileStream с доступом только для чтения.

 FileStream readOnlyStream = File.OpenRead(@"Test3.dat");

 readOnlyStream.Close();

 // Получение объекта FileStream с доступом только для записи.

FileStream writeOnlyStream = File.OpenWrite(@"Test4.dat");

 writeOnlyStream.Close();

 // Получение объекта StreamReader.

 StreamReader sreader = Filе.OpenText(@"C:\boot.ini");

 sreader.Close();

 // Получение нескольких объектов StreamWriter.

 StreamWriter swriter = File.CreateText(@"C:\Test3.txt");

 swriter.Close();

 StreamWriter swriterAppend = File.AppendText(@"C:\FinalTest.txt");

 swriterAppend.Close();

}

 

Новые члены File в .NET 2.0

В отличие от FileInfo, тип File поддерживает (в .NET 2.0) несколько своих собственных уникальных членов, описания которых приводятся в табл. 16.5. С помощью этих членов можно существенно упростить процессы чтения и записи текстовых данных.

Таблица 16.5. Методы типа File

При использовании этих новых методов типа File для чтения и записи пакетов данных потребуется всего несколько строк программного кода. Более того, каждый из указанных новых членов автоматически закрывает соответствующий дескриптор файла, например:

class Program {

 static void Main(string[] args) {

  string[] myTasks = { "Прочистить сток в ванной", "Позвонить Саше и Сереже", "Позвонить родителям", "Поиграть с ХВох" };

  // Записать все данные в файл на диске C.

  File.WriteAllLines(@"C:\tasks.txt", myTasks);

  // Прочитать все снова и напечатать.

  foreach (string task in File.ReadAllLines(@"C:\tasks.txt")) {

   Console.WriteLine("Нужно сделать: {0}", task);

  }

 }

}

Очевидно, когда вы хотите быстро получить дескриптор файла, тип File избавит вас от необходимости ввода нескольких лишних строк. Однако преимущество предварительного создания объекта FileInfo заключается в том, что тогда вы получаете возможность исследовать соответствующий файл с помощью членов абстрактного базового класса FileSystemInfо.

static void Main(string[] args) {

 // Вывод информации о файле boot.ini

 // с последующим открытием доступа только для чтения.

 FileInfo bootFile = new FileInfо(@"C:\boot.ini");

 Console.WriteLine(bootFile.CreationTime);

 Console.WriteLine(bootFile.LastAccessTime);

 FileStream readOnlyStream = bootFile.OpenRead();

 readOnlyStream.Close();

}

 

К этому моменту вы уже видели множество способов получения объектов FileStream, StreamReader и StreamWriter, но вам придется еще читать и записывать данные файлов, связанных с этими типами. Чтобы понять, как это делается, нужно ознакомиться с понятием потока. В "мире" ввода-вывода поток представляет порцию данных. Потоки обеспечивают общую возможность взаимодействия с последовательностями байтов, независимо от того, на устройстве какого вида (в файле, сетевом соединении, принтере и т.п.) они хранятся или отображаются.

Абстрактный класс System.IO.Stream определяет ряд членов, обеспечивающих поддержку синхронного и асинхронного взаимодействия с носителем данных (скажем, с файлом или областью памяти). На рис. 16.6 показано несколько потомков типа Stream.

Рис. 16.6. Типы, производные от Stream

Замечание. Следует знать, что понятие потока применимо не только к файлам или области памяти. Без сомнения, библиотеки .NET обеспечивают потоковый доступ к сетям и другим связанным с потоками абстракциям.

Напомним, что потомки stream представляют данные в виде "сырого" потока байтов, поэтому работа с потоками может быть весьма непонятной. Некоторые относящиеся к Stream типы поддерживают поиск – этот термин, по сути, означает процесс получения он изменения текущей позиции в потоке. Чтобы понять функциональные возможности, предлагаемые классом Stream, рассмотрите его базовые члены, описанные в табл. 16.6.

Таблица 16.6. Абстрактные члены Stream

 

Работа с FileStream

Класс FileStream обеспечивает реализацию абстрактных членов Stream в виде, подходящем для файловых потоков. Это довольно примитивный поток – он может читать или записывать только один байт или массив байтов. На самом деле необходимость непосредственного взаимодействия с членами типа FileStream возникает очень редко. Вы чаще будете использовать различные упаковщики потоков, которые упрощают работу с текстовыми данными или типами .NET. Однако для примера давайте поэкспериментируем со средствами синхронного чтения/записи типа FileStream.

Предположим, что мы создали новое консольное приложение FileStreamApp. Нашей целью является запись простого текстового сообщения в новый файл с именем myMessage.dat. Но поскольку FileStream может воздействовать только на отдельные байты, требуется перевести тип System.String в соответствующий массив байтов. К счастью, в пространстве имен System.Text определяется тип Encoding, предлагающий члены, которые выполняют кодирование и декодирование строк и массивов байтов (для подробного описания типа Encoding обратитесь к документации .NET Framework 2.0 SDK).

После выполнения кодирования массив байтов переводится в файл с помощью метода FileStream.Write(). Чтобы прочитать байты обратно в память, необходимо переустановить внутренний указатель позиции потока (с помощью свойства Position) и вызвать метод ReadByte(). Наконец, массив байтов и декодированная строка выводятся на консоль. Вот полный текст соответствующего метода Main().

// Не забудьте 'использовать' System.Text.

static void Main(string[] args) {

 Console.WriteLine("***** Забавы с FileStreams *****\n");

  // Получение объекта FileStream.

 FileStream fStream = File.Open(@"C:\myMessage.dat", FileMode.Create);

 // Кодирование строки в виде массива байтов.

 string msg = "Привет!";

 byte[] msgAsByteArray = Encoding.Default.GetBytes(msg);

 // Запись byte[] в файл.

 fStream.Write(msgAsByteArray, 0, msgAsByteArray.Length);

 // Переустановка внутреннего указателя позиции потока.

 fStream.Position = 0;

 // Чтение типов из файла и вывод на консоль….

 Console.Write("Ваше сообщение в виде массива байтов: ");

 byte[] bytesFromFile = new byte[msgAsByteArray.Length];

 for (int i = 0; i ‹ msgAsByteArray.Length; i++) {

  bytesFromFile[i] = (byte)fStream.ReadByte();

  Console.Write(bytesFromFile[i]);

 }

 // Вывод декодированного сообщения.

 Console.Write("\nДекодированное сообщение: ");

 Console.WriteLine(Encoding.Default.GetString(bytesFromFile));

  // Завершение потока.

 fStream.Close();

}

Хотя в этом примере файл данными не заполняется, уже здесь становится очевидным главный недостаток работы с типом FileStream: приходится воздействовать непосредственно на отдельные байты. Другие типы, являющиеся производными от Strеаm, работают аналогично. Например, чтобы записать последовательность байтов в заданную область памяти, можно использовать MemoryStream. Точно так же, чтобы передать массив байтов по сети, вы можете использовать тип NetworkStream.

К счастью, пространство имен System.IO предлагает целый ряд типов "чтения" и "записи", инкапсулирующих особенности работы с типами, производными от Stream.

Исходный код. Проект FileStreamApp размещен в подкаталоге, соответствующем главе 16.

 

Классы StreamWriter и StreamReader оказываются полезны тогда, когда приходится читать или записывать символьные данные (например, строки). Оба эти типа по умолчанию работают с символами Unicode, однако вы можете изменить эти установки, предоставив ссылку на правильно сконфигурированный объект System.Text.Encoding. Чтобы упростить рассмотрение, предположим, что предлагаемое по умолчавию кодирование в символы Unicode как раз и является подходящим.

Тип StreamReader получается из абстрактного типа TextReader. To же можно сказать и о родственном типе StringReader (он будет обсуждаться в этой главе позже). Базовый класс TextReader обеспечивает каждому из этих "последователей" очень небольшой набор функциональных возможностей, среди которых, в частности, возможность чтения символов из потока и их добавление в поток.

Тип StreamWriter (как и StringWriter, который также будет рассматриваться позже) получается из абстрактного базового класса TextWriter. Этот класс определяет члены, позволяющие производным типам записывать текстовые данные в имеющийся символьный поток. Взаимосвязь между этими новыми типами ввода-вывода показана на рис. 16.7.

Чтобы помочь вам понять возможности записи классов StreamWriter и StringWriter, в табл. 16.7 предлагаются описания основных членов абстрактного базового класса TextWriter.

Рис. 16.7. Читатели и писатели

Таблица 16.7. Основные члены TextWriter 

Замечание. Последние два из указанных в таблице членов класса TextWriter, вероятно, покажутся вам знакомыми. Если вы помните, у типа System.Console есть члены Write() и WriteLine(), записывающие текстовые данные в устройство стандартного вывода. На самом деле свойство Console.In является упаковкой для TextWriter, а свойство Console.Out – для TextReader.

Производный класс StreamWriter обеспечивает подходящую реализацию методов Write(), Close() и Flush() и определяет дополнительное свойство AutoFlush. Это свойство, когда его значение равно true (истина), заставляет StreamWriter при выполнении операции записи записывать все данные. Можно добиться лучшей производительности, если установить для AutoFlush значение false (ложь), поскольку иначе при каждой записи StreamWriter будет вызываться Close().

 

Запись в текстовый файл

Рассмотрим пример работал с типом StreamWriter. Следующий класс создает новый файл reminders.txt с помощью метода File.CreateText(). С помощью полученного объекта StreamWriter в новый файл добавляются определенные текстовые данные, как показано ниже.

static void Main(string[] args) {

 Console.WriteLine("*** Забавы с StreamWriter/StreamReader ***\n");

 // Получение StreamWriter и запись строковых данных.

 StreamWriter writer = File.CreateText("reminders.txt");

 writer.WriteLine("Нe забыть о дне рождения мамы…");

 writer.WriteLine("Не забыть о дне рождения папы…");

 writer.WriteLine("Не забыть о следующих числах:");

 for(int i = 0; i ‹ 10; i++) writer.Write(i + " ");

 // вставка новой строки.

 writer.Write(writer.NewLine);

 // Закрытие автоматически влечет запись всех оставшихся данных!

 writer.Close();

 Console.WriteLine("Создан файл и записаны некоторые идеи…");

}

Выполнив эту программу, вы можете проверить содержимое нового файла (рис. 16.8).

Рис. 16.8. Содержимое вашего файла * .txt

 

Чтение из текстового файла

Теперь выясним, как программными средствами читать данные из файла, используя соответствующий тип StreamReader. Вы должны помнить, что этот класс получается из TextReader, функциональные возможности которого описаны в табл. 16.8.

Таблица 16.8. Основные члены TextReader

Если теперь расширить имеющийся класс MyStreamWriter.Reader, чтобы использовать в нем StreamReader, вы сможете прочитать текстовые данные из файла reminders.txt, как показано ниже.

static void Main(string[] args) {

 Console.WriteLine("*** Забавы с StreamWriter/StreamReader ***\n");

 …

 // Теперь чтение данных из файла.

 Console.WriteLine("Вот ваши идеи:\n");

 StreamReader sr = File.OpenText("reminders.txt");

 string input = null;

 while ((input = sr.ReadLine()) != null) {

  Console.WriteLine(input);

 }

}

Выполнив программу, вы увидите символьные данные из reminders.txt, выведенные на консоль.

 

Непосредственное создание типов StreamWriter/StreamReader

Одной из смущающих особенностей работы с типами из System.IO является то, что часто одних и тех же результатов можно достичь в рамках множества подходов. Например, вы видели, что можно получить StreamWriter из File или из FileInfo, используя метод CreateText(). На самом деле есть еще одна возможность получения StreamWriters и StreamReaders – это непосредственное их создание. Например, наше приложение можно было бы переписать в следующем виде.

static void Main(string[] args) {

 Console.WriteLine("*** Забавы с StreamWriter/StreamReader ***\n");

 // Get a StreamWriter and write string data.

 StreamWriter writer = new StreamWriter("reminders.txt");

 …

 // Now read data from file.

 StreamReader sr = new StreamReader("reminders.txt");

 …

}

Видеть так много идентичных, на первый взгляд, подходов к реализации ввода-вывода, может быть, немного странно, но имейте в виду, что конечным результатом здесь оказывается гибкость. Так или иначе, вы смогли увидеть, как можно извлекать символьные данные из файлов и помещать их в файлы, используя типы StreamWriter и StreamReader, и теперь мы с вами можем рассмотреть роль классов StringWriter и StringReader.

Исходный код. Проект StreamWriterReaderApp размещен в подкаталоге, соответствующем главе 16.

 

Термин сериализация означает процесс переноса состояния объекта в поток, Соответствующая сохраненная последовательность данных содержит всю информацию, необходимую для реконструкции объекта, если в дальнейшем возникает необходимость в его использовании. С помощью такой технологии очень просто сохранять огромные объемы данных (в самых разных форматах). Во многих случаях сохранение данных приложения с помощью сервиса сериализации оказывается намного менее неуклюжим, чем прямое использование средств чтения/записи, предлагаемых в рамках пространства имен System.IO.

Предположим, например, что вы создали приложение с графическим интерфейсом и хотите обеспечить конечным пользователям возможность сохранить информацию об их предпочтениях. Для этого вы можете определить класс (например, с именем UserPrefs), инкапсулирующий, скажем, 20 полей данных. Если использовать тип System.IO.BinaryWriter, вам придется вручную сохранять каждое поле объекта UserPrefs. А когда вы захотите загрузить данные из соответствующего файла обратно в память, вам придется использовать System.IO.BinaryReader и (снова вручную) прочитать каждое значение, чтобы сконфигурировать новый объект UserPrefs.

Это, конечно, выполнимо, но вы можете сэкономить себе немало времени, просто указав для класса UserPrefs атрибут [Serializable]. В этом случае для сохранения полного состояния объекта достаточно будет нескольких строк программного кода.

static void Main(string[] args) {

 // Предполагаем, что для UserPrefs

 // указано [Serializable] .

 UserPrefs userData = new UserPrefs();

 userData.WindowColor = "Yellow";

 userData.FontSize = "50";

 userData.IsPowerUser = false;

 // Теперь сохраним объект в файле user.dat.

 BinaryFormatter binFormat = new BinaryFormatter();

 Stream fStream = new FileStream("user.dat", FileMode.Create, FileAccess.Write, FileShare.None);

 binFormat.Serialize(fStream, userData); fStream.Close();

 Console.ReadLine();

}

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

Как вы сможете убедиться позже, множество взаимосвязанных объектов можно представить в виде объектного графа. Сервис сериализации .NET позволяет сохранить и объектный граф, причем в самых разных форматах. В предыдущем примере программного кода использовался тип BinaryFormatter, поэтому состояние объекта UserPrefs сохранялось в компактном двоичном формате. Если использовать другие типы, то объектный граф можно сохранить в формате SOAP (Simple Object Access Protocol – простой протокол доступа к объектам) или в формате XML. Эти форматы могут быть полезны тогда, когда необходимо гарантировать, что ваши сохраненные объекты легко перенесут "путешествие" через операционные системы, языки и архитектуры.

Наконец, следует понимать, что объектный граф можно сохранить в любом производном от System.IO.Stream типе. В предыдущем примере объект UserPrefs сохранялся в локальном файле с помощью типа FileStream. Но если бы требовалось сохранить объект в памяти, следовало бы использовать тип MemoryStream. Это необходимо для того, чтобы последовательность данных корректно представляла состояния объектов соответствующего графа.

 

Роль объектных графов

Как уже упоминалось, при сериализации объекта среда CLR учитывает состояния всех связанных объектов. Множество связанных объектов представляется объектным графом. Объектные графы обеспечивают простой способ учета взаимных связей в множестве объектов, и не обязательно, чтобы эти связи в точности проецировались в классические связи объектно-ориентированного программирования (такие как отношения старшинства, и подчиненности), хотя они моделируют эту парадигму достаточно хорошо.

Каждому объекту в объектном графе назначается уникальное числовое значение. Следует иметь в виду, что эти числовые значения, приписываемые членам в объектном графе, произвольны и не имеют никакого смысла вне графа. После назначения всем объектам числового значения объектный граф может начать запись множества зависимостей каждого объекта.

Для примера предположим, что вы создали множество классов, моделирующих типы автомобилей (а что же еще?). Вы имеете базовый класс, названный Car (автомобиль), который "имеет" Radio (радио). Другой класс, JamesBondCar (автомобиль Джеймса Бонда), расширяет базовый тип Car. На рис. 17.1 показан возможный объектный граф, моделирующий указанные взаимосвязи.

Рис. 17.1 Простой объектный граф

При чтении объектных графов дли соединяющих стрелок вы можете использовать выражения "зависит от" и "ссылается на". Поэтому на рис. 17.1 вы можете видеть, что класс Car ссылается на класс Radio (в силу отношения локализации, "has-a"), а класс JamesBondCar ссылается на Car (в силу отношения подчиненности, "is-а") и на Radio (в силу того, что соответствующий защищенный член-переменная данным классом наследуется).

Конечно, для представления графа связанных объектов среда CLR картины в памяти не рисует. Вместо этого взаимосвязи, указанные в диаграмме, представляются математической формулой, которая выглядит примерно так.

[Car 3, ref 2], [Radio 2], [JamesBondCar 1, ref 3, ref 2]

Проанализировав эту формулу, вы снова увидите, что объект 3 (Car) имеет зависимость в отношения объекта 2 (Radio). Объект 2 (Radio) является "индивидуалистом", которому никто не требуется. Наконец, объект 1 (JamesBondCar) имеет зависимость в отношении как объекта 3, так и объекта 2. В любом случае, когда выполняется сериализация или реконструкция экземпляра JamesBondCar, объектный граф дает гарантию того, что типы Radio и Car тоже будут участвовать в процессе.

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

 

Чтобы сделать объект доступным сервису сериализации .NET, достаточно пометить каждый связанный класс атрибутом [Serializable]. И это все (правда!). Если вы решите, что некоторые члены данного класса не должны (или, возможно, не могут) участвовать в процессе сериализации, обозначьте соответствующие поля атрибутом [NonSerialized]. Это может быть полезно тогда, когда в классе, предназначенном для сериализации, есть члены-переменные, которые запоминать не нужно (например, фиксированные или случайные значения, динамические данные и т.п.), и вы хотите уменьшить размеры сохраняемого графа.

Для начала вот вам класс Radio, обозначенный атрибутом [Serializable], за исключением одной переменной (radioID), которая помечена атрибутом [NonSerialized], и поэтому не будет сохраняться в указанном потоке данных.

[Serializable]

public class Radio {

 public bool hasTweeters;

 public bool hasSubWoofers;

 public double[] stationPresets;

 [NonSerialized]

 public string radioID = "XF-552RR6";

}

Класс JamesBondCar и базовый класс Car, также обозначенные атрибутом [Serializable], определяют следующие поля данных.

[Serializable]

public class Car {

 public Radio theRadio = new Radio();

 public bool isHatchBack;

}

[Serializable]

public class JamesBondCar: Car {

 public bool canFly;

 public bool canSubmerge;

}

Следует знать о том, что атрибут [Serializable] не наследуется. Таким образом, если вы получаете класс из типа, обозначенного атрибутом [Serializable], дочерний класс тоже следует обозначить атрибутом [Serializable], иначе он при сериализации сохраняться не будет. На самом деле все объекты в объектном графе должны обозначаться атрибутом [Serializable]. При попытке с помощью BinaryFormatter или SoapFormatter выполнить сериализацию объекта. не подлежащего сериализации, в среде выполнения генерируется исключение SerializationException.

 

Открытые поля, приватные поля и открытые свойства

Заметим, что в указанных выше классах поля данных были определены открытыми только для того, чтобы упростить пример. Конечно, с точки зрения объектно-ориентированного подхода предпочтительнее использовать приватные данные, доступные через открытые свойства. Также для простоты не было определено никаких пользовательских конструкторов для этих типов, поэтому все их поля данных, не получившие начальных значений, получат значения, предусмотренные по умолчанию.

"Отодвинув" принципы объектно-ориентированного программирования в сторону, вы можете спросить, какие именно определения полей данных ожидают "видеть" различные средства форматирования, при отправке этих данных в поток. Ответ здесь зависит от многого. Если вы сохраняете объект с помощью BinaryFormatter, то определения не имеют абсолютно никакого значений. Этот тип предназначен дан сохранения всех предназначенных для сериализации полей типа, независимо от того, являются ли они общими полями, приватными полями или приватными полями, доступными через свойства типа. Однако ситуация оказывается совершенно иной, если вы используете тип XmlSerializer или тип SoapFormatter. Эти типы выполняют сериализацию только открытых полей данных и приватных данных, доступных через открытые свойства.

Напомним, однако, что если имеются поля данных, которые вы не хотите сохранять в объектном графе, вы можете селективно использовать для них атрибут [NonSerialized], как это сделано со строковым полем типа Radio.

 

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

• BinaryFormatter

• SoapFormatter

• XmlSerializer

Тип BinaryFormatter выполняет сериализацию объектного графа в поток, используя компактный двоичный формат. Этот тип определен в рамках пространства имен System.Runtime.Serialization.Formatters.Binary, являющегося частью mscorlib.dll. Таким образом, для сериализации объектов с использованием двоичного формата нужно только указать (в C#) следующую директиву using.

// Получение доступа к BinaryFormatter из mscorlib.dll .

using System.Runtime.Serialization.Formatter.Binary;

Тип SoapFormatter представляет граф в виде сообщения SOAP. Этот тип определен в пространстве имен System.Runtime.Serialization.Formatters.Soap, которое содержится в отдельном компоновочном блоке. Поэтому, чтобы представить объектный граф в формате сообщения SOAP, вы должны добавить ссылку на System.Runtime.Serialization.Formatters.Soap.dll и указать (в C#) следующую директиву using.

// Должна быть указана ссылка

// на System.Runtime.Serialization.Formatters.Soap.dll!

using System.Runtime.Serialization.Formatters.Soap;

Наконец, чтобы сохранить объектный граф в формате документа XML, нужно указать ссылку на пространство имен System.Xml.Serialization, которое также определено в отдельном компоновочном блоке – System.Xml.dll. Поскольку все шаблоны проектов в Visual Studio 2005 автоматически ссылаются на System.Xml.dll, вам нужно просто использовать следующее пространство имен.

// Определено в System.Xml.dll.

using System.Xml.Serialization;

 

Интерфейсы IFormatter и IRemotingFormatter

Независимо от того, какой формат вы выберете для использования, все они получаются прямо из System.Object и поэтому не могут иметь общего набора членов, наследуемого от какого-либо базового класса сериализации. Однако типы BinaryFormatter и SoapFormatter имеют общее множество членов по причине реализации интерфейсов IFormatter и IRemotingFormatter (тип XmlSerializer не реализует ни одного из них).

Интерфейс System.Runtime.Serialization.IFormatter определяет базовые методы Serialize() и Deserialize(), выполняющие основную работу по перемещению объектных графов в поток и из него. Кроме этих членов, IFormatter определяет несколько свойств, которые используются реализующим типом в фоновом режиме.

public interface IFormatter {

 SerializationBinder Binder { get; set; }

 StreamingContext Context { get; set; }

 ISurrogateSelector SurrogateSelector { get; set; }

 object Deserialize(System.IO.Stream serializationStream);

 void Serialize(System.IO.Stream serializationStream, object graph);

}

Интерфейс System.Runtime.Remoting.Messaging.IRemotingFormatter (который используется в .NET на уровне удаленного взаимодействия) предлагает перегруженные члены Serialize() и Deserialize(), более подходящие для использования в распределенных операциях. Заметьте, что IRemotingFormatter получается из более общего интерфейса IFormatter.

public interface IRemotingFormatter : IFormatter {

 object Deserialize(Stream serializationStream, HeaderHandler handler);

 void Serialize(Stream serializationStream, object graph, Header[] headers);

}

Хотя в большинстве операций сериализации вам, возможно, и не придется взаимодействовать с этими интерфейсами непосредственно, не забывайте о том, что интерфейсный полиморфизм дозволяет использовать экземпляр BinaryFormatter или SoapFormatter по ссылке на IFormatter. Таким образом, чтобы построить метод, выполняющий сериализацию объектного графа с помощью любого из этих классов, вы можете использовать следующий программный код.

static void SerializeObjectGraph (IFormatter itfFormat, Stream destStream, object graph) {

 itfFormat.Serialize(destStream, graph);

}

 

Выбор формата и точность типов

Очевидно, сутью различий указанных трех форматов является то, как именно объектный граф переводится в поток (в двоичном формате, формате SOAP или "чистом" XML). Но следует знать и о нескольких более "утонченных" различиях, особенно в отношении того, насколько различные форматы гарантируют точность типа. При использовании типа BinarуFormatter будут сохраняться не только поля данных объектов из объектного графа, но и абсолютное имя каждого типа, а также полное имя определяющего тип компоновочного блока. Эти дополнительные элементы данных делают BinaryFormatter идеальный выбором, когда вы хотите передать объекты по значению (например, как полную копию) за границы машины (см. главу 18). Как уже отмечалось, чтобы достичь такого уровня точности, BinaryFormatter учитывает все поля данных типа (как открытые, так и приватные).

Но SoapFormatter и XmlSerializer, с другой стороны, не пытаются сохранить тип абсолютно точно, поэтому они не записывают абсолютные имена типов и компоновочных блоков, а сохраняют только открытые поля данных и открытые свойства. На первый взгляд, это кажется ограничением, но реальная причина этого скрывается в открытой природе представления данных XML. Если вы хотите сохранить объектные графы так, чтобы они могли использоваться в любой операционной системе (Windows XP, ОС Маc X, различные вариации *nix), в рамках любого каркаса приложений (.NET. J2EE, COM и т.д.) и любом языке программирования, нет необходимости поддерживать абсолютную точность, поскольку у вас нет гарантии, что все возможные получатели смогут понять типы данных, специфичные для .NET. В этом случае идеальным выбором являются SoapFormatter и XmlSerializer, гарантирующие наиболее широкую доступность сохраненного объектного графа.

 

Чтобы показать, как сохранить экземпляр JamesBondCar в физическом файле, давайте используем тип BinaryFormatter. Подчеркнем снова, что двумя ключевыми методами типа BinaryFormatter являются Serialize() и Deserialize().

• Serialize(). Сохраняет объектный граф в указанном потоке в виде последовательности байтов.

• Deserialize(). Преобразует сохраненную последовательность байтов в объектный граф.

Предположим, что мы создали экземпляр JamesBondCar, изменили в нем некоторые данные и хотим сохранить этот "шпиономобиль" в файле *.dat. Первой нашей задачей является создание самого файла *.dat. Это можно сделать с помощью создания экземпляра типа System.IO.FileStream (см. главу 16). Создайте экземпляр BinaryFormatter и передайте ему FileStream и объектный граф для сохранения.

using System.Runtime.Serialization.Formatters.Binary; using System.IO;

 …

 static void Main (string[] args) {

 Console.WriteLine("*** Забавы с сериализацией объектов ***\n");

  // Создание JamesBondCar и установка данных состояния.

 JamesBondCar jbc = new JamesBondCar();

 jbc.canFly = true;

 jbc.canSubmerge = false;

 jbc.theRadio.statio.nPresets = new double[]{89.3, 105.1, 97.1};

 jbc.theRadio.hasTweeters = true;

 // Сохранение объекта в файл CarData.dat в двоичном формате.

 BinaryFormatter binFormat = new BinaryFormatter();

 Stream fStream = new FileStream("CarData.dat", FileMode.Create, FileAccess.Write, FileShare.None);

 binFormat.Serialize(fStream, jbc);

 fStream.Close();

 Console.ReadLine();

}

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

 

Реконструкция объектов с помощью BinaryFormatter

Теперь предположим, что вы хотите прочитать сохранённые данные JamesBondCar из двоичного файла назад в объектную переменную. Программно открыв CarData.dat (с помощью метода OpenRead()), вызовите метод Deserialize() объекта BinaryFormatter. Метод Deserialize() возвращает общий тип System.Object, поэтому вам придется выполнить явное преобразование, как показано ниже.

static void Main(string[] args) {

 …

 // Чтение JamesBondCar из двоичного файла.

 fStream = File.OpenRead("CarData.dat");

 JamesBondCar carFromDisk = (JamesBondCar)binFormat.Deserialize(fStream);

 Console.WriteLine("Может ли машина летать?: {0}", carFromDisk.canFly);

 fStream.Close();

 Console.ReadLine();

}

Обратите внимание на то, что при вызове Deserialize() методу передается производный от Stream тип, указывающий место хранения объектного графа (в данном случае это файловый поток). Так что проще уже некуда. По сути, сначала нужно обозначить атрибутом [Serializable] все классы, предназначенные для сохранения в потоке. После этого нужно использовать тип BinaryFormatter, чтобы передать объектный граф в двоичный поток и извлечь его оттуда. Вы можете увидеть двоичный образ, представляющий экземпляр JamesBondCar (рис. 17.2).

Рис. 17.2. Сериализация JamesBondCar с помощью BinaryFormatter

 

Вдобавок к SOAP и двоичному формату, компоновочный блок System.Xml.dll предлагает третий формат, обеспечиваемый типом System.Xml.Serialization. XmlSerializer который может использоваться для сохранения состояния данного объекта в виде "чистого" XML в противоположность данным XML, упакованным в сообщении SOAP. Работа с этим типом немного отличается от работы с типами SoapFormatter и BinaryFormatter. Рассмотрим следующий программный код.

using Sуstem.Xml.Serialization;

…

static void Main(string[] args) {

 …

  // Сохранение объекта в файл CarData.xml в формате XML.

 XmlSerializer xmlFormat = new XmlSerializer(typeof(JamesBondCar), new Type[] { typeof(Radio), typeof(Car) });

 fStream = new FileStream("CarData.xml", FileMode.Create, FileAccess.Write, FileShare.None);

 xmlFormat.Serialize(fStream, jbc);

 fStream.Close();

 …

}

Здесь главным отличием является то, что тип XmlSerializer требует указания информации о типе соответствующего элемента объектного графа. Обратите внимание на то, что первый аргумент конструктора XmlSerializer определяет корневой элемент XML-файла, а второй аргумент является массивом типов System.Type, содержащих метаданные подчиненных элементов. Если заглянуть в сгенерированный файл CarData.xml, вы увидите следующий XML-код (здесь он приводится в сокращенном виде).

‹?xml version="1.0" encoding="utf-8"?›

 ‹JamesBondCar xmlns:xsi="…"›

  ‹theRadio›

   ‹hasTweeters›true‹/hasTweeters›

   ‹hasSubWoofers›false‹/hasSubwoofers›

   ‹stationPresets›

    ‹double›89.3‹/double›

    ‹double›105.1‹/double›

    ‹double›97.1‹/double›

   ‹/stationPresets›

  ‹/theRadio›

  ‹isHatchBack›false‹/isHatchBack›

  ‹canFly›true‹/canFly›

  ‹canSubmerge›false‹/canSubmerge›

 ‹/JamesBondCar›

Замечание. Для XmlSerializer требуется, чтобы все типы в объектном графе, предназначенные для сериализации, поддерживали конструктор, заданный по умолчанию (так что не забудьте добавить его, если вы определили пользовательские конструкторы). Если это условие не будет выполнено, в среде выполнения будет сгенерировано исключение InvalidOperationException.

 

Контроль генерируемых XML-данных

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

По умолчанию все поля данных типа [Serializable] форматируются, как элементы, а не как XML-атрибуты. Для контроля того, как XmlSerializer компонует генерируемый XML-документ, следует указать для типов [Serializable] дополнительные атрибуты из пространства имен System.Xml.Serialization. В табл. 17.1 представлены некоторые из атрибутов, влияющих на кодирование XML-данных, передаваемых в поток.

Таблица 17.1. Атрибуты пространства имен System.Xml.Serialization, связанные с сериализацией объектов

Для примера давайте сначала выясним, как поля данных JamesBondCar сохраняются в XML-документе в настоящий момент.

‹?xml version="1.0" encodings="utf-8"?›

‹JamesBondCar xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd=http://www.w3.org/2001/XMLSchema›

 …

 ‹canFly›true‹/canFly›

 ‹canSubmerge›false ‹/ canSubmerge ›

‹ /JamesBondCar›

Если вы хотите указать пользовательское пространство имен XML, соответствующее JamesBondCar, и кодировать значения canFly и canSubmerge в виде XML-атрибутов, это можно сделать с помощью изменения определения JamesBondCar в C# следующим образом.

[ Serializablе , XmlRoot(Namespace = "http://www.intertechtraining.com")]

public class JamesBondCar: Car {

 …

 [XmlAttribute]

 public bool canFly;

  [XmlAttribute]

 public bool canSubmerge;

}

Это должно дать в результате следующий XML-документ (обратите внимание на открывающий элемент ‹JamesBondCar›).

‹?xml version="1.0" encodin="utf-8"?›

‹JamesBondCar xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" canFly="true" canSubmerge="false"

xmlns="http://www.intertechtraining.com"›

 …

‹/JamesBondCar›"

Конечно, есть множество других атрибутов, которые вы можете использовать для управления процессом генерирования XML-документа с помощью XmlSerializer. Чтобы ознакомиться со всеми опциями, выполните поиск информации о пространстве имен System.Xml.Serialization в документации .NET Framework 2.0 SDK

 

В большинстве случаев типовая схема сериализации, предлагаемая платформой .NET, будет именно тем, что требуется. Тогда нужно просто применить атрибут [Serializable] и передать объектный граф выбранному средству форматирования. Но в некоторых случаях может потребоваться корректировка того, как обрабатывается объектный граф в процессе сериализации. Например, в соответствии с внутренними правилами вашей компании все поля данных должны сохраняться в формате верхнего регистра или, возможно, вы хотите добавить в поток дополнительные элементы данных, которые не проецируются непосредственно в поля сохраняемого объекта (это могут быть штампы времени, уникальные имена или что-то иное).

Для непосредственного участия в управлении процессом сериализации объектов пространство имен System.Runtime.Serialization предлагает специальные типы. В табл. 17.2 описаны те из них, о которых вам следует знать.

Таблица 17.2. Основные типы пространства имен System.Runtime.Serialization

 

Более глубокий взгляд на сериализацию объектов

Перед тем как рассмотреть различные способы настройки параметров процесса сериализации, было бы полезно выяснить, что при этом происходит "за кулисами". Когда тип BinaryFormatter выполняет сериализацию объектного графа, этот тип отвечает за передачу в указанный поток следующей информации:

• абсолютных имен объектов графа (например, MyApp.JamesBondCar);

• имени компоновочного блока, определяющего объектный граф (например, MyApp.exe);

• экземпляра класса SerializationInfo, содержащего все данные, поддерживаемые членами объектного графа.

В процессе реконструкции объекта тип BinaryFormatter использует ту же информацию, извлеченную из соответствующего потока, для построения абсолютно точной копии объекта.

Замечание. Напомним, что SoapFormatter и XmlSerializer не сохраняют абсолютное имя типа и имя определяющего компоновочного блока. Эти типы заботятся только о сохранении открытых полей данных.

Общую картину можно представлять в виде диаграммы, показанной на рис. 17.3.

Рис. 17.3 Схема процесса сериализации

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

• Выясняется, обозначен ли объект атрибутом [Serializable]. Если нет, то генерируется исключение SerializationException.

• Если объект обозначен атрибутом [Serializable], то выясняется, реализует ли объект интерфейс ISerializable. Если да, то для объекта вызывается GetObjectData().

• Если объект не реализует ISerializable, используется типовой процесс сериализации, сохраняются все поля, не обозначенные атрибутом [NonSerialized].

Вдобавок к выявлению поддержки типом интерфейса ISerializable, форматтеры (в .NET 2.0) отвечают также за выявление поддержки соответствующими типами членов, обозначенных атрибутами [OnSerializing], [OnSerialized], [OnDeserializing] или [OnDeserialized]. Роль этих атрибутов будет обсуждаться позже, a пока что мы рассмотрим роль ISerializable.

 

Настройка параметров сериализации с помощью ISerializable

Объекты, обозначаемые атрибутом [Serializable], имеют возможность реализовать интерфейс ISerializable. В этом случае вы можете "участвовать" в процессе сериализации, выполняя любое предварительное или последующее форматирование данных. Указанный интерфейс очень прост, поскольку он определяет единственный метод, GetObjectData().

// Для настройки процесса сериализации реализуйте ISerializable.

public interface ISerializable {

 void GetObjectData(SerializationInfo info, StreamingContext context);

}

Метод GetObjectData() вызывается форматтером в процессе сериализации автоматически. Реализация этого метода предоставляет через входной параметр SerializationInfo серию пар имен и значений, которые (обычно) соответствуют полям данных того объекта, который следует сохранить. Тип SerializationInfo определяет перегруженный метод AddValue(), имеющий множество вариаций, а также небольшой набор свойств, которые позволяют читать и устанавливать имя типа, имя определяющего компоновочного блока и значение счетчика членов. Вот фрагмент соответствующего программного кода.

public sealed class SerializationInfo: object {

 public SerializationInfo(Type type, IFormatterConverter converter);

 public string AssemblyName { get; set; }

 public string FullTypeName { get; set; }

 public int MemberCount { get; }

 public void AddValue(string name, short value);

 public void AddValue(string name, UInt16 value);

 public void AddValue(string name, int value);

 …

}

Типы, реализующие интерфейс ISerializable, должны также определять специальный конструктор в соответствии со следующим шаблоном.

// Следует предложить пользовательский конструктор следующего вида,

// чтобы среда выполнения могла установить состояние вашего объекта.

[Serializable]

class SomeClass: ISerializable {

 private SomeClass(SerializationInfo si, StreamingContext ctx) {…}

 …

}

Обратите внимание на то, что для области видимости этого конструктора указано private. Это вполне допустимо, поскольку форматтер получает доступ к этому члену независимо от его видимости. Эти специальные конструкторы чаще всего обозначаются как приватные, чтобы обеспечить невозможность случайного создания объекта пользователем объекта с помощью такого конструктора. Заметьте, что первый параметр этого конструктора является (как и ранее) экземпляром типа SerializationInfo.

Второй параметр этого специального конструктора является типом StreamingContext, содержащим информацию об источнике или пункте назначения битов. Самым информативным членом этого типа является свойство State, которое представляет значение из перечня StreamingContextStates. Значения этого перечня соответствуют базовой композиции текущего потока.

Честно говоря, если вашей задачей разработки не является низкоуровневый пользовательский сервис удаленного доступа, вам вряд ли придется обращаться к указанному перечню непосредственно. Тем не менее, ниже приводятся имена элементов перечня StreamingContextStates (подробности его описания можно найти в документации .NET Framework 2.0 SDK).

public enum StreamingContextStates {

 Cro s sProcess,

 CrossMachine,

 File,

 Persistence,

 Remoting ,

 Other,

 Clone,

 CrossAppDomain,

 All

}

Чтобы иллюстрировать возможности настройки процесса сериализации с помощью ISerializable, предположим, что у нас есть тип класса, который определяет два элемента строковых данных. Кроме того, предположим, что все символы этих строк должны сохраняться в поток в верхнем регистре, а восстанавливаться из потока – в нижнем. Чтобы учесть эти требования, вы можете реализовать ISerializable так. как показано ниже (не забудьте указать using для пространства имен System.Runtime.Serialization).

[Seriаlizable]

class MyStringData: ISerializable {

 public string dataItemOne, dataItemTwo;

 public MyStringData() {}

 private MyStringData(SerializationInfo si, StreamingContext ctx) {

  // Регидратация члена из потока.

  dataItemOne = si.GetString(First_Item").ToLower();

  dataItemTwo = si.GetString("dataItemTwo").ToLower();

 }

 void ISerializable.GetObjectData(SerializatianInfo info, StreamingContext ctx) {

  // Наполнение объекта SerializationInfo

  // форматированными данными.

  info.AddValue("First_Item", dataItemOne.ToUpper());

  info.AddValue("dataItemTwo", dataItemTwo.ToUpper());

 }

}

Обратите внимание на то, что при "наполнении" типа SerializationInfo в методе GetObjectData() не требуется, чтобы элементы данных назывались одинаково с внутренними членами-переменными типа. Это может оказаться полезным тогда, когда нужно выделять данные из сохраненного формата. При этом не следует забывать о том, что для получения значений из приватного конструктора необходимо использовать имена, которые назначаются в рамках GetObjectData().

Чтобы проверить пользовательские настройки, предположим, что вы сохранили экземпляр MyStringData с помощью SoapFormatter. Заглянув в результирующий файл *.soap, вы увидите, что строковые поля в нем действительно представлены в верхнем регистре.

‹SOAP-ENV:Envelope xmlns:xsi="…"›

 ‹SOAP-ENV:Body›

  ‹a1:MyStringData id="ref-1" xmlns:a1="…"›

   ‹First_Item id="ref-3"› ЭTO НЕКОТОРЫЕ ДАННЫЕ. ‹/First_Item›

   ‹dataItemTwo id="ref-4"› ЭTO НЕКОТОРЫЕ ДОПОЛНИТЕЛЬНЫЕ ДАННЫЕ ‹/dataItemTwo›

  ‹/a1:MyStringData›

 ‹/SOAP-ENV:Body›

‹/SOAP-ENV:Envelope›

 

Настройка параметров сериализации с помощью атрибутов

Хотя реализация интерфейса ISerializable в .NET 2.0 все еще допустима, для настройки процесса сериализации теперь более предпочтительным считается определение методов, наделенных одним из целого ряда новых атрибутов, связанных с задачами сериализации (это атрибуты [OnSerializing], [OnSerialized], [OnDeserializing] и [OnDeserialized]). Использование этих атрибутов оказывается менее громоздким, чем реализация ISerializable, поскольку тогда не возникает необходимости вручную взаимодействовать с поступающим параметром SerializationInfo. Вместо этого вы получаете возможность непосредственно изменять данные состояния во время воздействия форматтера на тип.

При использовании этих атрибутов методы должны определяться так, чтобы они получали параметр StreamingContext и не возвращали ничего (в противном случае в среде выполнения генерируется соответствующее исключение). Обратите внимание на то, что не требуется учитывать все указанные атрибуты сериализации – можно учесть только те стадии сериализации, для которых следует выполнить перехват. Для примера рассмотрите новый тип [Serializable] с теми же требованиями, что и у MyStringData, но на этот раз с использованием атрибутов [OnSerializing] и [OnDeserialized].

[Serializable]

class MoreData {

 public string dataItemOne, dataItemTwo;

 [OnSerializing]

 internal void OnSerializing(StreamingContext context) {

  // Выполняется в процессе сериализации.

  dataItemOne = dataItemOne.ToUpper();

  dataItemTwo = dataItemTwo.ToUpper();

 }

 [OnDeserialized]

 internal void OnDeserialized(StreamingContext, context) {

  // Выполняется по завершении реконструкции объекта.

  dataItemOne = dataItemOne.ToLower();

  dataItemTwo = dataItemTwo.ToLower();

 }

}

Если выполнись сериализацию этого нового типа, вы снова обнаружите, что данные сохраняются в верхнем регистре, а воcстанавливаются – в нижнем.

Исходный код. Проект СustomSerialization размещен в подкаталоге, соответствующем главе 17.

 

Когда клиенты и серверы обмениваются информацией через границы приложений, среда CLR вынуждена использовать низкоуровневые примитивы, обеспечивающие настолько "прозрачное" взаимодействие сторон, насколько это возможно. Это значит, что вам, как программисту .NET, не нужно создавать огромные по объему блоки программного кода поддержки сетевого соединения, чтобы вызвать метод удаленного объекта. Также и серверному процессу не нужно "вручную" извлекать сетевой пакет из очереди и преобразовывать сообщение в формат, понятный удаленному объекту. Вы вправе ожидать, что среда CLR позаботится о таких деталях сама, используя свой стандартный набор примитивов удаленного взаимодействия (хотя, при желании, вы тоже можете принять участие в установке параметров соответствующего процесса).

В сущности, слой удаленного взаимодействия .NET обеспечивает аккуратную совместную работу следующих четырех ключевых элементов:

• агенты;

• сообщения;

• каналы;

• форматтеры.

Давайте рассмотрим каждый из указанных элементов по очереди и выясним, как их комбинация позволяет осуществлять удаленные вызовы методов.

 

Агенты и сообщения

Клиенты и объекты сервера взаимодействуют не напрямую, а через посредника, обычно называемого агентом (или proxy-модулем). Роль агента .NET заключается в создании для клиента иллюзии того, что он взаимодействует с запрошенным удаленным объектом в одном домене приложения. Чтобы создать такую иллюзию, агент предлагает интерфейс (члены, свойства, поля и т.д.), идентичный интерфейсу удаленного типа. С точки зрения клиента данный агент и является удаленным объектом. Однако "за кулисами" агент переправляет вызовы удаленному объекту.

Формально такой агент, вызываемый клиентом непосредственно, называется прозрачным агентом (transparent proxy). Этот объект, генерируемый средой CLR автоматически, несет ответственность за проверку того, что при вызове удаленного метода клиент получит нужное число параметров (и они будут нужного типа). Поэтому прозрачный агент можно интерпретировать, как фиксированный слой взаимодействия, который нельзя программно изменить или расширить.

В предположении о том, что прозрачный агент может выполнять проверку входных аргументов, соответствующая информация упаковывается в другой генерируемый средой CLR тип, который называется объектом сообщения. По определению все объекты сообщений реализуют интерфейс System.Runtime.Remoting.Messaging.IMessage.

public interface IMessage {

 IDictionary Properties { get; }

}

Как видите, интерфейс IMessage определяет единственное свойство (с именем Properties), которое обеспечивает доступ к коллекции, используемой для хранения предоставленных клиентом аргументов. После наполнения объекта сообщения содержимым средой CLR, он будет передан родственному типу, называемому реальным агентом (real proxy).

Реальный, агент – это сущность, которая фактически посылает объект сообщения в канал (понятие канала будет обсуждаться ниже). Реальный агент, который (в отличие от прозрачного агента) может быть расширен программистом, представляется базовым типом класса с именем RealProxy (что и следовало ожидать). Снова следует подчеркнуть, что среда CLR генерирует клиентскую реализацию реального агента для использования по умолчанию, которая вполне подойдет вам если не во всех, то в большинстве случаев. Но чтобы иметь представление о функциональных возможностях, предлагаемых абстрактным базовым классом RealProxy, изучите формальное определение этого типа.

public abstract class RealProxy: object {

 public virtual ObjRef CreateObjRef(Type requestedType);

 publiс virtual bool Equals(object obj);

 public virtual IntPtr GetCOMIUnknown(bool fIsMarshalled);

 public virtual int GetHashCode();

 public virtual void GetObjectData(SerializationInfo info, StreamingContext context);

 public Type GetProxiedType();

 public static object GetStubData(RеаlРrоxу rp);

 public virtual object GetTransparentProxy();

 public Type GetType();

 public IConstructionReturnMessage InitializeServerObject(IConstructionCallMessage ctorMsg);

 public virtual IMessage Invoke (IMessage msg);

 public virtual void SetCOMIUnknown(IntPtr i);

 public static void SetStubData(RealProxy rp, object stubData);

 public virtual IntPtr SupportsInterface(ref Guid iid);

 public virtual string ToString();

}

Если вы не заняты построением пользовательской реализации реального агента клиента, то единственным интересным для вас членом будет RealProxy.Invoke(). С помощью метода Invoke() сгенерированный средой CLR прозрачный агент в фоновом режиме передает форматированный объект сообщения типу RealProxy.

 

Каналы

После того как агенты проверят и отформатируют поставляемые клиентом аргументы, упаковав их в объект сообщении, соответствующий IMessage-совместимый тип передается от реального агента объекту канала. Каналы – это сущности, отвечающие за транспортировку сообщения удаленному объекту и, если это необходимо, за то, чтобы возвращаемое значение от удаленного объекта было доставлено обратно клиенту. В библиотеках базовых классов .NET 2.0 предлагаются готовые реализации трех каналов:

• TCP-канал;

• HTTP-канал;

• IPC-канал.

TCP-канал представляется типом класса TcpChannel и используется для передачи сообщений с использованием сетевого протокола TCP/IP. Класс TcpChannel удобен тем, что форматированные пакеты оказываются исключительно "легкими", поскольку сообщения превращаются в плотный двоичный формат с помощью BinaryFormatter (да, именно того BinaryFormatter, о котором шла речь в главе 17). При использовании типа TcpChannel удаленный доступ осуществляется быстрее. Недостатком является то, что TCP-каналы не согласуются с брандмауэром автоматически и могут требовать вмешательства сервисов администратора системы, чтобы получить разрешение на пересечение границы машины.

В противоположность этому, HTTP-канал, представляемый типом класса HttpChannel, преобразует объекты сообщений в формат SOAP, используя для этого соответствующий форматтер SOAP. Выше вы могли убедиться в том, что SOAP опирается на XML и поэтому результат в данном случае оказывается более объемным, чем в случае TcpChannel. Поэтому при использовании HttpChannel удаленный доступ может осуществляться медленнее. Но, с другой стороны, протокол HTTP является гораздо более дружественным в отношении брандмауэра, поскольку большинство сетевых экранов позволяет текстовым пакетам направляться через порт с номером 80.

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

Важно понимать, что вне зависимости от типа канала, который вы выберете для использования, и HttpChannel, и TcpChannel, и IpcChannel реализуют интерфейсы IChannel, IChannelSender и IChannelReceiver. Интерфейс IChannel (как вы вскоре убедитесь) определяет небольшой набор членов, обеспечивающих общую функциональность всех типов каналов. Роль IChannelSender заключается в определении для каналов общего множества членов, позволяющих отправлять информацию данному получателю. С другой стороны, IChannelReceiver определяет множество членов, позволяющих каналу получать информацию данного отправителя.

Чтобы позволить приложениям клиента и сервера зарегистрировать выбранный ими канал, вы должны использовать метод ChannelServices.RegisterChannel(), который получит тип, реализующий IChannel. Вот фрагмент программного кода, который показывает, как домен серверного приложения может зарегистрировать HTTP-канал, использующий порт 32469 (аналогичные возможности клиента будут продемонстрированы чуть позже).

// Создание и регистрация HttpChannel-сервера с портом 32469.

HttpChannel c = new HttpChannel(32469);

ChannelServices.RegisterChannel(с);

 

Снова о роли форматтера .NET

Заключительным элементом головоломки удаленного взаимодействия .NET является форматтер. Типы TcpChannel и HttpChannel используют свои внутренние форматтеры, задачей которых является перевод объекта сообщения в термины соответствующего протокола. Как уже говорилось, тип TcpChannel использует тип BinaryFormatter, в то время как тип HttpChannel использует функциональные возможности типа SoapFormatter. Опираясь на знания, полученные в предыдущей главе, вы должны понимать, как соответствующий канал форматирует поступающие сообщения.

После создания форматированного сообщения оно передается в канал, по которому в конце концов достигает целевого домена приложения. Там это сообщение преобразуется из специфических терминов протокола обратно в термины .NET, после чего элемент, который называется диспетчер, вызывает нужный метод удаленного объекта.

 

Общая картина

Если у вас от чтения предыдущих разделов уже голова идет кругом, не паникуйте! Прозрачный агент, реальный агент, объект сообщения и диспетчер вы можете, как правило, просто игнорировать, поскольку чаще всего вам вполне подойдут параметры удаленного взаимодействия, предлагаемые по умолчанию. Чтобы закрепить в памяти соответствующую последовательность событий, рассмотрите рис. 18.1, на котором показана схема процесса коммуникации двух объектов из разных доменов приложений.

Рис. 18.1. Архитектура удаленного взаимодействия .NET, предлагаемая по умолчанию

 

Несколько слов о расширении стандартных возможностей

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

Замечание. В этой главе тема расширения базового слоя удаленного взаимодействия .NET не обсуждается. Чтобы узнать, как это сделать, обратитесь к книге Ingo Rammer, Advanced .NET Remoting (Apress, 2002).

 

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

 

Варианты маршалинга для объектов: MBR и MBV

В рамках платформы .NET вы имеете на выбор два варианта того, как предоставить удаленный объект клиенту. Упрощенно говоря, маршалинг описывает правила передачи удаленного объекта из одного домена приложения в другой. При разработке объекта, предусматривающего удаленное использование, вы можете выбрать либо семантику MBR (marshal-by-reference – маршалинг по ссылке), либо семантику MBV (marshal-by-value – маршалинг по значению). Их различие заключается в следующем.

• MBR-объекты. Вызывающая сторона получает агента для осуществления доступа к удаленному объекту.

• MBV-объекты. Вызывающая сторона получает полную копию объекта для использования в своем домене приложения.

При использовании типа, относящегося к MBR-объектам, среда CLR обеспечит создание в домене приложения клиента прозрачного и реального агентов, в то время как сам MBR-объект будет оставаться в домене приложения сервера. При вызове методов удаленного типа клиентом система удаленного взаимодействия .NET (схема которой описана выше) активизируется, чтобы выполнить задачи упаковки, отправки и получения информации при обмене данными через границы доменов приложений. Для этого MBR-объекты имеют ряд свойств, "простирающихся" за рамки их физического расположения. Вы увидите, что MBR-объекты имеют различные опции конфигурации, относящиеся к их активизации и управлению циклом существования. В противоположность этому, MBV-объекты представляют собой локальные копии удалённых объектов (использующие протокол сериализации .NET, который был рассмотрен в главе 17). MBV-объекты имеют намного меньше опций конфигурации, поскольку их цикл существования контролируется непосредственно клиентом. Подобно любому другому объекту .NET, после того как клиент освободит все ссылки на MBV-тип, этот тип становится потенциальным объектом внимания для сборщика мусора. Поскольку MBV-типы являются локальными копиями удаленных объектов, процесс вызова клиентом членов соответствующего типа, вообще говоря, не предполагает никакой сетевой активности.

Следует понимать, что вполне естественным для сервера является поддержка доступа к множеству MBR- и MBV-типов. Вы можете также догадаться, что MBR-типы обычно поддерживают методы, возвращающие различные MBV-типы, что, в общем-то, напоминает автоматизированное предприятие, где один объект создает и выпускает другие связанные объекты. Здесь возникает следующий вопрос: как сконфигурировать пользовательский тип класса для использования в виде MBR-или MBV-объекта?

Конфигурация MBV-объекта

Процесс конфигураций объекта для использования в виде MBV-типа абсолютно аналогичен процессу конфигурации объекта для сериализации. Просто объявите соответствующий тип с атрибутом [Serializable].

[Serializable]

public class SportsCar {…}

Конфигурация MBR-объекта

MBR-объекты не маркируются специальным атрибутом .NET, а получаются (явно или неявно) из базового класса System.MarshalByRefObject.

public class SportsCarFactory: MarshalByRefObject {…}

Формально тип MarshalByRefObject определяется следующим образом.

public abstract class MarshalByRefObject: object {

 public virtual ObjRef CreateObjRef(Type requestedType);

 public virtual bool Equals(object obj);

 public virtual int GetHashCode();

 public virtual object GetLifetimeService();

 public Type GetType();

 public virtual object InitializeLifetimeService();

 public virtual string ToString();

}

Функциональные возможности, наследуемые от System.Object, вполне понятны, а роль остальных членов описана в табл. 18.2.

Таблица 18.2. Основные члены System.MarshalByRefObject

Можно сказать, что суть типа MarshalByRefObject заключается в определении членов, которые затем могут переопределяться для того, чтобы программно управлять циклом существования MBR-объекта (подробнее об управлении циклом существования объектов будет говориться в этой главе позже).

Замечание. То, что вы сконфигурировали тип в виде MBV- или MBR-объекта, совсем не означает, что этот объект следует использовать только в приложении удаленного взаимодействия, а означает только то, что этот объект можно использовать в таком приложении. Например, тип System.Windows.Forms.Form является потомком MarshalByRefObject. Поэтому при удаленном доступе он реализуется как MBR-тип, а в других случаях он будет обычным локальным объектом в домене приложения клиента.

Замечание. Как следствие предыдущего замечания обратим внимание на то, что если тип .NET не предполагает сериализацию и в его цепочке наследования нет MarshalByRefObject, то такой тип может активизироваться и использоваться только в его исходном домене приложения, т.е, такой тип является контекстно-связанным (см. главу 13).

Теперь, когда вы четко понимаете суть различий между MBR- и MBV-типами, давайте рассмотрим некоторые проблемы, специфичные для MBR-типов (к MBV-типам это не относится).

 

Варианты активизации для MBR-типа: WKO и CAO

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

Причина такого, казалось бы. странного поведение связана с оптимизацией. Точнее, каждый MBR-тип можно настроить на активизацию с использованием одного из двух следующих подходов:

• как общеизвестный объект (Well-Known Object – WKO);

• как объект, активируемый клиентом (Client Activated Object – CAO).

Замечание. Потенциальным источником недоразумений здесь является то, что в литературе, посвященной .NET, вместо акронима WKO также используют SAO (Server Activated Object – объект, активизируемый сервером). Акроним SAO встречается в целом ряде статей и книг, связанных с .NET. В этой главе, в соответствии с современной терминологией, будет использоваться аббревиатура WKO.

WKO-объекты – это MBR-типы, цикл существования которых подконтролен непосредственно домену приложения сервера. Приложение клиента активизирует удаленный тип, используя понятное общеизвестное строковое имя (отсюда и возник термин WKO). Домен приложения сервера размещает WKO-типы тогда, когда клиент выполняет первый вызов метода данного объекта (через прозрачный агент), а не тогда, когда программный код клиента использует ключевое слово new или когда вызов происходит через статический метод Activator.GetObject(), например:

// Получение агента для удаленного объекта.

// Эта строка не приводит к немедленному создании WKO-типа!

object remoteObj = Activator.GetObject(/* параметры… */);

// Вызов метода удаленного WKO-типа. Это приводит к созданию

// WKO-объекта и вызову метода ReturnMessage ().

RemoteMessageObject simple = (RemoteMessageObject)remoteObj;

Console. WriteLine("Сервер отвечает: {0}", simple.ReturnMуssage());

В чем здесь здравый смысл? При таком подходе простое предложение создать объект не ведет к немедленному пику сетевого обмена данными. Другим следствием является то, что WKO-типы могут создаваться только с помощью конструктора, заданного по умолчанию. Это разумно, поскольку конструктор удаленного типа используется только тогда, когда клиент выполняет вызов члена. Так что среда выполнения не имеет никакого иного варианта выбора, кроме вызова конструктора, заданного типом по умолчанию.

Замечание. Всегда помните о том, что любой WKD-тип должен иметь конструктор, заданный по умолчанию!

Если вы хотите разрешить клиенту создавать удаленные MBR-объекты с помощью пользовательского конструктора, сервер должен сконфигурировать соответствующий объект, как САО-объект. Цикл существования САО-объектов контролируется доменом приложения клиента. При доступе к САО-типу соответствующий обмен данными с сервером происходит уже при использовании клиентом ключевого слова new (с любым конструктором типа) или типа Activator.

 

Варианты конфигурации WKO-типа: синглеты и объекты одиночного вызова

Наконец, еще одна проблема выбора для MBR-типов в проекте .NET связана с тем, как сервер должен обрабатывать множественные обращения к WKO-типу. С САО-типами эта проблема не возникает, поскольку для них всегда есть однозначное соответствие между клиентом и удаленным САО-типом (эти типы являются объектами, кумулятивно изменяющими параметры своего состояния в процессе выполнения вызовов клиентов).

Одним из вариантов является конфигурация WKO-типа в виде синглета. В этом случае среда CLR создаст один экземпляр удаленного типа, который будет принимать запросы любого числа клиентов. Этот вариант оказывается естественным тогда, когда нужно поддерживать состояние типа, одинаковое для всех абонентов, выполняющих удаленные вызовы. Множество клиентов могут вызывать один и тот же метод в одно и то же время, поэтому среда CLR помещает каждый вызов клиента в новый поток. Однако обеспечение гарантий того, что ваши объекты будут реентерабельны, является вашей обязанностью, и для этого следует использовать подходы, описанные в главе 14,

В противоположность синглету, объект одиночного вызова - это WKO-тип, существующий только в контексте вызова отдельного метода. Поэтому, например, если WKO-тип, сконфигурированный с учетом семантики одиночного вызова, используется 20 клиентами, то сервер создаст 20 отдельных объектов (по одному для каждого клиента), и все эти объекты станут кандидатами для участия в процессе сборки мусора сразу же после завершения вызова метода. Как вы можете догадаться, объекты одиночного вызова, будучи объектами, не меняющими своего состояния, поддаются масштабированию лучше, чем синглеты.

Задача определения конфигурации состояния WKO-типа возлагается на сервер. Программно указанные варианты задаются с помощью перечня System.Runtime.Remoting.WellKnownObjectMode.

public enum WellKnownObjectMode {

 SingleCall,

 Singleton

}

 

Сводная характеристика MBR-объектов

Вы имели возможность убедиться в том, что для конфигурации MBV-объек-тов долгих размышлений не потребуется: нужно просто применить атрибут [Serializable], чтобы позволить отправку копий соответствующего типа в домен приложения клиента. С этого момента все взаимодействие с MBV-типом происходит в локальном окружении клиента. Когда клиент завершит использование соответствующего MBV-типа, этот тип становится объектом внимания сборщика мусора, и никаких проблем не возникает.

Но для MBR-типов имеется целый ряд вариантов конфигурации. Вы видели, что MBR-тип допускает варианты конфигурации в отношении его времени активизации, состояния и управления циклом существования. Чтобы представить весь набор имеющихся возможностей, в табл. 18.3 показано, как WKO и САО-объекты соотносятся с вариантами поведения, которые только что были нами рассмотрены.

Таблица 18.3. Опции конфигурации для MBR-типов 

 

Ничто не принесет большей радости, чем создание реального распределенного приложения на новой платформе. Чтобы показать, как быстро можно создать и запустить приложение, использующее слой удаленного взаимодействия .NET, мы построим простой пример такого приложения. Выше уже отмечалось, что такое приложение должно состоять из трех компоновочных блоков .NET:

• общий компоновочный блок с именем SimpleRemotingAsm.dll;

• компоновочный блок клиента с именем SimpleRemoteObjectClient.exe;

• компоновочный блок сервера с именем SimpleRemoteObjectServer.exe.

 

Создание общего компоновочного блока

Сначала создадим общий компоновочный блок, SimpleRemotingAsm.dll, на который будут ссылаться как сервер, так и клиент. В SimpleRemotingAsm.dll определяется единственный MBR-тип с именем RemoteMessageObject, который поддерживает два открытых члена. Метод DisplayMessage() выводит в окно консоли сервера поставляемое клиентом сообщение, a ReturnMessage() возвращает некоторое сообщение клиенту. Вот полный программный код этой новой библиотеки классов C#.

namespace SimpleRemotingAsm {

 // Для этого типа при удаленном доступе

 // будет иcпользоваться маршалинг до ссылке (MBR).

 public class RemoteMessageObject: MarshalByRefObject {

  public RemoteMessageObject() { Console.WriteLine("Создание RemoteMessageObject!"); }

  // Этот метод получает входную строку

  // от вызывающей стороны.

  public void DisplayMessage(string msg) { Console.WriteLine("Сообщение: {0}", msg); }

  // Этот метод возвращает значение вызывающей стороне.

  public string ReturnMessage() { return "Привет от сервера!"; }

 }

}

Наиболее интересным здесь является то, что соответствующий тип получается из базового класса System.MarshalByRefObject, в результате чего полученный класс будет гарантированно доступным с помощью агента на стороне клиента. Также обратите внимание на пользовательский вариант конструктора, заданного по умолчанию, который печатает сообщение при создании экземпляра типа. Вот и все. Теперь можете создать новый компоновочный блок SimpleRemotingAsm.dll на базе этого программного кода.

 

Создание компоновочного блока сервера

Напомним, что компоновочные блоки сервера обслуживают, в частности, и общие компоновочные блоки, содержащие объекты удаленного доступа. Создайте консольную программу с именем SimpleRemoteObjectServer. Роль серверного компоновочного блока заключается в том, чтобы открыть канал для поступающих запросов и зарегистрировать RemoteMessageObjесt, как WKO-объект. Сначала сошлитесь на компоновочные блоки System.Runtime.Remoting.dll и SimpleRemotingAsm.dll и обновите Main() так, как предлагается ниже.

using System;

using System.Runtime.Remoting;

using System.Runtime.Remoting.Channels;

using System.Runtime.Remoting.Channels.Http;

using SimpleRemotingAsm;

namespace SimpleRemoteObjectServer {

 class SimpleObjServer {

  static void Main(string[] args) {

   Console.WriteLine("*** Начало работы SimpleRemoteObjectServer! ***");

   Console.WriteLine("Для завершения нажмите ‹Enter›");

   // Регистрация нового HttpChannel

   HttpChannel с = new HttpChannel(32469);

   ChannelServices.RegisterChannel(c);

   // Регистрация WKO-типа с активацией синглета.

   RemotingConfiguration.RegisterWellKnownServiceType(typeof(SimpleRemotingAsm.RemoteMessageObject), "RemoteMsgObj.soap", WellKnownObjectMode.Singleton);

   Console.ReadLine();

  }

 }

}

Метод Main() начинается c создания нового типа HttpChannel, для которого указан произвольный идентификатор порта. Этот порт открывается путем регистрации канала с помощью статического метода ChannelServices.RegisterChannel(). После регистрации канала компоновочный блок удаленного сервера может обрабатывать сообщения, поступающие через порт с номером 32469.

Замечание. Номер, который вы назначите порту, как правило, выбираете вы сами (или ваш системный администратор). При этом, однако, следует учитывать то, что порты с номерами ниже 1024 резервируются для использования системой.

Затем, чтобы зарегистрировать тип SimpleRemotingAsm.RemoteMessageObject в качестве WKO-типа, используется метод RemotingConfiguration.RegisterWellKnownServiceType(). Первым аргументом этого метода является информация типа для регистрируемого типа. Вторым параметром RegisterWellKnownServiceТуре() является произвольная выбранная вами строка, которая будет использоваться для идентификации регистрируемого объекта при обмене данными между доменами приложений. Здесь вы информируете среду CLR о том, что данный объект должен распознаваться клиентом по имени RemoteMsgObj.soap.

Заключительным параметром является член перечня WellKnownObjectMode, и для него здесь указано WellKnownObjectMode.Singleton. Напомним, что при использовании WKO-синглета все поступающие запросы обслуживаются одним экземпляром RemoteMessageObject. Создайте компоновочный блок сервера и переходите к созданию программного кода клиента.

 

Создание компоновочного блока клиента

Теперь, когда у вас есть приемник, который будет обслуживать объекты уда-ленного доступа, остается создать компоновочный блок, который запросит доступ к соответствующим возможностям. Здесь снова создайте простое консольное приложение. Установите ссылку на System.Runtime.Remoting.dll и SimpleRemotingAsm.dll. Реализуйте Main() так, как показано ниже.

using System;

using System.Runtime.Remoting;

using System.Runtime.Remoting.Channels;

using System.Runtime.Remoting.Channels.Http;

using SimpleRemotingAsm;

namespace SimpleRemoteObjectClient {

 class SimpleObjClient {

  static void Main(string[] args) {

   Console.WriteLine("*** Начало работы SimpleRemoteObjectClient! ***");

   Console.WriteLine("Для завершения нажмите ‹Enter›");

   // Создание нового HttpChannel.

   HttpChannel с = new HttpChannel();

   ChannelServices.RegisterChannel(c);

   // Получение агента для удаленного доступа к WKO-типу.

   object remoteObj = Activator.GetObject(typeof(SimpleRemotingAsm.RemoteMessageObject), "http://localhost:32469/RemoteMsgObj.soap");

   // Использование удаленного объекта.

   RemoteMessageObject simple = (RemoteMessageObject)remoteObj;

   simple.DisplayMessage("Привет от клиента!");

   Console.WriteLine("Сервер говорит: {0}", simple.ReturnMessage());

   Console.ReadLine();

  }

 }

}

В этом приложении клиента обратите внимание на следующее. Во-первых, клиент также должен зарегистрировать HTTP-канал, но идентификатор порта при этом не указывается, поскольку конечная точка канала задается адресом URL активизации, поставляемым клиентом. Поскольку клиент взаимодействует с WKO-типом, вы должны активизировать конструктор типа, заданный по умолчанию. С этой целью вызывается метод Activator.GetObject() с двумя параметрами. Первым параметром является информация типа удаленного объекта, с которым вы хотите взаимодействовать. Прочитайте последнее предложение еще раз. Поскольку здесь метод Activator.GetObject() требует метаданные описания объекта, становится ясно, почему для клиента также требуется ссылка на общий компоновочный блок! В конце главы будут рассмотрены различные возможности совершенствования поведения компоновочного блока клиента в этом отношении.

Второй параметр метода Activator.GetObject() представляет собой URL активизации. Значение URL активизации, описывающее WKO-тип, можно представить в следующем обобщенном формате.

СхемаПротокола://ИмяКомпьютера:Порт/UriОбъекта

Наконец, заметим, что метод Activator.GetObject() возвращает общий тип System.Object, поэтому для получения доступа к членам RemoteMessageObject необходимо использовать явное преобразование типа.

 

Тестирование приложения, использующего удаленное взаимодействие

При тестировании приложения начните с запуска серверного приложения, которое откроет HTTP-канал и зарегистрирует объект RemoteMessageObject для удаленного доступа. Затем запустите экземпляр приложения клиента. Если все пройдет хорошо, окно вашего сервера должно иметь вид, показанный на рис. 18.2, а приложение клиента должно отображать то, что вы видите на рис. 18.3.

Рис. 18.2. Вывод сервера

Рис. 18.3. Вывод клиента

 

Итак, вы успешно построили распределённое приложение, используя слой удаленного взаимодействия .NET. В связи c данными примерами следует обратить внимание на то что полученные приложения клиента и сервера содержат большой объем "жестко" кодируемой программной логики. Например, сервер указывает фиксированный идентификатор порта, фиксированный режим активизации и фиксированный тип канала. Клиент, с другой стороны, "жестко" кодирует имя удаленного объекта, с которым пытается взаимодействовать.

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

Вспомните из главы 11 о том, что файл *.config можно использовать для "подсказок" среде CLR в отношений места нахождения внешних компоновочных блоков, необходимых для работы приложения. Эти же файлы *.config могут использоваться и для информирования CLR о целом ряде параметров удаленного взаимодействия, как на стороне клиента, так и на стороне сервера.

При создании файла *.config для указания различных параметров удаленного взаимодействия используют элемент ‹system.runtime.remoting›. Если у вашего приложения уже есть файл *.config, в котором указаны параметры размещения компоновочного блока, вы можете добавить элементы удаленного взаимодействия в этот же файл. Единый файл *.config, содержащий и настройки удаленного взаимодействия, и информацию привязки, должен выглядеть примерно так.

‹configuration›

 ‹sуstem.runtime.remoting›

  ‹!-- параметры удаленного взаимодействия клиента и сервера --›

 ‹/system.runtime.remoting ›

 ‹ runtime›

   ‹!-- информация привязки компоновочного блока --›

 ‹/runtime ›

‹ /configuration›

Если вам нечего указать в отношении привязки компоновочного блока, вы можете опустить соответствующий элемент ‹runtime› и использовать в файле *.config шаблон следующего вида.

‹configuration›

 ‹ system.runtime.remoting›

   ‹!-- параметры удаленного взаимодействия клиента и сервера --›

 ‹/system.runtime.remoting›

‹/configuration›

 

Создание файлов *.config сервера

Файлы конфигурации на стороне сервера позволяют объявить объекты, которые будут доступны для удаленных вызовов, а также задать параметры канала и порта. Рассмотрим следующий вариант программной логики сервера.

// "Жестко" заданная программная логика сервера HTTP.

HttpChannel с = new HttpChannel(32469);

ChannelServices.RegisterChannel(с);

RemotingConfiguration.RegisterWellKnownServiceType(typeof(SimpleRemotingAsm.RemoteMessageObject), "RemoteMsgObj.soap", WellKnownObjectMode.Singleton);

Используя элементы ‹service›, ‹wellknown› и ‹channels›, эту программную логику можно заменить следующим файлом *.config.

‹configuration›

 ‹system.runtime.remoting›

  ‹application›

   ‹service›

    ‹wellknown mode="Singleton" type="SimpleRemotingAsm.RemoteMessageObject, SimpleRemotingAsm" objectUri="RemoteMsgObj.soap"/›

   ‹/service›

   ‹channels›

    ‹channelref="http"/›

   ‹/channels›

  ‹/application›

 ‹/system.runtime.remoting›

‹/configuration›

Обратите внимание на то, что значительная часть информации удаленного сервера указывается в контексте элемента ‹service› (не сервер!). Его дочерний элемент ‹wellknown› использует три атрибута (mode, type и objectUri) для регистрации WKO-объекта в слое удаленного взаимодействия .NET. Элемент ‹channels› может содержать любое число элементов ‹channel›, которые позволяют определить вид канала (в данном случае это HTTP), открываемого на сервере. Для ТСР-каналов вместо http нужно просто использовать лексему tcp.

Поскольку в этом случае вся необходимая информация содержится в файле SimpleRemoteObjectServer.exe.config, метод Main() серверной стороны значительно упрощается. В нем остается выполнить только вызов RemotingConfiguration.Configure() и указать имя соответствующего файла конфигурации.

static void Main(string[] args) {

 // Регистрация WKO-объекта с помощью файла *.config.

 RemotingConfiguration.Configure("SimpleRemoteObjectServer.exe.config");

 Console.WriteLine("Старт сервера! Для остановки нажмите ‹Enter›");

 Console.ReadLine();

}

 

Создание файлов *.config клиента

Клиенты тоже могут использовать файлы *.config удаленного взаимодействия. В отличие от файлов конфигурации сервера, в файлах конфигурации клиента для идентификации имени WKO-объекта используется элемент ‹client›. Вдобавок к возможности динамического изменения параметров удаленного взаимодействия без перекомпиляции базового программного кода, файлы *.config клиента позволяют создать тип агента непосредственно с помощью ключевого слова C# new, не используя метод Activator.GetObject(). Предположим, например, что у нас есть файл *.config клиента со следующим содержимым.

‹configuration›

 ‹system.runtime.remoting›

  ‹application›

   ‹client displayName = "SimpleRemoteObjectClient"›

    ‹wellknown type=" SimpleRemotingAsm.RemoteMessageObject, SimpleRemotingAsm" url="http://localhost:32469/RemoteMsgObj.soap"/›

   ‹/client›

   ‹channels›

    ‹channel ref="http"/›

   ‹/channels›

  ‹/application›

 ‹/system.runtime.remoting›

‹/configuration›

Тогда можно изменить метод Main() клиента так.

statiс void Main(string[] args) {

 RemotingConfiguration.Configure("SimpleRemoteObjectClient.exe.config");

 // При использовании файла *.config клиент может создать тип

 // непосредственно с помощью ключевого слова 'new' .

 RemoteMessageObject simple = new RemoteMessageObject();

 simple.DisplayMessage("Привет от клиента!");

 Console.WriteLine("Сервер говорит: {0}", simple.ReturnMessage());

 Console.WriteLine("Старт клиента! Для остановки нажмите ‹Enter›");

 Console.ReadLine();

}

При выполнении этого варианта приложения вывод оказывается аналогичным исходному. Если клиент пожелает использовать TCP-канал, то для свойств url элемента ‹wellknown› и ref элемента ‹сhannel› следует вместо http указывать tcp.

Исходный код. Проекты SimpleRemoteObjectServerWithConfig и SimpleRemoteObjectClientWithConfig размещены в подкаталоге, соответствующем главе 18 (оба эти проекта используют созданный выше компоновочный блок SimpleRemotingAsm.dll).

 

Наши первые приложения удаленного взаимодействия позволяли доступ клиентов к одному WKO-типу. Напомним, что WKO-типы (по определению) являются MBR-типами, поэтому доступ клиента к ним осуществляется через агента-посредника. В противоположность этому, MBV-типы являются локальными копиями серверного объекта, обычно возвращаемыми открытыми членами некоторого MBR-типа. Вы уже знаете, как настроить MBV-тип (следует обозначить соответствующий класс атрибутом [Serializable]), но MBV-тип в действии вы еще не видели (если не считать обмена строковыми данными между двумя сторонами). Для иллюстрации взаимодействия MBR- и MBV-типов мы рассмотрим новый пример, в котором используются следующие три компоновочных блока.

• Общий компоновочный блок CarGeneralAsm.dll

• Компоновочный блок клиента CarProviderClient.exe

• Компоновочный блок сервера CarProviderServer.exe

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

 

Создание общего компоновочного блока

В ходе нашего обсуждения процесса сериализации объектов в главе 17 мы создали тип JamesBondCar (в дополнение к связанным классам Radio и Car). Библиотека программного кода CarGeneralAsm.dll будет использовать эти типы, поэтому сначала выберите Projects→Add Existing Item из меню и добавьте в свой новый проект библиотеки классов соответствующие файлы *.cs (автоматически созданный файл Class1.cs можете удалить), Поскольку каждый из добавленных типов уже обозначен атрибутом [Serializable], они готовы для маршалинга по значению в отношении удаленного клиента.

Теперь нам нужен MBR-тип, который обеспечит доступ к типу JamesBondCar. Чтобы сделать ситуацию немного более интересной, ваш MBR-объект (CarProvider) будет поддерживать обобщенный список List‹› типов JamesBondCar. Тип CarProvider определит два члена, которые позволят вызывающей стороне получить заданный тип JamesBondCar, а также полный перечень List‹› соответствующих типов. Вот весь программный код для нового типа класса.

namespace CarGeneralAsm {

 // Этот тип является MBR-объектом, обеспечивающим доступ

 // к соответствующим MBV-типам.

 public class CarProvider: MarshalByRefObject {

  private List‹JamesBondCar› theJBCars = new List‹JamesBondCar›();

  // Добавление в список нескольких машин.

  public CarProvider() {

   Console.WriteLine("Создание поставщика машин");

   theJBCars.Add(new JamesBondCar("QMobile", 140, true, true"));

   theJBCars.Add(new JamesBondCar("Flyer", 140, true, false));

   theJBCars.Add(new JamesBondCar("Swimmer", 140, false, true));

   theJBCars.Add(new JamesBondCar("BasicJBC", 140, false, false));

  }

  // Получение всех JamesBondCar.

  public List‹JamesBondCar› GetAllAutos() { return theJBCars; }

  // Получение одного JamesBondCar,

  public JamesBondCar GetJBCByIndex(int i) { return (JamesBondCar)theJBCars[i]; }

 }

}

Обратите внимание на то, что метод GetAllAutos() возвращает внутренний тип List‹›. Очевидный вопрос: как данный член пространства имен System. Collections.Generic представляется вызывающей стороне? Если посмотреть описание этого типа в документации .NET Framework 2.0 SDK, вы обнаружите, что list‹› сопровождается атрибутом [Serializable].

[SerializableAttribute()]

public class List‹T›: IList, ICollection, IEnumerable

Таким образом, для всего содержимого типа List‹› будет использован маршалинг по значению (если содержащиеся в нем типы также допускают сериализацию). Это очень удобная особенность удаленного взаимодействия .NET и членов библиотек базовых классов. Вдобавок к пользовательским MBV- и MBR-типам, которые вы можете создать сами, любой тип из библиотек базовых классов, сопровождающийся атрибутом [Serializable], также способен выступать в качестве MBV-типа в архитектуре удаленного взаимодействия .NET. Аналогично, любой тип, получающийся (непосредственно или косвенно) из MarshalByRefObject, может функционировать, как MBR-тип.

Замечание. Следует знать о том, что SoapFormatter не поддерживает сериализацию обобщенных типов. При создании методов, получающих или возвращающих обобщенные типы (напри-мер, List‹›), вы должны использовать BinaryFormatter и объект TcpChannel.

 

Создание компоновочного блока сервера

Компоновочный блок сервера (CarProviderServer.exe) в рамках метода Main() содержит следующую программную логику.

using System;

using System.Runtime.Remoting;

using System.Runtime.Remoting.Channels;

using System.Runtime.Remoting.Channels.Http;

using CarGeneralAsm;

namespace CarProviderServer {

 class CarServer {

  static void Main(string[] args) {

   RemotingConfiguration.Configure("CarProviderServer.exe.config");

   Console.WriteLine("Старт сервера! Для остановки нажмите ‹Enter›");

   Console.ReadLine();

  }

 }

}

Соответствующий файл *.config почти идентичен файлу *.config сервера, созданному в предыдущем примере. Единственным заслуживающим внимания моментом здесь является определение значения URI объекта для типа CarProvider.

‹configuration›

 ‹system.runtime.remoting›

  ‹application›

   ‹service›

    ‹wellknown mode="Singleton" type="CarGeneralAsm.CarProvider, CarGeneralAsm" objectUri="carprovider.rem" /›

   ‹/service›

   ‹channels›

    ‹channel ref="tcp" port="32469" /›

   ‹/channels›

  ‹/application›

 ‹/system.runtime.remoting›

‹/configuration›

 

Создание компоновочного блока клиента

Наконец, рассмотрим приложение клиента, которое будет использовать MBR-тип CarProvider для получения отдельных типов JamesBondCars и типа List‹›. После получения типа от CarProvider вы посылаете его вспомогательной функции UseCar() для обработки.

using System;

using System.Runtime.Remoting;

using System.Runtime.Remoting.Channels;

using System.Runtime.Remoting.Channels.Http;

using CarGeneralAsm;

using System.Collections.Generic;

namespace CarProviderClient {

 class CarClient {

  private static void UseCar(JamesBondCar c) {

   Console.WriteLine("-› Имя: {0}", с.PetName);

   Console.WriteLine("-› Макc. скорость: {0} ", с.MaxSpeed);

   Console.WriteLine("-› Способность плавать: {0}", с.isSeaWorthy);

   Console.WriteLine("-› Способность летать: {0}, c.isFlightWorthy);

   Console.WriteLine();

  }

  static void Main(string[] args) {

   RemotingConfiguration.Configure("CarProviderClient.exe.config");

    // Создание поставщика машин.

   CarProvider cр = new CarProvider();

   // Получение первого объекта JBC.

   JamesBondCar qCar = cp.GetJBCByIndex(0);

   // Получение всех объектов JBC.

   List‹JamesBondCar› allJBCs = cp.GetAllAutos();

   // Использование первой машины.

   UseCar(gCar);

   // Использование всех машин в List‹›.

   foreach(JamesBondCar j in allJBCs) UseCar(j);

   Console.WriteLine(''Старт клиента! Для остановки нажмите ‹Enter›");

   Console.ReadLine();

  }

 }

}

Содержимое файла *.config на стороне клиента также соответствует ожиданиям. Здесь нужно просто изменить URL активизации.

‹configuration›

 ‹system.runtime.remoting›

  ‹application›

   ‹client displayName = "CarClient"›

    ‹wellknown type= "CarGeneralAsm.CarProvider, CarGeneralAsm" url="tcp://localhost:32469/carpovider.rem"/›

   ‹/client›

    ‹ channels ›

    ‹channel ref="http" /›

   ‹/channels›

  ‹/application›

 ‹/system.runtime.remoting›

‹ /configuration ›

Теперь запустите свои приложения сервера и клиента (конечно же, в указанном порядке) и рассмотрите соответствующий вывод. В окне консоли клиента будут представлены объекты JamesBondCar и соответствующая информация для каждого типа. Напомним, что вы взаимодействуете с List‹› и типами JamesBondCar, поэтому вы работаете с их членами в рамках домена приложения клиента, так как оба указанных типа обозначены атрибутом [Serializable].

Чтобы доказать это, измените вспомогательную функцию UseCar() так, чтобы она вызывала метод TurnOnRadio() для входного объекта JamesBondCar. Теперь запустите приложения сервера и клиента еще раз. Обратите внимание на то, что на машине клиента теперь появляются соответствующие сообщения. Если бы типы Car, Radio и JamesBondCar были сконфигурированы, как MBR-типы, сообщения бы появлялись на сервере. Для проверки получите каждый из указанных типов из MarshalByRefObject и перекомпилируйте все три компоновочных блока (для гарантии того, что Visual Studio 2005 скопирует самый последний CarGeneralAsm.dll в каталоги приложений клиента и сервера). Теперь при выполнении приложения окно с сообщением появится на удаленной машине.

Исходный код. Проекты CarGeneralAsm, CarProviderServer и CarProviderClient размещены в подкаталоге, соответствующем главе 18.

 

Вы уже видели, что WKO-типы, сконфигурированные для активизации одиночного вызова, существуют только в процессе текущего вызова метода. Поэтому WKO-типы одиночного вызова являются объектами, не меняющими своего состояния в процессе выполнения. Как только текущий вызов завершается, WKO-тип одиночного вызова становится объектом, предназначенным для участия в очередной процедуре сборки мусора.

С другой стороны, САО-типы, а также WKO-типы, сконфигурированные для активизации в виде синглета, являются по своей природе объектами, кумулятивно изменяющими параметры своего состояния в процессе выполнения вызовов клиентов. Учитывая эти две доступные опции установки конфигурации, возникает следующий вопрос: как процесс сервера "узнает" о том, что пора уничтожить такой MBR-объект? Если сборщик мусора на сервере уничтожит MBR-объекты, находящиеся в использовании удаленным клиентом, это создаст проблемы, А если серверу придется ожидать освобождения MBR-типов слишком долго, это отрицательно повлияет на работу системы, особенно если соответствующие MBR-объекты удерживают важные ресурсы (связь с базой данных, неуправляемые типы или какие-то другие ресурсы).

Цикл существования MBR-объекта, являющегося CAO-типом или WKD-синглетом, контролируется по схеме лизингового управления, которая тесно связана с процессом сборки мусора .NET. Если "время аренды" MBR-объекта, являющегося CAO типом или WKO-синглетом истекает, объект становится кандидатом на участие в очередном цикле сборки мусора. Как и в случае любого другого .NET-типа, если удаленный объект переопределяет System.Object.Finalize() (с помощью синтаксиса деструктора C#), то среда выполнения .NET автоматически запустит соответствующую логику финализации.

 

Схема лизингового управления, используемая по умолчанию

Для MBR-объектов, являющихся САО-типами или WKO-синглетами, применяется так называемый лизинг по умолчанию, время которого равно пяти минутам. Если среда выполнения обнаружит, что MBR-объект, являющийся САО-типом или WKO-синглетом, остается неактивным в течение пяти минут, делается вывод о том, что клиент больше не использует данный удаленный объект, и поэтому этот объект может использоваться в процессе сборки мусора. При этом совсем не обязательно, чтобы после истечения времени лизинга объект помечался для сборки мусора немедленно. На самом деле есть много возможностей влиять на поведение, задаваемое лизингом по умолчанию.

Например, при каждом вызове клиентом члена удаленного MBR-обьекта, являющегося САО-типом или WKO-синглетом, время лизинга снова устанавливается равным пяти минутам. Но кроме автоматического обновления интервала времени лизинга при вызове клиента, среда выполнения .NET обеспечивает три дополнительные альтернативы.

• Установки лизинга по умолчанию для удаленных объектов могут переопределяться файлами *.config.

• Могут использоваться спонсоры лизинговой схемы сервера, действующие от имени удаленного объекта, время лизинга которого уже истекло.

• Могут использоваться спонсоры лизинговой схемы клиента, действующие от имени удаленного объекта, время лизинга которого уже истекло.

Мы рассмотрим каждую из указанных возможностей в следующих разделах, а пока что давайте рассмотрим установки лизинга, принятые для удаленного типа по умолчанию. Вспомните, что базовый класс MarshalByRefObject определяет член с именем GetLifetimeService(). Этот метод возвращает ссылку на внутренний объект, поддерживающий интерфейс System.Runtime.Remoting.Lifetime.ILease. Интерфейс ILease можно использовать для управления параметрами лизинга данного САО-типа или WKO-синглета. Вот формальное определение этого интерфейса.

public interface ILease {

 TimeSpan CurrentLeaseTime { get; }

 LeaseState CurrentState { get; }

 TimeSpan InitialLeaseTime { get; set; }

 TimeSpan RenewOnCallTime { get; set; }

 TimeSpan SponsorshipTimeout { get; set; }

 void Register(System.Runtime.Remoting.Lifetime.ISponsor obj);

 void Register(System.Runtime.Remoting.Lifetime.ISponsor obj, TimeSpan renewalTime);

 TimeSpan Renew(TimeSpan renewalTime);

 void Unregister(System.Runtime.Remoting.Lifetime.ISponsor obj);

}

Интерфейс ILease не только позволяет получить информацию о текущих параметрах лизинга (с помощью CurrentLeaseTime, CurrentState и InitialLeaseTime), но и обеспечивает возможность построения "спонсоров" лизинга (более подробно об этом будет говориться позже). Роль каждого из членов ILease описана в табл. 18.6.

Таблица 18.6. Члены интерфейса ILease

Для иллюстрации особенностей лизинга по умолчанию для удаленных СAО-типов и WKO-синглетов определим в нашем текущем проекте CAOCarGeneralAsm новый внутренний класс LeaseInfo. Статический член LeaseStats() этого класса выводит информацию о текущем лизинге для типа CarProvider в окно консоли сервера (не забудьте указать директиву using для пространства имен System.Runtime.Remoting.Lifetime, чтобы сообщить компилятору о месте нахождения определении типа ILease).

internal class LeaseInfo {

 public static void LeaseStats(ILease itfLease) {

  Console.WriteLine(***** Информация о лизинге *****");

  Console.WriteLine("Состояние лизинга: {0}", itfLease.CurrentState);

  Console.WriteLine("Начальное время лизинга: {0}:{1}", itfLease.InitialLeaseTime.Minutes, itfLease.InitialLeaseTime.Seconds);

  Console.WriteLine("Текущее время лизинга: {0}:{1}", itfLease.CurrentLeaseTime.Minutes, itfLease.CurrentLeaseTime.Seconds);

  Console.WriteLine("Обновление времени при вызове: {0}:{1}", itfLease.RenewOnCallTime.Minutes, itfLease.RenewOnCallTime.Seconds);

  Console.WriteLine();

 }

}

Теперь предположим, что LeaseInfo.LeaseStats() вызывается в рамках методов GetJBCByIndex() и GetAllAutos() типа CarProvider. После перекомпиляции компоновочных блоков сервера и клиента (снова для гарантии того, что система Visual Studio 2005 скопирует самую последнюю и наиболее полную версию CarGeneralAsm.dll в каталоги приложений клиента и сервера), выполните приложение еще раз. Окно консоли вашего сервера должно теперь быть похожим на то, которое показано на рис. 18.6.

Рис. 18.6. Информация лизинга по умолчанию для CarProvider

 

Изменение параметров схемы лизингового управления

Очевидно, параметры лизинга по умолчанию не могут годиться во всех случаях и для всех удаленных САО-объектов и WKO-синглетов. Если вы хотите изменить типовые установки, у вас на выбор есть два варианта.

• Установки лизинга, принятые по умолчанию, можно изменить с помощью файла *.config сервера.

• Установки лизинга, принятые по умолчанию, можно изменить программными средствами путем переопределения членов базового класса MarshalByRefObject.

Каждый из этих подходов действительно позволяет изменить установки лизинга, принятые по умолчанию, но между этими подходами есть принципиальная разница. При использовании файла *.config сервера установки лизинга применяются ко всем объектам, размещаемым в рамках процесса сервера. При переопределении отдельных членов типа MarshalByRefObject появляется возможность изменять установки лизинга для каждого объекта в отдельности.

Чтобы продемонстрировать изменение параметров лизинга по умолчанию с помощью файла *.config, добавим к XML-данным сервера дополнительный элемент ‹lifetime›.

‹configuration›

 ‹system.runtime.remoting›

  ‹application›

   ‹lifetime leaseTime = "15M" renewOnCallTime = "5M"/›

   ‹service›

    ‹activated type="CarGeneralAsm.CarProvider, CarGeneralAsm" /›

   ‹/service›

   ‹channels›

    ‹channel ref="tcp" port="32469" /›

   ‹/channels›

  ‹/application

 ‹/system.runtime.remoting›

‹/configuration›

Обратите внимание на то, что в значениях свойств leaseTime и renewOnCallTime используется суффикс M, который, как вы можете догадаться сами, при установке времени для лизинга обозначает использование минут в качестве единицы измерения. При необходимости числовые значения элемента ‹lifetime› могут также содержать суффиксы MS (миллисекунды), S (секунды), Н (часы) и даже D (дни).

Повторим, что при изменении файла *.config сервера вы изменяете параметры лизинга для каждого САО-объекта и WKO-синглета в рамках сервера. Как альтернативу, можно использовать программное переопределение метода InitializeLifetime() конкретного удаленного типа.

public class CarProvider: MarshalByRefObject {

 public override object InitializeLifetimeService() {

  // Получение текущей информации лизинга.

  ILease itfLeaseInfo = (ILease)base.InitializeLifetimeService();

   // Изменение установок.

  itfLeaseInfo.InitialLeaseTime = TimeSpan.FromMinutes(50);

  itfLeaseInfo.RenewOnCallTime = TimeSpan.FromMinutes(10);

  return itfLeaseInfo;

 }

 …

}

Здесь CarProvider устанавливает значение 50 минут для InitialLeaseTime и значение 10 – для RenewOnCallTime. Снова подчеркнем, что преимуществом переопределения метода InitializeLifetimeServices() является возможность, настройки каждого удаленного типа в отдельности.

Наконец, чтобы вообще отключить ограничения для времени лизинга данного СAО-типа или WKO-синглета, переопределите InitializeLifetimeServices() так, чтобы возвращалось значение null. В результате вы, по сути, укажете МВR-тип, который будет существовать всё время, пока будет работать хост-приложение сервера.

 

Настройка параметров лизинга на стороне сервера

Вы только видели, что переопределение метода InitializeLifetimeServices() MBR-типом позволяет изменить текущие параметры лизинга во время активизации типа. Но что делать, если удаленному типу нужно изменить параметры лизинга после активизации? Предположим, например, что тип CarProvider предлагает новый метод, выполняющий операцию, требующую много времени (например; соединение с удаленной базой данных с последующим чтением большого набора записей). Перед началом выполнения такого заданий вы можете программно изменить время лизинга так, чтобы в случае, когда остаток времени становится менее одной минуты, время лизинга снова увеличивалось до десяти минут. Для этого можно использовать наследуемые методы MarshalByRefObject.GetLifetimeService() и ILease.Renew() так, как предлагается ниже.

// Корректировка параметров лизинга на стороне сервера.

// Предполагается, что это новый метод типа CarProvider.

public void DoLengthyOperation() {

 ILease itfLeaseInfo = (ILease)this.GetLifetimeService();

 if (itfLeaseInfo.CurrentLeaseTime.TotalMinutes ‹ 1.0) itfLeaseInfo.Renew(TimeSpan.FromMiutes(10));

 // Выполнение длительной операции…

}

 

Настройка параметров лизинга на стороне клиента

В дополнение к указанным возможностям ILease, домен приложения клиента тоже может регулировать текущие параметры лизинга CAO-типов и WKD-сингле-тов, с которыми осуществляется удаленное взаимодействие. Для этого клиент должен использовать статический метод RemotingServices.GetLifetimeService(). В качестве параметра указанному члену клиент должен передать ссылку на удаленный тип так, как показано ниже.

// Корректировка параметров лизинга на стороне клиента.

CarProvider ср = new CarProvider(сars);

ILease itfLeaseInfo = (ILease)RemotingServices.GetLifetimeServiсе(cp);

if (itfLeaseInfo.CurrentLeaseTime.TotalMinutes ‹ 10.0) itfLeaseInfo.Renew(TimeSpan.FromMinutes(1000));

Такой подход может быть полезен тогда, когда домен приложения клиента готов начать выполнение длительной операции в потоке, использующем удаленный тип. Например, если однопоточное приложение должно напечатать документ, содержащий 100 страниц текста, очень велика вероятность того, что удаленный САО-тип или WKO-синглет может выйти за рамки отведенного для процесса времени. Надеюсь, вы уловили общую идею, хотя здесь, конечно, более "элегантным" решением является создание нового потока выполнения.

 

При изучении материала этой главы вы создали группу консольных серверных хостов, обеспечивающих доступ к некоторому множеству удаленных объектов. Если вы имеете опыт использования классической модели DCOM (Distributed Component Object Model – распределенная модель компонентных объектов), соответствующие шаги могут показаться вам немного странными. В мире DCOM обычно строится один COM-сервер (на стороне сервера), содержащий удаленные объекты, который несет ответственность и за прием запросов, поступающих от удаленного клиента. Это единственное DCOM-приложение *.exe "спокойно" загружается в фоновом режиме без создания, в общем-то ненужного командного окна.

При построении компоновочного блока сервера .NET велика вероятность того, что удаленной машине не придется отображать никаких сообщений. Скорее всего, вам понадобится сервер, который только откроет подходящие каналы и зарегистрирует удаленные объекты для доступа клиента. Кроме того, при наличии простого консольного хоста вам (или кому-нибудь другому) придется вручную запустить компоновочный блок *.exe на стороне сервера, поскольку система удаленного взаимодействия .NET не предусматривает автоматический запуск файла *.exe на стороне сервера при вызове удаленным клиентом.

С учетом этих проблем возникает следующий вопрос: как создать невидимый приемник, который загрузится автоматически? Программисты .NET предлагают здесь на выбор две возможности.

• Построение .NET-приложения сервиса Windows, готового предложить хостинг для удаленных объектов.

• Разрешение осуществлять хостинг для удаленных объектов серверу IIS (Internet Information Server – информационный сервер Интернет).

 

Хостинг удаленных объектов с помощью сервиса Windows

Возможно, идеальным хостом для удаленных объектов является сервис Windows, поскольку сервис Windows позволяет следующее.

• Может загружаться автоматически при запуске системы

• Может запускаться, как "невидимый" процесс в фоновом режиме

• Может выполняться от имени конкретной учетной записи пользователя

Создать пользовательский сервис Windows средствами .NET исключительно просто, особенно в сравнении с возможностями непосредственного использования Win32 API. Для примера мы создадим проект Windows Service с именем CarWinService (рис. 18.7), который будет осуществлять хостинг удаленных типов, содержащихся в CarGeneralAsm.dll.

В результате Visual Studio 2005 сгенерирует парциальный класс (названный по умолчанию Service1), полученный из System.ServiceProcess.ServiceBase, и еще один класс (Program), реализующий метод Main() сервиса. Поскольку Service1 нельзя считать достаточно информативным именем для пользовательского сервиса, с помощью окна свойств укажите для свойств (Name) и ServiceName значение CarService. Различие между этими двумя свойствами в том, что значение (Name) задает имя, используемое для обращения к типу в программном коде, а свойство ServiceName обозначает имя, отображаемое в окне конфигурации сервисов Windows.

Перед тем как двигаться дальше, установите ссылки на компоновочные блоки CarGeneralAsm.dll и System.Remoting.dll, а также укажите следующие строки директив using в файле, содержащем определение класса CarService.

using System.Runtime.Remoting;

using System.Runtime.Remoting.Channels.Http;

using System.Runtime.Remoting.Channels;

using System.Diagnostics;

Рис. 18.7. Создание рабочего пространства нового проекта Windows Service

Реализация метода Main()

Метод Main() класса Program обеспечивает запуск сервисов, определённых в проекте, путём передачи массива типов ServiceBase статическому методу Service.Run(). При условии, что имя пользовательского сервиса было изменено с Service1 на CarService, вы должны иметь следующее определение класса (для ясности программного кода здесь удалены комментарии).

static class Program {

 static void Main() {

  ServiceBase[] ServicesToRun;

  ServicesToRun = new ServiceBase[] { new CarService () };

  ServiceBase.Run(ServicesToRun);

 }

}

Реализация метода CarService.OnStart()

Вы, вероятно, уже догадываетесь, какая программная логика должна использоваться при запуске пользовательского сервиса. Напомним, что целью CarService является выполнение той задачи, которую выполнял ваш консольный сервис. Поэтому, чтобы зарегистрировать CarService в виде WKO-синглета, доступного по протоколу HTTP, можете добавить в метод OnStart() следующий программный код (при использовании сервисов Windows для обслуживания удаленных объектов вместо "жестко" запрограммированной реализации можно использовать тип RemotingConfiguration, позволяющий загрузить файл *.config удаленного взаимодействия на стороне сервера).

protected override void OnStart(string[] args) {

 // Создание нового HttpChannel.

 HttpChannel с = new HttpChannel(32469);

 ChannelServices.RegisterChannel(c);

 // Регистрация WKO-типа одиночного вызова.

 RemotingConfiguration.RegisterWellKnownServiceType(typeof(CarGeneralAsm.CarProvider), "CarProvider.soap", WellKnownObjectMode.SingleCall);

 // Сообщение об успешном старте.

 EventLog.WriteEntry("CarWinService", "CarWinService стартовал успешно!", EventLogEntryType.Information);

}

Заметим, что после регистрации типа в журнал регистрации событий Windows (с помощью типа System.Diagnostics.EventLog) записывается пользовательское сообщение с информацией о том, что машина-хост успешно запустила ваш сервис.

Реализация метода OnStop()

Строго говоря, CarService не требует никакой программной логики остановки. Но для примера давайте направим в EventLog еще одно событие, на этот раз с информацией о завершении работы пользовательского сервиса Windows.

protected override void OnStop() {

 EventLog.WriteEntry("CarWinService", "CarWinService остановлен", EventLogEntryType.Information);

}

Теперь, когда сервис полностью оформлен, следующей задачей является установка этого сервиса на удаленной машине.

Добавление установщика сервиса

Чтобы получить возможность установки сервиса на выбранной вами машине, нужно добавить в текущий проект CarWinService дополнительный тип. Для установки любого сервиса Windows (созданного как средствами .NET, так и средствами Win32 API) требуется создание в реестре целого ряда записей, которые позволят ОС взаимодействовать с сервисом. Вместо создания этих записей вручную, можно просто добавить в проект сервиса Windows тип Installer (установщик), который правильно сконфигурирует тип, производный от ServiceBase, для установки на целевой машине.

Чтобы добавить установщик для CarService, откройте окно проектирования сервиса (с помощью двойного щелчка на файле CarService.cs в окне Solution Explorer), щелкните правой кнопкой в любом месте окна проектирования сервиса и выберите Add Installer (добавить установщик), рис. 18.8.

Рис. 18.8. Добавление установщика для пользовательского сервиса Windows

В результате будет добавлен новый компонент, который оказывается производным базового класса System.Configuration.Install.Installer. В окне проектирования теперь будет два компонента. Тип serviceInstaller1 представляет установщик конкретного сервиса в вашем проекте. Выбрав соответствующую пиктограмму, вы обнаружите, что в окне Properties для свойства ServiceName установлено значение типа CarService.

Второй компонент (serviceProcessInstaller1) позволяет задать окружение, в котором будет выполняться установленный сервис. По умолчанию значением свойства Асcount (учетная запись) является User (пользователь). С помощью окна свойств Visual Studio 2005 измените это значение на LocalServicе (локальный сервис), рис. 18.9.

Рис. 18.9. Идентификация СarService

Вот и все! Теперь скомпилируйте свой проект.

Установка CarWinService

Установка CarService.exe на машине (локальной или удаленной) предполагает выполнение двух действий.

1. Перемещение скомпилированного компоновочного блока сервиса (и всех необходимых внешних компоновочных блоков – в данном случае это CarGeneralAsm.dll) на удаленную машину.

2. Запуск средства командной строки installutil.exe с указанием соответствующего сервиса в качестве аргумента.

После выполнения п. 1 откройте командное окно Visual Studio 2005, перейдите в каталог с компоновочным блоком CarWinService.exe и введите следующую команду (этот же инструмент можно использовать и для деинсталляции сервиса).

installutil carwinservice.exe

После установки сервиса Windows вы можете запустить и сконфигурировать его с помощью апплета Services (Службы) Windows, который размещен в папке Администрирование панели управления Windows. В окне Services выделите CarService (рис. 18.10) и щелкните на ссылке Start (Запустить), чтобы загрузить и выполнить соответствующий двоичный файл.

Рис. 18.10. Апплет Services Windows

Исходный код. Проект CarWinService размещен в подкаталоге, соответствующем главе 18.

 

Хостинг удаленных объектов с помощью IIS

Хостинг удаленного компоновочного блока с помощью сервера IIS (Internet Information Server – информационный сервер Интернет) даже проще, чем создание сервиса Windows, поскольку сервер IIS специально запрограммирован на то, чтобы получать поступающие запросы HTTP через порт 80. Поскольку IIS является Web-сервером, должно быть очевидно, что IIS может осуществлять обслуживание только удаленных объектов, использующих тип HttpChannel (в отличие от сервиса Windows, который допускает также использование типа TcpChannel). С учетом этого ограничения, при использовании IIS для поддержки удаленного взаимодействия необходимо выполнить следующие действия.

1. На жестком диске создайте новую папку для хранения CarGeneralAsm.dll. В этой папке создайте подкаталог \Bin. Скопируйте файл CarGeneralAsm.dll в этот подкаталог (например, C:\IISCarService\Bin).

2. На машине-хосте откройте окно апплета Internet Information Services (размещенного в папке Администрирование панели управления Windows).

3. Щелкните правой кнопкой в строке узла Default Web Site (Web-узел по умолчанию) и выберите New→Virtual Directory из появившегося контекстного меню.

4. Создайте виртуальный каталог, соответствующий только что созданной вами корневой папке (C:\IISCarService). Остальные значения, предложенные мастером создания виртуального каталога, будут вполне подходящими.

5. Наконец, создайте новый файл конфигураций с именем web.config для настройки параметров регистрации удаленных типов виртуальным каталогом (см. следующий фрагмент программного кода). Сохраните этот файл в соответствующей корневой папке (в данном случае это папка C:\IISCarService).

‹configuration›

 ‹system.runtime.remoting›

  ‹application›

   ‹service›

    ‹wellknown mode="Singleton" type="CarGeneralAsm.CarProvider, CarGeneralAsm" objectUri="carprovider.soap" /›

   ‹/service›

   ‹channels›

    ‹channel ref="http"/›

   ‹/channels›

  ‹/application ›

 ‹/system.runtime.remoting›

‹/configuration›

Теперь файл CarGeneralAsm.dll будет доступен для НТТР-запросов IIS, и вы можете обновить файл *.config на стороне клиента так, как показано ниже (конечно, указав в нем имя своего IIS-хоста).

‹configuration›

 ‹system.runtime.remoting›

  ‹application›

   ‹client displayName="CarClient"›

    ‹wellknown type="CarGeneralAsm.CarProvider, CarGeneralAsm" url= "http://NameTheRemoteIISHost/IISCarHost/carprovider.soap "/›

   ‹/client›

   ‹channels›

    ‹channel ref="http"/›

   ‹/channels›

  ‹/application›

 ‹/sуstem.runtime.remoting›

‹/configuration›

После этого вы сможете выполнять приложение клиента так же, как и раньше.

 

В завершение нашего обсуждения материала данной главы давайте выясним, как вызывать члены удаленного типа асинхронно. В главе 14 была рассмотрена тема асинхронного вызова методов с помощью типов делегата. Как и следует ожидать, при асинхронном вызове удаленного объекта компоновочным блоком клиента первым шагом должно быть определение пользовательского делегата, представляющего соответствующий удаленный метод. После этого вызывающая сторона для вызова метода и получения возвращаемых значений может использовать любой из подходов, описанных в главе 14.

Для примера создайте новое консольное приложение (AsyncWKOCarProvider-Client) и установите в нем ссылку на первый вариант компоновочного блока CarGeneralAsm.dll. Теперь измените класс Program так, как показано ниже:

class Program {

 // Делегат для метода GetAllAutos().

 internal delegate List‹JamesBondCar› GetAllAutosDelegate();

 static void Main(string[] args) {

  Console.WriteLine("Старт клиента! Для завершения нажмите ‹Enter›");

  RemotingConfiguration.Configure("AsyncWKOCarProviderClient.exe.config");

   // Создание поставщика машин.

  CarProvider cp = new CarProvider();

   // Создание делегата.

  GetAllAutosDelegate getCarsDel = new GetAllAutosDelegate(cp.GetAllAutos);

  // Асинхронный вызов GetAllAutos().

  IAsyncResult ar = getCarsDel.BeginInvoke(null, null);

   // Имитация активности клиента.

  while (!ar.IsCompleted) { Console.WriteLine("Клиент работает…"); }

  // Все сделано! Получение возвращаемого значения делегата.

  List‹JamesBondCar allJBCs = getCarsDel.EndInvoke(ar);

  // Использование всех машин из списка.

  foreach(JamesBondCar j in allJBCs) UseCar(j);

  Console.ReadLine();

 }

}

Здесь приложение клиента сначала объявляет делегат, соответствующий сигнатуре метода GetAllAutos() удаленного типа CarProvider. После создания делегата имя вызываемого метода (GetAllAutos) передается ему, как обычно. Потом запускается метод BeginInvoke(), сохраняется результирующий интерфейс IAsyncResult и имитируется какая-то работа на стороне клиента (напомним, что свойство IAsyncResult.IsCompleted позволяет выяснить, завершил ли работу соответствующий метод). После завершения работы клиента вы получаете список List‹›, возвращенный методом CarProvider.GetAllAutos() в результате вызова члена EndInvoke(), и передаете каждый объект JamesBondCar статической вспомогательной функции с именем UseCar().

public static void UseCar(JamesBondCar j) {

 Console.WriteLine("Может ли машина летать"? {0}", j.isFlightWorthy);

 Console.WriteLine("Может ли машина плавать? {0}", j.isSeaWorthy);

}

Снова подчеркнем, что красота использования типа делегата .NET заключается в том, что форма асинхронного вызова удаленных методов оказывается аналогичной форме вызова локальных методов.

Исходный код. Проект AsynсWKOCarProviderClient размещен в подкаталоге, соответствующем главе 18.

 

Роль атрибута [OneWay]

Предположим, что CarProvider должен иметь метод AddCar(), принимающий в качестве входного параметра JamesBondCar и не возвращающий ничего. Здесь главное те, что метод не возвращает ничего. Из названия класса System.Runtime. Remoting.Messaging.OneWayAttribute можно догадаться, что в данном случае слой удаленного взаимодействия .NET передает вызов удаленной стороне односторонним способом, и не заботится о создании инфраструктуры, необходимой для возврата значения (отсюда и название one-way - односторонний). Вот соответствующая модификация класса.

// "Обитель" атрибута [OneWay].

using System.Runtime.Remoting.Messaging;

…

namespace CarGeneralAsm {

 public class CarProvider: MarshalByRefObject {

  …

  // Клиент может вызвать соответствующий метод

  // и 'забыть' о нем.

  [OneWay]

  public void AddCar(JamesBondCar newJBC) { theJBCars.Add(newJBC); }

 }

}

Вызывающая сторона вызывает этот метод так, как обычно.

// Создание поставщика машин.

CarProvider ср = new CarProvider();

// Добавление новой машины.

ср.AddCar(new JamesBondCar("Zippy", 200, false, false));

С точки зрения клиента вызов AddCar() является полностью асинхронным, поскольку среда CLR обеспечивает использование фонового потока для запуска удаленного метода. Поскольку AddCar() сопровождается атрибутом [OneWay], клиент не может получить от вызова никакого возвращаемого значения. Но, поскольку AddCar() возвращает void, это не является проблемой.

Вдобавок к указанному ограничению, следует также знать о том, что при наличии у метода с атрибутом [OneWay] выходных или ссылочных параметров (определяемых с помощью ключевых слов out или ref) вызывающая сторона не сможет получить модификации вызываемой стороны. К тому же, если вдруг метод с атрибутом [OneWay] сгенерирует исключительное состояние (любого типа), вызывающая сторона ничего об этом не узнает. Удаленные объекты могут обозначить некоторые методы атрибутом [OneWay] только тогда, когда вызывающей стороне действительно позволяется вызвать эти методы и "забыть" об этом.

 

При построении приложения Windows Forms вы можете, при желании, создать весь соответствующий программный код вручную (например, в редакторе Блокнот или в редакторе TextPad), а затем отправить файлы *.cs компилятору командной строки C# с флагом /target:winexe. Построение нескольких приложений Windows Forms вручную дает не только бесценный опыт, но и помогает лучше понять программный код, генерируемый графическими средствами проектирования, предлагаемыми в рамках пакетов интегрированной среды разработки .NET разных производителей.

Чтобы вы могли понять основы процесса создания приложений Windows Forms, в первых примерах этой главы не используются графические средства проектирования. Освоив процесс построений приложений Windows Forms "без помощи мастеров", вы без труда сможете перейти к использованию различных инструментов разработки, встроенных в Visual Studio 2005.

 

Создание главного окна вручную

В начале изучения приемов программирования Windows Forms мы построим самое простое главное окно, так сказать, "с чистого листа". Создайте на своем жест-ком диске новую папку (например, C:\MyFirstWindow) и в этой папке с помощью любого текстового редактора создайте новый файл MainWindow.cs.

В Windows Forms класс Form используется для представления любого окна в приложении. Это относится и к главному окну, находящемуся на вершине иерархии окон в приложении с интерфейсом SDI (Single-Document Interface – однодокументный интерфейс), и к модальным и немодальным диалоговым окнам, и к родительским и дочерним окнам в приложении с интерфейсом MDI (Multiple Document Interface – многодокументный интерфейс). Чтобы создать и отобразить главное окно приложения, необходимо выполнить следующие два обязательных шага.

1. Получить новый класс из System.Windows.Forms.Form.

2. Добавить в метод Main() приложения вызов метода Application.Run(), передав этому методу экземпляр производного от Form типа в виде аргумента.

Поэтому добавьте в файл MainWindow.cs следующее определение класса.

using System;

using System.Windows.Forms;

namespace MyWindowsApp {

 public class MainWindow : Form {

  // Выполнение приложения и идентификация главного окна.

  static void Main(string[] args) {

   Application.Run(new MainWindow());

  }

 }

}

Вдобавок к обязательно присутствующему модулю mscorlib.dll, приложение Windows Forms должно сослаться на компоновочные блоки System.dll и System.Windows.Forms.dll. Вы, может быть, помните из главы 2, что используемый по умолчанию ответный файл C# (файл csc.rsp) дает указание csc.exe автоматически включить эти компоновочные блоки в процесс компиляции, так что здесь никаких проблем не ожидается. Также напомним, что опция /target:winexe компилятора csc.exe означает создание выполняемого файла Windows.

Замечание. Строго говоря, можно построить приложение Windows и с помощью опции /target:exe компилятора csc.exe, но тогда кроме главного окна полученное приложение в фоновом режиме будет создавать командное окно (которое будет существовать до тех пор, пока не завершит работу главное окно приложения). Указав /target:winexe, вы получите приложение, выполняемое в так называемом "родном" для Windows Forms режиме (без создания фонового командного окна).

Чтобы скомпилировать файл программного кода C#, откройте окно командной строки Visual Studio 2005 и выберите следующую команду.

csc /target:winexe *.cs

На рис. 19.1 показан результат запуска полученного приложения.

Рис. 19.1. Главное окно в стиле Windows Forms

Понятно, что такой результат применения средств Windows Forms впечатления не производит. Но обратите внимание на то, что путем получения простой производной от Form мы создали главное окно, допускающее минимизацию, максимизацию, изменение размеров и закрытие (да еще и с пиктограммой, предлагаемой системой по умолчанию!). В отличие от других средств разработки графического интерфейса от Microsoft, которые вы, возможно, использовали ранее (в частности, это касается библиотеки базовых классов MFC), теперь нет необходимости связывать сотни строк программного кода соответствующей инфраструктуры (фреймов, документов, представлений, приложений и карт сообщений). В отличие от приложений Win32 API, использующих C, здесь нет необходимости вручную реализовывать процедуры WinProc() и WinMain(). В рамках платформы .NET эту "грязную" работу выполняют элементы, инкапсулированные в типах Form и Application.

 

Принцип разграничения обязанностей

Сейчас класс MainWindow определяет метод Main() в рамках своего контекста. Но, если хотите, можно создать другой статический класс (назовем его Program). который будет отвечать за запуск главного окна, а задачей класса, производного от Form, останется непосредственное отображение окна.

namespace MyWindowsApp {

 // Главное окно.

 public class MainWindow: Form {}

 // Объект приложения.

 public static class Program {

  static void Main(string[] args) {

   // He забудьте о 'using' для System.Windows.Forms !

   Application.Run(new MainWindow());

  }

 }

}

В результате вы обеспечите поддержку одного из главных правил объектно-ориентированного программирования – разграничение обязанностей. Это правило требует, чтобы класс был ответственен за выполнение минимально возможного объема работы. Разделив исходный класс на два отдельных класса, вы тем самым отделили форму от создающего ее класса. Результатом оказывается более мобильное (в смысле переносимости) окно, поскольку его теперь можно поместить в рамки любого проекта без дополнительного метода Main(), специфичного для данного проекта.

Исходный код. Проект MyFirstWindow размещён в подкаталоге, соответствующем главе 19.

 

Класс Application определяет множество статических членов, позволяющих управлять поведением различных низкоуровневых элементов приложения Windows Forms. Класс Application определяет набор событий, позволяющих реагировать, например, на завершение работы приложения или переход в состояние ожидания.

Кроме метода Run(), этот класс предлагает и другие методы, о которых вам следует знать.

• DoEvents(). Обеспечивает для приложения возможность в ходе выполнения операций, требующих много времени, обрабатывать сообщения, находящихся в это время в очереди сообщений.

• Exit(). Завершает выполнение Windows-приложения и выгружает из памяти домен этого приложения.

• EnableVisualStyles(). Настраивает приложение на поддержку визуальных стилей Windows XP. При активизации поддержки ХР-стилей указанный метод должен вызываться до загрузки главного окна с помощью Application.Run().

Кроме того, класс Application определяет ряд свойств, многие из которых доступны только для чтения. При анализе табл. 19.2 обратите внимание на то, что большинство свойств представляет характеристики "уровня приложения" (имя компании, номер версии и т.д.). С учетом ваших знаний об атрибутах уровня компоновочного блока (см. главу 12) многие из этих свойств должны быть для вас понятны.

Таблица 19.2. Основные свойства типа Application

Наконец, класс Application определяет набор статических событий, и вот некоторые из них.

• ApplicationExit генерируется непосредственно перед тем, как данное приложение завершает работу.

• Idle генерируется тогда, когда цикл сообщений приложения заканчивает обработку текущего пакета сообщений и готовится к переходу в состояние ожидания (ввиду отсутствия сообщений для обработки).

• ThreadExit генерируется непосредственно перед тем, как завершает работу поток данного приложения.

 

Возможности класса Application

Для иллюстраций некоторых функциональных возможностей класса Application давайте расширим тип MainWindow, чтобы он мог выполнять следующее.

• Использовать значения некоторых атрибутов уровня компоновочного блока.

• Обрабатывать статическое событие ApplicationExit…

Первой нашей задачей является использование свойств класса Application для отображения атрибутов уровня компоновочного блока. Для начала добавьте в свой файл MainWindow.cs следующие атрибуты (обратите внимание на то, что здесь используется пространство имен System.Reflection).

using System;

using System.Windows.Forms;

using System.Reflection;

// Несколько атрибутов для данного компоновочного блока .

[аssembly:AssemblyCompany("Intertech Training")] [assembly: AssemblyProduct("Более совершенное окно")"] [assembly:AssemblyVersion("1.1.0.0")]

namespace MyWindowsApp {

 …

}

Вместо того чтобы отображать атрибуты [AssemblyCompany] и [AssemblyProduct] вручную, используя приемы, предлагавшиеся в главе 12, класс Application позволяет сделать это автоматически, используя различные статические свойства. Например, можно реализовать конструктор следующего вида, который будет играть роль конструктора, заданного по умолчанию.

public class MainWindow: Form {

 publiс MainWindow() {

  MessageBox.Show(Application. ProductName , String.Format("Это приложение создано для вас компанией {0}", Application. CompanyName ));

 }

}

Выполнив это приложение, вы увидите окно сообщения, отображающее соответствующую информацию (рис. 19.2).

Рис 19.2. Чтение атрибутов с помощью типа Application

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

public class MainForm: Form {

 public MainForm() {

  // Перехват события ApplicationExit.

  Application.ApplicationExit += new EventHandler(MainWindow_OnExit);

 }

 private void MainWindow_OnExit (object sender, EventArgs evArgs) {

  MessageBox.Show(string.Format("Форма версии {0} завершила работу.", Application.ProductVersion));

 }

}

 

Делегат System.EventHandler

Обратите внимание на то, что событие ApplicationExit работает в паре с делегатом System.EventHandler. Этот делегат может указывать методы, соответствующие следующей сигнатуре.

delegate void EventHandler(object sender, EventArgs e);

Делегат System.EventHandler является самым примитивным делегатом, используемым для обработки событий Windows Forms, но существует очень много его вариаций. Что же касается EventHandler, то его первый параметр (типа System. Object) представляет объект, сгенерировавший данное событие. Второй параметр EventArgs (или его потомок) может содержать любую информацию, относящуюся к данному событию.

Замечание. Класс EventArgs является базовым для множества производных типов, содержащих дополнительную информацию для событий из определенных семейств. Так, для событий мыши используется параметр MouseEventArgs, предлагающий, например, такую информацию, как позиция (х, у) указателя. Для событий клавиатуры используется тип KeyEventArgs, предоставляющий информацию о текущих нажатиях клавиш и т.д.

Так или иначе, если вы перекомпилируете и запустите приложение, то теперь перед завершением работы приложения вы увидите соответствующий блок сообщения.

Исходный код. Проект AppClassExample размещен в подкаталоге, соответствующем главе 19.

 

Класс System.Windows.Forms.Control задает общее поведение, ожидаемое от любого GUI-типа. Базовые члены Control позволяют указать размер и позицию элемента управления, выполнить захват событий клавиатуры и мыши, получить и установить фокус ввода, задать и изменить видимость членов и т.д. В табл. 19.4 определяются некоторые (но, конечно же, не все) свойства, сгруппированные по функциональности.

Таблица 19.4. Базовые свойства типа Control

Кроме того, класс Control определяет ряд событий, позволяющих реагировать на изменение состояния мыши, клавиатуры, действия выделения и перетаскивания объектов (а также на многие другие действия). В табл. 19.5 предлагается описок некоторых (но далеко не всех) событий, сгруппированных по функциональности.

Таблица 19.5. События типа Control

Наконец, базовый класс Control определяет целый ряд методов, позволяющих взаимодействовать с любым типом, производным от Control. При ближайшем рассмотрений методов Control вы обнаружите, что многие из них имеют префикс On, за которым следует имя соответствующего события (OnMouseMove, OnKeyUp, OnPaint и т.д.). Каждый из этих снабженных префиксом виртуальных методов представляет собой обработчик соответствующего события, заданный по умолчанию. Переопределив такой виртуальный член, вы получаете возможность выполнить необходимую предварительную (или заключительную) обработку данных, перед вызовом (или после вызова) родительской реализации обработчика события.

public class MainWindow: Form {

 protected override void OnMouseDown(MouseEventArgs e) {

  // Добавленный программный код для события MouseDown.

  // Вызов родительской реализации.

  base.OnMouseDown(e);

 }

}

Это может оказаться полезным, например, при создании пользовательских элементов управления, которые получаются из стандартных (см. главу 21), но чаще всего вы будете использовать обработку событий в рамках стандартного синтаксиса событий C# (именно это предлагается средствами проектирования Visual Studio 2005 по умолчанию). В этом случае среда разработки вызовет пользовательский обработчик события после завершения работы родительской реализации.

public class MainWindow: Form {

 public MainWindow() {

  MouseDown += new MouseEventHandler(MainWindow_MouseDown);

 }

 void MainWindow_MouseDown(object sender, MouseEventArgs e) {

  // Добавленный программный код для события MouseDown.

 }

}

Кроме методов вида OnХХХ(), есть несколько других методов, о которые вам следует знать.

• Hide(). Скрывает элемент управления, устанавливая для его свойства Visible значение false (ложь).

• Show(). Делает элемент управления видимым, устанавливая для его свойства Visible значение true (истина).

• Invalidate(). Заставляет элемент управления обновить свое изображение, посылая событие Paint.

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

 

Использование возможностей класса Control

Чтобы продемонстрировать возможности применения некоторых членов класса Control, давайте построим новую форму, способную обеспечивать следующее.

• Отвечать на события MouseMove и MouseDown.

• Выполнять захват и обработку ввода с клавиатуры, реагируя на событие KeyUp.

Для начала создайте новый класс, производный от Form. В конструкторе, заданном по умолчанию, мы используем различные наследуемые свойства, чтобы задать исходный вид и поведение формы. Обратите внимание на то, что здесь нужно указать использование пространства имён System.Drawing поскольку необходимо получить доступ к структуре Color (пространство имен System.Drawing будет рассмотрено в следующей главе).

using System;

using System.Windows.Forms;

using System.Drawing;

namespace MyWindowsApp {

 public class MainWindow: Form {

  publiс MainWindow() {

   // Использование наследуемых свойств для установки

   // характеристик интерфейса пользователя.

Text = "Моя фантастическая форма";

   Height = 300;

   Width = 500;

   BackColor = Color.LemonChiffon;

   Cursor = Cursors.Hand;

  }

 }

 public static class Program {

  static void Main(string[] args) {

   Application.Run(new MainWindow());

  }

 }

}

Скомпилируйте это приложение в его текущем виде, просто чтобы проверить что вы не допустили никаких опечаток.

csc /target:winexe *.cs

 

Ответ на события MouseMove

Далее, мы должны обработать событие MouseMove. Целью является отображение текущих координат (x, у) указателя в области заголовка формы. Все связанные с состоянием мыши события (MouseMove. MouseUp и т.д.) работают в паре с делегатом MouseEventHandler, способным вызвать любой метод, соответствующий следующей сигнатуре.

void MyMouseHandler(object sender, MouseEventArgs e);

Поступающая на вход структура MouseEventArgs расширяет общий базовый класс EventArgs путем добавления целого ряда членов, специально предназначенных для обработки действий мыши (табл. 19.6).

Таблица 19.6. Свойства типа MouseEventArgs

Вот обновленный класс MainForm, в котором обработка события MouseMove происходит так, как предполагается выше.

public class MainForm: Form {

 public MainForm() {

  …

  // Для обработки события MouseMove.

  MouseMove += new MouseEventHandler(MainForm_MouseMove);

 }

 // Обработчик события MouseMove.

 public void MainForm_MouseMove(object sender, MouseEventArgs e) {

  Text = string. Format ("Текущая позиция указателя: ({0}, {1}) ", е.Х, e.Y);

 }

}

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

Рис. 19.4. Мониторинг движения мыши

 

Регистрация щелчков кнопок мыши

Следует подчеркнуть, что событие MouseUp (как и MouseDown) посылается при щелчке любой кнопки мыши. Если нужно выяснить, какой кнопкой мыши был выполнен щелчок (левой, правой или средней), следует проанализировать значение свойства Button класса MouseEventArgs. Значение свойства Button соответствует одному из значений перечня MouseButtons. Предположим, что для обработки со-бытия MouseUp вы изменили заданный по умолчанию конструктор так, как показано ниже.

public MainWindow() {

 …

 // Для обработки события MouseUp.

 MouseUp += new MouseHandler(MainForm_MouseUp);

}

Следующий обработчик события MouseUp сообщает в окне сообщения о том, какой кнопкой мыши был выполнен щелчок.

public void MainForm_MouseUp(object sender, MouseEventArgs e) {

 // Какая кнопка мыши была нажата?

 if (e.Button == MouseButtons. Left) MessageBox.Show("Щелчок левой кнопки");

 if (e.Button == MouseButtons. Right) MessageBox.Show("Щелчок правой кнопки");

 if (e.Button == MouseButtons. Middle) MessageBox.Show("Щелчок средней кнопки");

}

 

Ответ на события клавиатуры

Обработка ввода с клавиатуры почти идентична обработке событий мыши. cобытия KeyUp и KeyDown работают в паре с делегатом KeyEventHandler, который может указывать на любой метод, получающий объект общего вида в качестве первого параметра, и KeyEventArgs – в качестве второго.

void MyKeyboardHandler(object sender, KeyEventArgs e);

Описания членов KeyEventArgs предлагаются в табл. 19.7.

Таблица 19.7. Свойства типа KeyEventArgs

Измените объект MainForm, чтобы реализовать обработку события KeyUp. В окне сообщения отобразите название нажатой клавиши, используя свойство KeyCode.

public class MainForm: Form {

 public MainForm() {

  …

  // Для отслеживания событий KeyUp.

  KeyUp += new KeyEventHandler(MainForm_KeyUp);

 }

 private void MainForm_KeyUp (object sender, KeyEventArgs e) {

  MessageBox.Show(e. KeyCode. ToString(), "Нажата клавиша!");

 }

}

Скомпилируйте и запустите программу. Теперь вы должны иметь возможность не только определить, какой кнопкой мыши был выполнен щелчок, но и то, какая была нажата клавиша на клавиатуре.

На этом мы завершим обсуждение функциональных возможностей базового класса Control и перейдем к обсуждению роли Form.

Исходный код. Проект ControlBehaviors размещен в подкаталоге, соответствующем главе 19.

 

Класс Form обычно (но не обязательно) является непосредственным базовым классом для пользовательских типов Form. В дополнение к большому набору членов, унаследованных от классов Control, ScrollableControl и ContainerControl, тип Form предлагает свои собственные функциональные возможности, в частности для главных окон, дочерних окон MDI и диалоговых окон. Давайте сначала рассмотрим базовые свойства, представленные в табл. 19.8.

Таблица 19.8. Свойства типа Form

В дополнение к ожидаемым обработчикам событий с префиксом On, предлагаемым по умолчанию, в табл. 19.9 предлагается список некоторых базовых методов, определенных типом Form.

Таблица 19.9. Основные методы типа Form

Наконец, класс Form определяет ряд событий, связанных с циклом существования формы. Основные такие события описаны в табл. 19.10.

Таблица 19.10. Подборка событий типа Form

 

Цикл существования типа Form

Если вы имеете опыт программирования интерфейсов пользователя с помощью таких пакетов разработки, как Java Swing, Mac OS X Cocoa или Win32 АРI, вы должны знать, что "оконные типы" поддерживают множество событий, происходящих в различные моменты цикла существования таких типов. То же самое можно сказать и о типах Windows Forms. Вы уже видели, что "жизнь" формы начинается тогда, когда вызывается конструктор типа, перед его передачей методу Application.Run().

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

Следующим событием, генерируемым после события Load, является событие Activated. Это событие генерируется тогда, когда форма получает фокус ввода, как активное окно на рабочем столе. Логическим "антиподом" события Activated является (конечно же) событие Deactivate, которое генерируется тогда, когда форма утрачивает фокус ввода, становясь неактивным окном. Легко догадаться, что события Activated и Deactivate в цикле существования формы могут генерироваться множество раз, поскольку пользователь может переходить от одного активного приложения к другому.

Когда пользователь решает закрыть соответствующую форму, по очереди генерируются еще два события: Closing и Closed. Событие Closing генерируется первым и дает возможность предложить конечному пользователю многими нелюбимое (но полезное) сообщение "Вы уверены, что хотите закрыть это приложение?". Этот шаг с требованием подтвердить выход полезен тем. что пользователю получает возможность сохранить данные соответствующего приложения перед завершением работы программы.

Событие Closing работает в паре с делегатом CancelEventHandler, определенным в пространстве имен System.ComponentModel. Если установить для свойства CancelEventArgs.Cancel значение true (истина), форме будет дано указание возвратиться к нормальной работе, и форма уничтожена не будет. Если установить для CancelEventArgs.Cancel значение false (ложь), будет сгенерировано событие Closed, и приложение Windows Forms будет завершено (домен приложения будет выгружен и соответствующий процесс прекращен).

Чтобы закрепить в памяти последовательность событий, происходящих в рамках цикла существовании формы, рассмотрим новый файл MainWindow.cs, в котором события Load, Activated, Deactivate, Closing и Closed обрабатываются в конструкторе класса так, как показано ниже (не забудьте добавить в программу директиву using для пространства имен System.ComponentModel, чтобы получить доступ к определению CancelEventArgs).

public MainForm() {

 // Обработка различных событий цикла существования формы.

 Closing += new CancelEventHandler(MainForm_Closing);

 Load += new EventHandler(MainForm_Load);

 Closed += new EventHandler(MainForm_Closed);

 Activated += new EventHandler(MainForm_Activated);

 Deactivate += new EventHandler(MainForm_Deactivate);

}

В обработчиках событий Load, Closed, Activated и Deactivate в строковую переменную System.String (с именем LifeTimeInfo) добавляется имя перехваченного события. Обработчик события Closed отображает значение этой строки в окне сообщения.

private void MainForm_Load(object sender, System.EventArgs e) { lifeTimeInfo += "Событие Load\n"; }

private void MainForm_Activated(object sender, System.EventArgs e) { lifeTimeInfo += "Событие Activate\n"; }

private void MainForm_Deactivate(object sender, System.EventArgs e) { lifeTimeInfo += "Событие Deactivate\n"; }

private void MainForm_Closed(object sender, System.EventArgs e) {

 lifeTimeInfo += "'Событие Closed\n";

 MessageBox.Show(lifeTimeInfо);

}

В обработчик события Closing задается вопрос о том, действительно ли пользователь желает завершить работу приложения. При этом используется поступающий на вход объект CancelEventArgs.

private void MainForm_Closing(object sender, CancelEventArgs e) {

 DialogResult dr = MessageBox.Show("Вы ДЕЙСТВИТЕЛЬНО хотите закрыть приложение?", "Событие Closing", MessageBoxButtons.YesNo);

 if (dr == DialogResult.No) e.Cancel = true;

 else e.Cancel = false;

}

Обратите внимание на то, что метод MessageBox.Show() возвращает тип DialogResult, значение которого идентифицирует кнопку (Да, Нет), нажатую в форме конечным пользователем. Теперь скомпилируйте полученный программный код в командной строке.

csc /target:winexe *.cs

Запустите приложение на выполнение и несколько раз поочередно предоставьте форме фокус ввода и уберите ее из фокуса ввода (чтобы сгенерировать события Activated и Deactivate). После прекращения работы вы увидите блок сообщений, аналогичный показанному на рис. 19.5.

Рис. 19.5. "Биография" типа, производного от Form

Большинство наиболее интересных возможностей типа Form связано с созданием и настройкой систем меню, панелей инструментов и строк состояния. Необходимый для этого программный код не слишком сложен, но Visual Studio 2005 предлагает целый набор графических инструментов проектирования, которые позаботятся о создании значительной части такого программного кода за вас. Поэтому давайте на время скажем "до свидания" компилятору командной строки и займемся созданием приложений Windows Forms с помощью Visual Studio 2005.

Исходный код. Проект FormLifeTime размещен в подкаталоге, соответствующем главе 19.

 

В Visual Studio 2005 предлагается специальный шаблон для создания приложений Windows Forms. Выбрав шаблон Windows Application при создании проекта, вы получите не только объект приложения с соответствующим методом Main(), но и подходящий исходный тип, производный от Form. Кроме того, среда разработки предложит вам целый набор графических инструментов проектирования, способных превратить процесс построения интерфейса пользователя в детскую забаву. Чтобы рассмотреть имеющиеся возможности, создайте рабочее пространство нового проекта Windows Application (рис. 19.6). Мы пока что не собираемся создавать рабочий пример, так что можете назвать этот проект так, как захотите.

Рис. 19.6. Проект Windows Application в Visual Studio 2005

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

Рис. 19.7. Панель инструментов Visual Studio 2005

Рис. 19.8. Окно свойств Visual Studio 2005

Как видите, элементы управления в панели инструментов сгруппированы по категориям. В большинстве своем эти категории самоочевидны – например, категория Printing (Печать) содержит средства управления печатью. Menus & Toolbars (Меню и панели инструментов) содержит рекомендуемые элементы управления для меню и панелей инструментов и т.д. Тем не менее, пара категорий заслуживает специального обсуждения.

• Common Controls (Общие элементы управления). Элементы этой категории можно считать "рекомендуемым набором" общих элементов управления для построения пользовательского интерфейса.

• All Windows Forms (Все элементы управления Windows Forms). Здесь вы найдете полный набор элементов управления Windows Forms, включая элементы управления .NET 1.х, которые считаются устаревшими.

Второй из указанных здесь пунктов заслуживает более пристального внимания. Если вы работали с Windows Forms в рамках .NET 1.x, вам будет полезно знать, что многие привычные для вас элементы управления (например, элемент управления DataGrid) находятся как раз под "знаком" категории All Windows Forms. К тому же, некоторые общие элементы управления, которые вы могли использовать в рамках .NET 1.x (например, MainMenu, ToolBar и Statusbar) по умолчанию в панели Toolbox не показаны.

 

Получение доступа к устаревшим элементам управления

Во-первых, отметим, что устаревшие элементы пользовательского интерфейса, о которых здесь идет речь, остаются пригодными для использования в .NET 2.0, а во-вторых, если вы хотите их использовать, то их можно снова добавить в панель инструментов. Для этого щелкните правой кнопкой мыши в любом месте окна Toolbox (кроме строки заголовка) и выберите Choose Items (Выбрать элементы) из появившегося контекстного меню. В появившемся диалоговом после этого окне отметьте нужные вам элементы (рис. 19.9).

Рис. 19.9. Добавление элементов управления на панель инструментов

Замечание. Может показаться, что а списке в окне добавления элементов управления имеются повторения (например, для элемента управления ToolBar). На самом же деле каждый элемент списка уникален, так как соответствующий элемент управления может иметь другую версию (например, 2.0 вместо 1.0) и/или быть элементом .NET Compact Framework. Поэтому будьте внимательны, чтобы выбрать правильный элемент.

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

Замечание. В этой главе мы используем новое, рекомендуемое сегодня множество элементов управления пользовательского интерфейса. Чтобы получить информацию, необходимую для работы с устаревшими типами MainMenu, Statusbar и другими аналогичными им типами, обратитесь к документации .NET Framework 2.0 SDK.

 

Анализ проекта Windows Forms в Visual Studio 2005

Любой тип Form проекта Windows Forms в Visual Studio 2005 представлен двумя связанными C#-файлами, в чем можно убедиться непосредственно, заглянув в окно Solution Explorer (рис. 19.10).

Рис. 19.10. Каждая форма является композицией двух файлов *.cs

Щелкните правой кнопкой мыши на пиктограмме Form1.cs и в появившемся контекстном меню выберите View Code (Просмотр программного кода). Вы увидите программный код парциального класса, содержащего обработчики событий формы, конструкторы, переопределения и другие члены созданного вами класса (заметьте, что здесь имя исходного класса Form1 было изменено на MainWindow с помощью выбора Rename из меню Refactor).

namespace MyVisualStudioWinApp {

 public partial class MainWindow: Form {

  public MainWindow() {

   InitializeComponent();

  }

 }

}

Конструктор, заданный формой по умолчанию, вызывает метод InitializeComponent(), определенный в соответствующем файле *.Designer.cs. Этот метод создается в Visual Studio 2005 автоматически, и в нем автоматически отражаются все модификации выполняемые вами в окне проектирования формы.

Для примера перейдите снова на вкладку окна проектирования формы и найдите свойство Text в окне свойств. Укажите для этого свойства новое значение (например, Мое тестовое окно). Теперь откройте файл Form1.Designer.cs и убедитесь в том, что метод InitializeComponent() соответствующим образом изменен.

private void InitializeComponent() {

 …

 this.Text = "Мое тестовое окно";

}

Кроме поддержки InitializeComponent(), файл *.Designer.cs определяет члены-переменные, представляющие элементы управления, размещенные в окне проектирования формы. Снова для примера перетащите элемент управления Button (Кнопка) в окно проектирования формы. В окне свойств с помощью свойства Name измените имя соответствующей переменной с button1 на btnTestButton.

Замечание. Всегда лучше переименовать размещаемый элемент управления, перед тем как программировать обработку событий. Если этого не сделать, вы получите целый набор обработчиков событий с неинформативными именами наподобие button27_Click, поскольку при создании соответствующего имени по умолчанию к имени элемента просто добавляется суффикс в виде порядкового номера переменной.

 

Обработка событий в режиме проектирования

Обратите внимание на то, что в окне свойств есть кнопка с изображением молнии. Вы, конечно, можете вручную создать программный код, обеспечивающий обработку событий уровня формы, (как это было сделано в предыдущих примерах), но эта кнопка позволяет обработать событие для данного элемента управления "визуально". Из раскрывающегося списка (вверху окна свойств) выберите элемент управления, который должен взаимoдeйствoвaть с формой, найдите событие, которое вы хотите обработать, и напечатайте имя, которое должно использоваться для обработчика события (или выполните двойной щелчок на имени события, чтобы сгенерировать типовое имя в виде ИмяЭлемента_ИмяСобытия).

Если задать обработку события Click для элемента управления Button, в файле Form1.cs появится следующий обработчик событий.

public partial class MainWindow: Form {

 public MainWindow {

  InitializeComponent();

 }

 private void btnButtonTest_Click(object sender, EventArgs e) {}

}

Файл Form1.Designer.cs будет содержать необходимую инфраструктуру и описание соответствующего члена-переменной.

partial class MainWindow {

 …

 private void InitializeComponent() {

  …

  this.btnButtonTest.Click += new System.EventHandler(this.btnButtonTest_Click);

 }

 private System.Windows.Forms.Button btnButtonTest;

}

Замечание. Каждый элемент управлении имеет свое событие по умолчанию, которое будет обработано при двойном щелчке на этом элементе управления в окне проектирования формы. Например, событием по умолчанию для формы является Load, так что если выполнить двойной щелчок, поместив указатель мыши на тип Form среда разработки автоматически запишет программный код для обработки именно этого события.

 

Класс Program

Кроме файлов, связанных с формой, Windows-приложение Visual Studio 2005 определяет еще один класс, представляющий объект приложения (т.е. тип, определяющий метод Main()). Обратите внимание на то, что в следующем методе Main() вызывается Application.EnableVisualStyles(), а также Application.Run().

static class Program {

 [STAThread]

 static void Main() {

  Application.EnableVisualStyles();

  Application.Run(new MainWindow());

 }

}

Замечание. Атрибут [STAThread] дает среде CLR указание обрабатывать все устаревшие COM-объекты (включая элементы управления ActiveX), используя STA-управление (SingleThreaded Apartment – однопоточное размещение). Если вы имеете опыт использования COM, вы должны знать, что STA-управление используется для того, чтобы доступ к COM-типу выполнялся в синхронном (а значит, безопасном в отношении потоков) режиме.

 

Необходимые компоновочные блоки

Наконец, если Заглянуть в окно Solution Explorer, вы увидите, что проект Windows Forms автоматически ссылается на целый ряд компоновочных блоков, среди которых будут System.Windows.Forms.dll и System.Drawing.dll.

Напомним, что подробное обсуждение System.Drawing.dll предполагается в следующей главе.

 

В рамках платформы .NET 2.0 рекомендуемым элементом управления для создания системы меню является MenuStrip. Этот элемент управления позволяет создавать как "обычные" пункты меню, такие как Файл→Выход, так и пункты меню, представляющие собой любые подходящие элементы управления. Вот некоторые общие элементы интерфейса, которые могут содержаться в MenuStrip.

• ToolStripMenuItem – традиционный пункт меню.

• ToolStripComboBox – встроенный элемент ComboBox (комбинированное окно).

• ToolStripSeparator – простая линия, разделяющая содержимое.

• ToolStripTextBox – встроенный элемент TextBox (текстовое окно).

С точки зрения программиста, элемент управления MenuStrip содержит строго типизированную коллекцию ToolStripItemCollection. Подобно другим типам коллекции, этот объект поддерживает методы Add(), AddRange(), Remove() и свойство Count. Эта коллекция обычно заполняется не напрямую, а с помощью различных инструментов режима проектирования, но если требуется, то есть возможность обработать ее и вручную.

Чтобы привести пример использования элемента управления MenuStrip, создайте новое приложение Windows Forms с именем MenuStripApp. Поместите элемент управления MenuStrip в форму в окне проектирования, присвоив ему имя mainMenuStrip. В результате в файл *.Designer.cs добавится новая переменная.

private System.Windows.Forms.MenuStrip mainMenuStrip;

Элемент управления MenuStrip имеет очень широкие возможности настройки в режиме проектирования в Visual Studio 2005. Например, вверху у этого элемента управления есть маленькая пиктограмма стрелки, в результате выбора которой появляется контекстно-зависимый "встроенный" редактор содержимого, как показано на рис. 19.11.

Рис. 19.11. "Встроенный" редактор MenuStrip

Такие контекстно-зависимые редакторы cодержимого поддерживаются многими элементами управления Windows Forms. Что же касается MenuStrip, то соответствующий редактор позволяет быстро сделать следующее.

• Вставить "стандартную" систему меню (File, Save, Tools, Help и т.д.), используя ссылку Insert Standard Items (Вставить стандартные элементы).

• Изменить стыковочное поведение MenuStrip.

• Отредактировать любой элемент MenuStrip (это просто "быстрая альтернатива" в отношении возможности выбора соответствующего конкретного элемента в окне свойств).

В этом примере мы проигнорируем возможности "встроенного" редактора, сосредоточившись на создании системы меню "вручную". Сначала в режиме проектирования выберите элемент управления MenuStrip и определите стандартное меню Файл→Выход, впечатав соответствующие имена в поле с подсказкой Type Here (Печатать здесь), рис. 19.12.

Рис. 19.12. Создание системы меню

Замечание. Вы, наверное, знаете, что символ амперсанда (&), размещенный перед буквой в строке элемента меню, задает комбинацию клавиш для быстрого вызова данного элемента. В этом примере указано &Файл→В&ыход, поэтому пользователь может активизировать меню Выход, нажав сначала ‹Alt+ф›, а затем ‹ы›.

Каждый элемент меню, введенный вами в режиме проектирования, представляется типом класса ToolStripMenuItem. Открыв свой файл *.Designer.cs, вы увидите там новые переменные для каждого из введенных элементов.

partial class MainWindow {

 private System.Windows.Forms.MenuStrip mainMenuStrip;

 private System.Windows.Forms.ToolStripMenuItem fileToolStripMenuItem;

 private System.Windows.Forms.ToolStripMenuItem exitToolStripMenuItem;

}

При использовании редактора меню метод InitializeComponent() соответственно обновляется. Для MenuStrip во внутреннюю коллекцию ToolStripItemCollection добавляется элемент, соответствующий новому пункту меню высшего уровня (fileToolStripMenuItem). Точно так же обновляется переменная fileToolStripMenuItem, для которой в ее коллекцию ToolStripItemCollection вставляется переменная exitToolStripMenuItem с помощью свойства DropDownItems.

private void InitializeComponent() {

 …

 //

 // menuStrip1

 //

 this.menuStrip1. Items.AddRange (new System.Windows.Forms.ToolStripItem[] { this.fileToolStripMenuItem });

 …

 //

 // fileToolStripMenuItem

  //

 this.fileToolStripMenuItem .DropDownItems.AddRange (new System.Windows.Forms.ToolStripItem[] { this.exitToolStripMenuItem });

 …

 //

 // MainWindow

 //

 this.Controls.Add(this.menuStrip1);

}

Наконец (что не менее важно), элемент управления MenuStrip добавляется в коллекцию элементов управления формы. Эта коллекции будет рассматриваться подробно в главе 21, а здесь важно отметить, чего элемент управления может быть видимым во время выполнения только в том случае, когда этот элемент присутствует в указанной коллекции.

Чтобы завершить создание программного кода нашего примера, вернитесь в режим проектирования и выполните обработку события Сlick для пункта меню Выход, используя кнопку событий в окне свойств. В сгенерированном обработчике событии выполните вызов ApplicationExit.

private void exitToolStripMenuItem_Click(object sender, EventArgs e) {

 Application.Exit();

}

Теперь вы можете скомпилировать и выполнить свою программу. Проверьте, что вы можете завершить работу приложения как с помощью выбора Файл→Выход из меню, так и с помощью нажатия ‹Аlt+ф›, а затем ‹ы› на клавиатуре.

 

Добавление элемента Textbox в MenuStrip

Давайте создадим новый элемент меню наивысшего уровня, присвоив этому элементу имя Изменение Цвета фона. Подчиненным элементом в этом меню будет не пункт меню, а элемент ToolStripTextBox (рис. 19.13). Добавив новый элемент управления, измените его имя на toolStripTextBoxColor с помощью окна свойств.

Нашей целью является возможность выбора пользователем цвета (красный, зелёный, розовый и т.д.). значение которого будет установлено для свойства BackColor формы. Сначала обработайте событие LostFocus для нового члена. ToolStripTextBox в рамках конструктора формы (это событие происходит тогда, когда TextBox в ToolStrip перестает быть активным элементом интерфейса).

public MainWindow() {

 …

 toolStripTextBoxColor.LostFocus += new EventHandler(toolStripTextBoxColor_LostFocus);

}

Рис. 19.13. Добавление TextBox в MenuStrip

В сгенерированном обработчике события прочитайте строковые данные, введенные в ToolStripTextBox (с помощью свойства Text), и используйте метод System. Drawing.Color.FromName(). Этот статический метод возвращает тип Color, соответствующий известному строковому значению. Чтобы учесть возможность ввода пользователем неизвестного цвета (или любых других неподходящих данных), используется простая логика try/catch.

void toolStripTextBoxColor_LostFocus(object sender, EventArgs e) {

 try {

  BackColor = Color.FromName(toolStripTextBoxColor.Text);

 } catch {} // Просто игнорировать неправильные данные.

}

Запустите обновленное приложение снова и попробуйте ввести названия различных цветов. В результате правильного ввода вы должны увидеть изменение цвета фона формы. Чтобы получить информацию о допустимых названиях цветов, изучите информацию о типе System.Drawing.Color в окне обозревателя объектов (Object Browser) Visual Studio 2005 или в документации .NET Framework 2.0 SDK.

 

Создание контекстных меню

Рассмотрим теперь процедуру построения контекстно-зависимых меню (т.е. меню, раскрывающихся по щелчку правой кнопки мыши). Классом, используемым для построения контекстных меню в .NET 1.1. был класс ContextMenu, но в .NET 2.0 предпочтение отдается типу ContextMenuStrip. Подобно типу MenuStrip, тип ContextMenuStrip поддерживает ToolStripItemCollection для представления всех элементов меню (ToolStripMenuItem, ToolStripComboBox, ToolStripSeparator, ToolStripTextBox и т.д.).

Перетащите новый элемент управления ContextMenuStrip из панели инструментов в окно проектирования формы и измените имя этого элемента управления на fontSizeContextStrip с помощью окна свойств. Обратите внимание на то, что теперь дочерние элементы в ContextMenuStrip можно добавлять графически, почти так же, как при редактировании MenuStrip (очень приятное изменение по сравнению с методом, предлагавшимся в Visual Studio .NET 2003). Для нашего примера добавьте три элемента ToolStripMenuItem с названиями Крупный, Средний и Мелкий (рис. 19.14).

Рис. 19.14. Создание ContextMenuStrip

Это контекстное меню предназначено для того, чтобы пользователь мог выбрать размер шрифта для сообщения, отображаемого в области клиента формы. Чтобы упростить себе задачу, создайте тип перечня TextFontSize в рамках пространства имен MenuStripApp и объявите новый член-переменную этого типа в рамках Form (установив для переменной значение TextFontSize.FontSizeNormal).

namespace MainForm {

 // Вспомогательный перечень для размера шрифта.

 enum TextFontSize {

  FontSizeHuge = 30,

  FontSizeNormal = 20,

  FontSizeTiny = 8

 }

 public class MainForm: Form {

  // Текущий размер шрифта.

  private TextFontSize currFontSize = TextFontSize.FontSizeNormal;

  …

 }

}

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

private void MainWindow_Paint(object sender, PaintEventArgs e) {

 Graphics g = e.Graphics;

 g.DrawString("Щелкните здесь правой кнопкой мыши…", new Font("Times New Roman", (float)currFontSize), new SolidBrush(Color.Black), 50, 50);

}

Наконец, нужно обработать события Click для каждого из типов ToolStripMenuItem, поддерживаемых элементом ContextMenuStrip. При этом можно, конечно, иметь отдельный обработчик событий Click для каждого из типов, но мы укажем один обработчик событий, который будет вызываться при щелчке на любом из трех элементов ToolStripMenuItem. Используя окно свойств, укажите для обработчика событий Click имя ContextMenuItemSelection_Ciicked для всех трех типов ToolStripMenuItem и реализуйте соответствующий метод так, как показано ниже.

private void ContextMenuItemSelection_Clicked(object sender, EventArgs e) {

 // Получение элемента ToolStripMenuItem,

 // на котором выполнен щелчок.

 ToolStripMenuItem miClicked = (ToolStripMenuItem)sender;

 // Поиск элемента, на которой выполнен щелчок, по его имени.

 if (miClicked.Name == "hugeToolStripMenuItem") currFontSize = TextFontSize.FontSizeHuge;

 if (miClicked.Name == "normalToolStripMenuItem") currFontSize = TextFontSize.FontSizeNormal;

 if (miClicked.Name == "tinyToolStripMenuItem") currFontSize = TextFontSize.FontSizeTiny;

 // Указание форме обновить представление.

 Invalidate();

}

Обратите внимание на то, что использование аргумента sender позволяет определить имя члена-переменной ToolStripMenuItem, чтобы установить размер текста. После этого вызов Invalidate() генерирует событие Paint, которое вызовет ваш обработчик события Paint.

Заключительным шагом является информирование формы о том, какой элемент ContextMenuStrip должен отображаться при щелчке правой кнопки мыши в области клиента. Для этого с помощью окна свойств установите значение свойства ContextMenuStrip равным имени элемента контекстного меню. После этого в контексте InitializeComponent() появится следующая строка.

this .ContextMenuStrip = this.fontSizeContextStrip;

Если выполнить приложение теперь, вы сможете изменить размер отображаемого текстового сообщения по щелчку правой кнопки мыши.

Замечание. С помощью свойства Context MenuStrip в контекстное меню можно включить любой элемент управления. Например, если в диалоговом окне контекстного меню создать объект Button (Кнопка), то соответствующий пункт Меню будет отображаться только тогда, когда щелчок будет выполнен в рабочей области кнопки.

 

Проверка состояния элементов меню

Члены типа ToolStripMenuItem позволяют проверить состояние элемента меню, сделать его доступным или скрытым. В табл. 19.11 даются описания некоторых из наиболее интересных свойств этого типа.

Таблица 19.11. Члены типа ToolStripMenuItem

Давайте расширим ваше контекстное меню так, чтобы в нем рядом с выбранным в настоящий момент пунктом меню отображалась отметка выбора. Установить отметку для данного элемента меню очень просто (для этого нужно установить значение свойства Checked равным true). Однако для того, чтобы проследить, какой пункт меню должен быть отмечен, потребуется дополнительная программная логика. Одним из возможных подходов здесь является определение специальной переменной ToolStripMenuItem, которая будет представлять элемент, отмеченный в настоящий момент.

public class MainWindow: Form {

 …

  // Указывает отмеченный элемент.

 private ToolStripMenuItem currentCheckedItem;

}

Напомним, что размером текста по умолчанию является TextFontSize.FontSizeNormal. С учетом этого начальным отмеченным элементам в ToolStripMenuItem должен быть normalToolStripMenuItem. Измените конструктор формы так, как показано ниже.

public MainWindow() {

 // Наследуемый метод для центрирования формы.

 CenterToScreen();

 InitializeComponent();

 // Установка отметки выбора для элемента меню 'Средний'.

 currentCheckedItem = normalToolStripMenuItem;

 currentCheckedItem.Checked = true;

}

Теперь вы имеете возможность программно идентифицировать отмеченный в настоящий момент элемент, и последним из необходимых шагов будет обновление обработчика события ContextMenuItemSelection_Clicked(). В нем нужно снять отметку выбора с элемента, выбранного ранее, и отметить новый текущий объект ToolStripMenuItem в соответствии с новым выбором пользователя.

private void ContextMenuItemSelection_Clicked(object sender, EventArgs e) {

 // Удаление отметки выбора для элемента.

 currentCheckedItem.Checked = false;

 …

 if (miClicked.Name == "hugeToolStripMenuItem") {

  currFontSize = TextFontSize.FontSizeHuge;

  currentCheckedItem = hugeToolStripMenuItem;

 }

 if (miClicked.Name = "normalToolStripMenuItem") {

  currFontSize = TextFontSize.FontSizeNormal;

  currentCheckedItem = normalToolStripMenuItem;

 }

 if (miClicked.Name == "tinyToolStripMenuItem") {

  currFontSize = TextFontSize.FontSizeTiny;

  currentCheckedItem = tinyToolStripMenuItem;

 }

 // Установка отметки выбора для нового элемента.

currentCheckedItem.Checked = true;

 …

}

На рис. 19.15 показан законченный проект MenuStripApp в действии.

Исходный код. Проект MenuStripApp размещен в подкаталоге, соответствующем главе 19.

Рис. 19.15. Установка и удаление отметок выбора для элементов ToolStripMenuItem

 

В дополнение к системе меню многие формы предлагают поддержкустроки состояния, которая обычно размещается в нижней части формы. Строка состояния может делиться на любое число "панелей" с текстовой (или графической) информацией, содержащей пояснения для пунктов меню, текущее время или специальные данные приложения.

Хотя поддержка строк состояния (с помощью типа System.Windows.Forms. StatusBar) предлагается с момента появления платформы .NET, в .NET 2.0 вместо простого элемента StatusBar предлагается использовать новый тип StatusStrip. Подобно обычной строке состояния, StatusStrip может состоять из любого числа панелей, содержащих текстовые/графические данные, предоставленные типом ToolStripStatus. Однако StatusStrip может содержать и дополнительные элементы, например, следующего вида.

• ToolStripProgressBar – встроенный индикатор выполнения (хода задания).

• ToolStripDropDownButton – встроенная кнопка, отображающая при щелчке на ней раскрывающийся список вариантов выбора.

• ToolStripSplitButton – подобен ToolStripDropDownButton, но отображает элементы раскрывающегося списка только тогда, когда пользователь щелкает непосредственно в области раскрывающегося списка. ToolStripSplitButton предлагает также поведение, аналогичное обычной кнопке, и поэтому может поддерживать обработку события Click.

Для примера мы построим новый объект MainWindow, в котором поддерживается простое меню (Файл→Выход и Справка→О программе) и StatusStrip. Левая панель строки состояния будет использоваться для отображения строковых данных, соответствующих выбранному в настоящий момент элементу меню (например, при выборе пользователем элемента Выход в строке будет отображаться "Выход из приложения").

Средняя часть строки состояния будет отображать одну из двух динамически создаваемых значений, соответствующих текущему времени и текущей дате. Наконец, правая часть строки состояния будет представлять тип ToolStripDropDownButton, позволяющий пользователю переключиться с отображения даты на отображение времени и наоборот (да еще и с пиктограммой счастливого лица в придачу!). На рис. 19.16 показано окно приложения в своем окончательном варианте.

Рис. 19.16. Приложение StatusStrip

 

Создание системы меню

Создайте новый проект приложения Windows Forms с именем StatusStripApp. Разместите элемент управления MenuStrip в окне проектирования формы и создайте два пункта меню (Файл→Выход и Справка→О программе). После этого задайте обработку событий Click (щелчок) и MouseHover (задержка указателя мыши) для каждого из дочерних элементов меню (Выход и О программе) с помощью окна свойств.

Реализация обработчика событий Click для элемента Файл→Выход просто завершает работу приложения, а обработчик событий Click для Справка→О программе отображает окно сообщения MessageBox.

private void exitToolStripMenuItem_Click(object sender, EventArgs e) { Application.Exit(); }

private void aboutToolStripMenuItem_Click(object sender, EventArgs e) { MessageBox.Show("My StatusStripApp!"); }

Обработчики событий MouseHover, отображающие подходящие подсказки в левой панели StatusStrip, мы с вами обновим немного позже. Пока что оставьте их пустыми.

 

Настройка StatusStrip

Добавьте в окно проектирования формы элемент управления StatusStrip и поменяйте имя этого элемента управления на mainStatusStrip. Следует понимать, что по умолчанию StatusStrip не содержит вообще никаких панелей. Для добавления трех панелей можно использовать разные подходы.

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

• Добавить нужные элементы в диалоговом окне, появляющемся при выборе ссылки Edit Items (Редактирование элементов) из меню контекстного редактора StatusStrip (см. рис. 19.17).

• Добавить нужные элементы по одному с помощью раскрывающегося меню новых элементов StatusStrip (рис. 19.18).

Мы используем раскрывающееся меню новых элементов. С помощью этого меню добавьте два новых типа ToolStripStatusLabel, назначив им имена toolStripStatusLabelMenuState и toolStripStatusLabelClock, и тип ToolStripDropDownButton с именем toolStripDropDownButtonDateTime. Как и следует ожидать, в результате этого в файл *.Designer.cs будут добавлены новые члены-переменные и соответственно обновлен метод InitializeComponent().

Рис. 19.17. Контекстный редактор StatusStrip

Риc. 19.18. Добавление элементов с помощью раскрывающегося меню новых элементов StatusStrip

Заметьте, что StatusStrip поддерживает внутреннюю коллекцию для представления всех созданных панелей.

partial class MainForm {

 private void InitializeComponent() {

  …

  //

  // mainStatusStrip

  //

  this.mainStatusStrip.Items.AddRange(

   new System.Windows.Forms.ToolStripItem[] { this.toolStripStatusLabelMenuState, this.toolStripStatusLabelClock, this.toolStripDropDownButtonDateTime });

  …

 }

 private System.Windows.Forms.StatusStrip mainStatusStrip;

 private System.Windows.Forms.ToolStripStatusLabel toolStripStatusLabelMenuState;

 private System.Windows.Forms.ToolStripStatusLabel toolStripStatusLabelClock;

 private System.Windows.Forms.ToolStripDropDownButton toolStripDropDownButtonDateTime;

 …

}

Теперь в окне проектирования формы выберите ToolStripDropDownButton и добавьте два новых элемента меню День недели и Текущее время, соответственно назначив им имена dayoftheWeekToolStripMenuItem и currentTimeToolStripMenuItem (рис. 19.19).

Рис. 19.19. Добавление пунктов меню для элемента ToolStripDropDownButton

Чтобы настроить панели так, как показано на рис. 19.19, нужно установить подходящие значения для соответствующих свойств в окне свойств Visual Studio 2005. В табл. 19.12 для элементов StatusStrip предлагаются описания свойств, которые нужно установить, и событий, которые нужно обработать (вы, конечно, можете настроить панели так, как сочтете необходимым).

Значение свойства Image члена toolStripDropDownButtonDateTime может указывать на любой файл с изображением, размещенный на вашей машине (при этом, конечно, следует учитывать то, что слишком большие файлы изображений могут порождать проблемы). Для нашего примера вы можете использовать файл happyDude.bmp, предлагаемый вместе с загружаемым исходным кодом для этой книги (посетите раздел загрузки Web-узла Apress, размещенный по адресу ).

Таблица 19.12. Конфигурация панелей StatusStrip

Итак, проектирование нашего графического интерфейса пользователя завершено. Но, чтобы реализовать оставшиеся обработчики событий, мы с вами должны выяснить роль компонента Timer (таймер).

 

Работа с типом Timer

Напомним, что средняя часть строки состояния должна отображать текущее время или текущую дату, в зависимости от предпочтений пользователя.

Первым шагом на пути к достижению этой цели является добавление в форму члена-переменной Timer – компонента, вызывающего некоторый метод (указанный с помощью обработчика события Tick) через заданный интервал времени (указанный с помощью свойства Interval).

Перетащите компонент Timer в окно проектирования формы и переименуйте его в timerDateTimeUpdate. Используя окно свойств, установите значение свойства Interval равным 1000 (это значение в миллисекундах), а значение свойства Enabled – равным true (истина). Наконец, обработайте событие Tick. Перед реализацией обработчика событий Tick определите в проекте новый тип перечня с именем DateTimeFormat. Этот перечень будет использоваться для выяснения того, что должен отображать второй элемент ToolStripStatusLabel – текущее время или текущую дату.

enum DateTimeFormat {

 ShowClock,

 ShowDay

}

Построив перечень, обновите MainWindow так, как предлагается ниже.

public partial class MainWindow: Form {

 // Какой формат отображать?

 DateTimeFormat dtFormat = DateTimeFormat.ShowClock;

 …

 private void timerDateTimeUpdate_Tick(object sender, EventArgs e) {

  string panelInfo = "";

  // Создание текущего формата.

  if (dtFormat == DateTimeFormat.ShowClock) panelInfo = DateTime.Now.ToLongTimeString();

  else panelInfo = DateTime.Now.ToLongDateString();

  // Установка текста для панели.

  toolStripStatusLabelClock.Text = panelInfo;

 }

}

Обратите внимание на то, что обработчик события Timer использует тип DateTime. Здесь вы просто читаете текущее время или дату системы, используя свойство Now, и устанавливаете соответствующее значение для свойства Text члена-переменной toolStripStatusLabelClock.

 

Включение отображения

В этот момент обработчик событий Tick должен отобразить в панели toolStripStatusLabelClock текущее время, если значением по умолчанию члена-переменной DateTimeFormat является DateTimeFormat.ShowClock. Чтобы позволить пользователю переключаться между отображением даты и времени, обновите MainWindow так, как предлагается ниже (заметьте, что здесь также указано, какой из двух пунктов меню в ToolStripDropDownButton должен при этом отмечаться).

public partial class MainWindow: Form {

 // Какой формат отображать?

 DateTimeFormat dtFormat = DateTimeFormat.ShowClock;

 // Указывает отмеченный элемент.

 private ToolStripMenuItem currentCheckedItem;

 public MainWindow() {

  InitializeComponent();

  // Эти свойства можно также установить

  // в окне Properties.

  Text = "Пример StatusStrip";

  CenterToScreen();

  BackColor = Color.CadetBlue;

  currentCheckedItem = currentTimeToolStripMenuItem;

  currentCheckedItem.Checked = true;

 }

 …

 private void currentTimeToolStripMenuItem_Click(object sender, EventArgs e) {

  // Установка отметки и формата времени для панели.

  currentCheckedItem.Checked = false;

  dtFormat = DateTimeFormat.ShowClock;

  currentCheckedItem = currentTimeToolStripMenuItem;

  currentCheckedItem.Checked = true;

 }

 private void dayoftheWeekToolStripMenuItem_Click(object Sender, EventArgs e) {

  // Установка отметки и формата даты для панели.

  currentCheckedItem.Checked = false;

  dtFormat = DateTimeFormat.ShowDay;

  currentCheckedItem = dayoftheWeekToolStripMenuItem;

  currentCheckedIteim.Checked = true;

 }

}

 

Вывод подсказок для выбранных элементов меню

Наконец, нужно настроить первую панель так. чтобы она содержала текст подсказки для выбранного пользователем элемента меню. Вы знаете, что большинство приложений отображает в левой части строки состояния поясняющую информацию (например, "Выход из приложения"), соответствующую выбранному конечным пользователем пункту меню. Если вы обработали события MouseHover для всех элементов меню нижнего уровня в MenuStrip и ToolStripDropDownButton, то остается только присвоить подходящее значение свойству Text для члена-переменной toolStripStatusLabelMenuState, например:

private void exitToolStripMenuItem_MouseHover(object sender, EventArgs e) { toolStripStatusLabelMenuState.Text = "Выход из приложения"; }

private void aboutToolStripMenuItem_MouseHover(object sender, EventArgs e) { toolStripStatusLabelMenuState.Text = "Отображение информации о приложении"; }

private void dayioftheWeekToolStripMenuItem_MouseHover(object sender, EventArgs e) { toolStripStatusLabelMenuState.Text = "Отображение текущей даты."; }

private void currentTimeToolStripMenuItem_MouseHover(object sender, EventArgs e) { toolStripStatusLabelMenuState.Text = "Отображение текущего времени."; }

Итак, у вас есть обновленный проект для тестового запуска. Теперь при выборе пунктов меню вы должны видеть в первой панели элемента StatusStrip соответствующие строки с поясняющей информацией.

 

Состояние готовности

Наконец, нужно гарантировать, что при снятии указателя мыши с пункта меню пользователем в первой текстовой панели не останется "старая" подсказка, а будет отображено некоторое "типовое" сообщение (например: "Ожидание действий пользователя"). В текущем своем виде наше приложение оставит в строке текст, соответствующий ранее выбранному пункту меню, что может вызывать, по меньшей мере, недоумение пользователя. Чтобы исправить это, обработайте событие MouseLeave для элементов меню Выход, О программе, День недели и Текущее время. Но вместо генерирования нового обработчика события для каждого элемента, позвольте всем указанным элементам вызывать один метод с именем SetReadyPrompt().

private void SetReadyPrompt(object sender, EventArgs e) { toolStripStatusLabelMenuState.Text = "Ожидание действий пользователя."; }

В результате вы должны обнаружить, что первая панель возвращается к отображению этого типового сообщения, как только курсор мыши покидает пределы любого из четырех указанных выше элементов меню.

Исходный код. Проект StatusBarApp размещен в подкаталоге, соответствующем главе 19.

 

Тип ToolStrip в .NET2.0 предлагается использовать вместо типа ToolBar, предлагавшегося в рамках .NET 1.x и теперь считающегося устаревшим. Вы знаете, что панели инструментов обычно обеспечивают альтернативный способ активизации соответствующих пунктов меню. При щелчке пользователя на кнопке Сохранить, результат будет тем же, что и при выборе Файл→Сохранить из меню. Подобно MenuStrip и StatusStrip, тип ToolStrip может содержать множество разных элементов панели инструментов (возможности использования некоторых из них вы уже видели в предыдущих примерах).

• ToolStripButton

• ToolStripLabel

• ToolStripSplitButton

• ToplStripDropDownButton

• ToolStripSeparator

• ToolStripComboBox

• ToolStripTextBox

• ToolStripProgressBar

Подобно другим элементам управления Windows Forms, ToolStrip поддерживает встроенный редактор, который позволяет быстро добавить стандартные типы кнопок (File, Exit, Copy, Paste и т.д.), изменить поведение стыковки и встроить ToolStrip в ToolStripContainer (подробнее об этом чуть позже). Возможности поддержки ToolStrip в режиме проектирования демонстрируются на рис. 19.20.

Рис. 19.20. Возможности режима проектирования для ToolStrip

Подобно MenuStrip и StatusStrip, индивидуальные элементы управления ToolStrip добавляются во внутреннюю коллекцию ToolStrip с помощью свойства Items (элементы). Если щелкнуть на ссылке Insert Standard Items (Вставить стандартные элементы) встроенного редактора ToolStrip, то в метод InitializeComponent() будет добавлен массив производных от ToolStripItem типов, представляющих соответствующие элементы.

private void InitializeComponent() {

 …

 // Автоматически генерируемый программный код

 // для подготовки ToolStrip.

 this.toolStrip1.Items.AddRange(new System.Windows.Forms.ToolStripItem[] {

  this.newToolStripButton, this.openToolStripButton,

  this.saveToolStripButton, this.printToolStripButton,

  this.toolStripSeparator, this.cutToolStripButton,

  this.copyToolStripButton, this.pasteToolStripButton,

  this.toolStripSeparator, this.helpToolStripButton });

 …

}

Чтобы продемонстрировать работу с ToolStrip, в следующем приложении

Windows Forms создается тип ToolStrip, содержащий два типа ToolStripButton (с именами toolStripButtonGrowFont и toolStripButtonShrinkFont), тип ToolBarSeparator и тип ToolBarTextBox (с именем toolStripTextBoxMessage).

Конечный пользователь получает возможность ввести сообщение, которое будет отображено в окне формы с помощью ToolBarTextBox, а два типа ToolBarButton используются для того, чтобы увеличить или уменьшить размер шрифта. На рис. 19.21 показано результирующее окно проекта, который мы с вами собираемся построить.

Рис. 19.21. Приложение ToolStripApp в действии

Я надеюсь, что к этому моменту вы имеете достаточно информации о приемах работы в режиме проектирования формы в Visual Studio 2005, поэтому я не буду утомлять вас указаниями по поводу построения ToolStrip. Однако следует заметить, что каждый элемент ToolStripButton имеет свою пользовательскую (хотя и достаточно примитивную) пиктограмму, которая была создана с помощью редактора изображений Visual Studio 2005. Если вы захотите создать файл изображения для своего проекта, можете просто выбрать Project→Add New Item из меню, а затем в появившемся диалоговом окне выбрать Icon File (Файл пиктограммы), рис. 19.22.

Рис. 19.22. Вставка новых файлов изображений

После этого вы можете отредактировать свои изображения с помощью окна Colors и комплекта инструментов редактора изображений. Имея пиктограммы в наличии, вы можете связать их с типами ToolStripButton с помощью свойства Image в окне свойств. После того как вы сочтете внешний вид ToolStrip удовлетворительным, обработайте событие Click для каждого элемента ToolStripButton.

Вот соответствующий программный код метода InitializeComponent() для первого типа ToolStripButton (второй ToolStripButton выглядит почти так же).

private void InitializeComponent() {

 …

 //

  // toolStripButtonGrowFont

 //

 this.toolStripButtonGrowFont.DisplayStyle = System.Windows.Forms.ToolStripItemDisplayStyle.Image;

 this.toolStripButtonGrowFont.Image = ((System.Drawing.Image)(resources.GetObject("toolStripButtonGrowFont.Image")));

 this.toolStripButtonGrowFont.ImageTransparentColor = System.Drawing.Color.Magenta;

 this.toolStripButtonGrowFont.Name = "toolStripButtonGrowFont";

 this.toolStripButtonGrowFont.Text = "toolStripButton2";

 this.toolStripButtonGrowFont.ToolTipText = "Увеличить шрифт";

 this.toolStripButton.GrowFont.Click += new System.EventHandler(this.toolStripButtonGrowFont_Click);

 …

}

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

Остальной программный код чрезвычайно прост. В следующем обновленном MainWindow обратите внимание на то, что текущий размер шрифта ограничивается значениями из диапазона между 12 и 70.

public partial class MainWindow: Form {

 // Текущий, минимальный и максимальный размеры шрифта.

 int currFontSize = 12;

 const int MinFontSize =12;

 const int MaxFonfSize = 70;

 publiс MainWindow() {

  InitializeComponent();

  CenterToScreen();

  Text = string.Format("Выбранный вами размер шрифта: {0}", currFontSize);

 }

 private void toolStripButtonShrinkFont_Click(object sender, EventArgs e) {

  // Уменьшение размера шрифта на 5 и обновление экрана.

  currFontSize -= 5;

  if (currFontSize ‹= MinFontSize) currFontSize = MinFontSize;

  Text = string.Format("Выбранный вами размер шрифта: {0}", currFontSize);

  Invalidate();

 }

 private void toolStripButtonGrowFont_Click(object sender, EventArgs e) {

  // Увеличение размера шрифта на 5 и обновление экрана.

  currFontSize += 5;

  if (currFontSize ›= MaxFontSize) currFontSize = MaxFontSize;

  Text = string.Format("Выбранный вами размер шрифта: {0}", currFontSize);

  Invalidate();

 }

 private void MainWindow_Paint(object sender, PaintEventArgs e) {

  // Отображение сообщения пользователя.

  Graphics g = e.Graphics;

  g.DrawString(toolStripTextBoxMessage.Text, new Font("Times New Roman", currFontSize), Brushes.Black, 10, 60);

 }

}

В качестве заключительного штриха, чтобы гарантировать, что пользовательское сообщение будет обновлено, как только ToolStripTextBox утратит фокус, обработайте событие LostFocus и вызовите Invalidate() для формы в рамках сгенерированного обработчика события.

public partial class MainWindow: Form {

 …

 public MainWindow() {

  …

  this.toolStripTextBoxMessage.LostFocus += new EventHandler(toolStripTextBoxMessage_LostFocus);

 }

 void toolStripTextBoxMessage_LostFocus(object sender, EventArgs e) {

  Invalidate();

 }

 …

}

 

Работа с ToolStripContainer

Типы ToolStrip, если требуется, можно настроить так, чтобы они могли "стыковаться" с любой стороной и даже со всеми сторонами содержащей их формы. Для иллюстрации того, как это сделать, щелкните правой кнопкой мыши на своем элементе ToolStrip в окне проектирования фирмы и выберите Embed In ToolStripContainer (Встроить в контейнер). После этого ToolStrip будет помещен В ToolStripContainer. Для нашего примера выберите опцию Dock Fill In Form (Стыковка ко всей форме) риc. 10.23.

Рис. 19.23. Стыковка ToolStripContainer ко всей форме

Запустив эту модификацию приложения, вы увидите, что ToolStrip может перемещаться и стыковаться к любой стороне контейнера. Однако ваше пользовательское сообщение исчезнет. Причина в том, что типы ToolStripContainer являются для формы дочерними элементами управления. Так что графическое отображение на самом деле выполняется, но вывод скрыт контейнером, который сейчас накрывает всю клиентскую область формы.

Чтобы решить возникшую проблему, нужно обработать событие Paint для ToolStripContainer, а не для формы. Сначала найдите событие Paint формы в окне свойств и щелкните правой кнопкой на текущем обработчике событий. Из контекстного меню выберите Reset (рис. 19.24).

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

Теперь обработайте событие Paint для ToolStripContainer и переместите имеющийся программный код отображения из обработчика события Paint формы в обработчик события Paint контейнера. После этого можете удалить (теперь пустой) метод MainWindow_Paint().

Рис. 19.24. Переустановка события

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

public partial class MainWindow: Form {

 …

 void toolStripTextBoxMessage_LostFocus(object sender, EventArgs e) {

  toolStripContainer1.Invalidate(true) ;

 }

 private void toolStripButtonShrinkFont_Click(object sender, EventArgs e) {

  …

  toolStripContainer1.Invalidate(true);

 }

 private void toolStripButtonGrowFont_Click(object sender, EventArgs e) {

  toolStripContainer1.Invalidate(true);

 }

 // Теперь "закрашивается" контейнер, а не форма!

 private void ContentPanel_Paint(object sender, PaintEventArgs e) {

  Graphics g = e.Graphics;

  g.DrawString(toolStripTextBoxMessage.Text, new Font("Times New Roman", currFontSize), Brushes.Black, 10, 60);

 }

}

Конечно, следует проверить разные конфигурации ToolStripContainer, чтобы понять, как все это работает. Подробности по документации .NET Framework 2.0 SDK вам придется изучать самостоятельно. На рис. 19.25 показано окно завершенного проекта.

Исходный код. Проект ToolStripApp размещен в подкаталоге, соответствующем главе 19.

Рис. 19.25. Приложение ToolStripApp с допускающим стыковку ToolStrip

 

Чтобы завершить краткое знакомство с Windows Forms, давайте обсудим то, как настроить форму на работу в качестве родительского объекта для любого числа дочерних окон (т.е. в качестве MDI-контейнера). MDI-приложения дают пользователям возможность открывать множество дочерних окон в рамках одного и того же главного окна. В мире MDI каждое окно представляет свой "документ" приложения. Например, Visual Studio 2005 является МDI-приложением, поскольку вы можете открыть множество документов в рамках одного экземпляра этого приложения.

При построении МDI-приложения с помощью Windows Forms первой задачей оказывается (конечно же) создание нового приложения Windows. Исходная форма в приложении обычно содержит систему меню, которая позволяет создавать новые документы (например, содержит пункт Файл→Создать) и упорядочивать существующие открытые окна (каскадом, по вертикали или по горизонтали).

Для создания дочерних окон обычно определяется форма-прототип, играющая роль основы для каждого дочернего окна. Поскольку Form является типом класса, любые приватные данные, определенные в дочерней форме, будут для конкретного экземпляра уникальными. Например, при созданий MDI-приложения текстового редактора для отображения текста можно создать дочернюю форму, поддерживающую StringBuilder. Если пользователь создаст пять новых дочерних окон, каждая соответствующая форма будет поддерживать свой собственный экземпляр StringBuilder, которыми можно будет управлять независимо.

Кроме того, MDI-приложения позволяют "объединять" меню. Как уже упоминалось, родительские окна обычно имеют свои системы меню, которые позволяют пользователю создавать и упорядочивать дополнительные дочерние окна. Но что будет в том случае, когда дочернее окно имеет свою систему меню? Если пользователь максимизирует конкретное дочернее окно, то система меню этого дочернего окна должна "поглотиться" родительской формой, чтобы пользователь получил возможность активизировать элементы каждой из имеющихся систем меню. Пространство имен Windows Forms определяет ряд свойств, методов и событий, позволяющих программное слияние систем меню. Имеется также система "слияния по умолчанию", которая оказывается вполне подходящей во многих типичных случаях.

 

Создание родительской формы

Для демонстрации основ процесса построения MDI-приложения создайте новое приложение Windows, назвав его SimpleMdiApp. При этом почти вся MDI-ин-фраструктура может быть назначена исходной форме с помощью различных инструментов проектирования. Сначала найдите свойство IsMdiContainer в окне свойств и установите его равным true (истина). В результате в окне проектирования формы область клиента изменится – теперь она будет визуально представлять контейнер дочернего окна.

Затем разместите в главной форме новый элемент управления MenuStrip. В этом меню укажите три элемента высшего уровня с названиями Файл, Окно и Упорядочить окна. Меню Файл содержит два подчиненных элемента с названиями Создать и Выход. Меню Окно не содержит никаких подчиненных элементов, потому что при создании пользователем дополнительных дочерних окон новые элементы предполагается добавлять программно. Наконец, меню Упорядочить окна определяет три подчиненных элемента с названиями Каскадом, По вертикали и По горизонтали.

После создания меню пользовательского интерфейса обработайте событие Click для пунктов меню Выход, Создать, Каскадом, По вертикали и По горизонтали (напомним, что меню Окно пока что не имеет никаких подчиненных элементов). Обработчик элемента Файл→Создать мы реализуем в следующем разделе главы, а сейчас рассмотрим программный код для остальных элементов меню.

// Обработка события Файл | Выход и упорядочение дочерних окон.

private void cascadeToolStripMenuItem_Click(object sender, EventArgs e) {

 LayoutMdi (MdiLayout.Cascade) ;

}

private void verticalToolStripMenuItem_Click(object sender, EventArgs e) {

 LayoutMdi (MdiLayout.TileVertical);

}

private void horizontalToolStripMenuItem_Click(object sender, EventArgs e) {

 LayoutMdi (MdiLayout.TileHorizontal) ;

}

private void exitToolStripMenuItem_Click (object sender, EventArgs e) {

 Application.Exit();

}

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

Перед тем как перейти к обсуждению процесса создания дочерних форм, установите еще одно свойство MenuStrip. Свойство MdiWindowListItem используется доя того, чтобы выяснить, какой пункт меню наивысшего уровня должен использоваться для автоматического списка имен всех дочерних икон при соответствующем выборе из меню. Присвойте значение этого свойства члену-переменной windowToolStripMenuItem. По умолчанию для этого списка используется значение дочернего свойства Text с числовым суффиксом (т.е. Form1, Form2, Form3 и т.д.).

 

Создание дочерней формы

Теперь, когда у вас есть оболочка MDI-контейнера, нужно создать дополнительную форму, выполняющую роль прототипа для данного дочернего окна. Начните со вставки нового типа Form в имеющийся проект (используйте Project→Add Windows Form), присвойте этому типу имя ChidPrototypeForm и обработайте для него событие Сlick. В сгенерированном обработчике события путем случайного выбора установите цвет фона для области клиента. Кроме того, выведите "преобразованное в строку" значение Color (цвет) нового объекта в полосу заголовка дочернего окна. Следующая программная логика реализует поставленные задачи.

private void ChildPrototypeForm_Click(object sender, EventArgs e)

 // Получение трех случайных чисел.

 int r, g, b;

 Random ran = new Random();

 r = ran.Next(0, 255);

 g = ran.Next(0, 255);

 b = ran.Next(0, 255);

 // Создание цветового значения для фона.

 Color currColor = Color.FromArgb(r, g, b);

 this.BackColor = currColor;

 this.Text = currColor.ToString();

}

 

Создание дочерних окон

Заключительным шагом должно быть создание подходящей реализации обработчика событий Файл→Создать родительской формы. Теперь, когда дочерняя форма определена, соответствующая программная логика оказывается очень простой: нужно создать и отобразить новый экземпляр типа ChildPrototypeForm. Кроме того, нужно установить значение свойства MdiParent дочерней формы, указывающее на содержащую ее форму (в данном случае это ваше главное окно). Вот как должны выглядеть соответствующие модификации программы.

private void newToolStripMenuItem_Сlick(object sender, EventArgs e) {

 // Создание нового дочернего окна.

 ChildPrototypeForm newChild = new ChildPrototypeForm();

 // Ссылка на родительскую форму для данного дочернего окна.

 newChild.MdiParent = this;

 // Отображение новой формы .

 newChild . Show();

}

Замечание. Дочерняя форма имеет возможность использовать свойство MdiParent непосредственно, когда требуется выполнить какие-то действия (или организовать сообщение) с родительским окном.

При тестировании этого приложения начните с создания нескольких дочерних окон и, щелкнув на каждом из них, создайте уникальные цвета для их фона, Если теперь рассмотреть подчиненные элементы меню Окно, вы должны обнаружить, что там представлена и учтена каждая дочерняя форма. Точно так же с помощью элементов меню Упорядочить окна вы можете дать указание родительской форме разместить дочерние формы по вертикали, горизонтали или каскадом. На рис. 19.26 показано окно готового приложения.

Рис. 19.26. Окно MDI-приложения

Исходный код. Проект SimpleMdiApp размещен в подкаталоге, соответствующем главе 19.

 

Многие из методов визуализации, определенные объектом System.Drawing. Graphics, требуют указать позицию или область, в которой требуется отобразить данный элемент. Например, метод DrawString() требует, чтобы вы указали позицию, в которой нужно отобразить текстовую строку в производном от Control типе. Метод DrawString() является перегруженным, поэтому параметр позиции можно указать как в виде координаты (х, у), так и в виде размеров "бокса", в котором нужно выполнить визуализацию. Другие методы GDI+ могут требовать, чтобы вы указали ширину и высоту данного элемента или внутренние границы геометрического образа.

Таблица 20.2. Базовые типы пространства имен System.Drawing 

Для указания такой информации пространство имен System.Drawing определяет типы Point, Rectangle, Region и Size. Очевидно, что тип Point (точка) представляет координату (x, у). Типы Rectangle (прямоугольник) содержат пару точек, представляющих левый верхний и нижний правый угол прямоугольной области. Типы Size (размер) подобны Rectangle, но эта структура представляет конкретные размеры, используя длину и ширину. Наконец, типы Region (регион) предлагают способ представления непрямоугольных областей.

Члены-переменные, используемые типами Point, Rectangle, Region и Size, внутренне представлены целочисленными данными. Если вам потребуется более "тонкая" детализация, можете использовать, соответственно, типы PointF, RectangleF и SizeF, которые (как вы можете догадаться) отображаются в соответствующие значения с плавающим разделителем. Но, независимо от внутреннего представления, все эти типы имеют аналогичные множества членов, включая ряд перегруженных операторов.

 

Тип Point(F)

Первым утилитарным типом, о котором вам следует знать, является тип System.Drawing.Point(F). В отличие от иллюстративных типов Point, создававшихся в предыдущих главах, тип Point(F) GDI+ поддерживает целый ряд очень полезных членов, включая следующие:

• +, -, ==, != – перегруженные варианты различных C#-операций;

• X, Y – обеспечивают доступ к соответствующим внутренним значениям (х, у) типа Point;

• IsEmpty – возвращает true (истина), если x и у установлены равными 0.

Для иллюстрации работы с утилитарными типами GDI+ рассмотрите следующее консольное приложение (названное UtilTypes), в котором используется тип System.Drawing.Point (не забудьте установить ссылку на System.Drawing.dll).

using System;

using System.Drawing;

namespace UtilTypes {

 public class Program {

  static void Main(string[] args) {

   // Создание и смещение точки.

   Point pt = new Point(100, 72);

   Console.WriteLine(pt);

   pt.Offset(20, 20);

   Console.WriteLine(pt);

   // Перегруженные операции Point.

   Point pt2 = pt;

   if (pt == pt2) WriteLine ("Точки одинаковы");

   else WriteLine("Точки различны");

   // Изменение значения X для pt2 .

   pt2.X = 4000;

    // Отображение каждого значения X.

   Console.WriteLine("Первая точка: {0} ", pt);

   Console.WriteLine("Вторая точка: {0} ", рt2);

   Console.ReadLine();

  }

 }

}

 

Тип Rectangle(F)

Типы Rectangle, подобно Point, оказываются полезными во многих приложениях (и особенно в GUI-приложениях). Одним из наиболее полезных методов типа Rectangle является метод Contains(). Этот метод позволяет выяснить, находится ли данный тип Point или Rectangle в рамках границ некоторого другого объекта. Позже в этой же главе вы увидите, как использовать этот метод для проверки попадания в область GDI-изображений. А пока что рассмотрите следующий простой пример.

static void Main(string[] args) {

 …

 // Вначале Point находится вне прямоугольника .

 Rectangle r1 = new Rectangle(0, 0, 100, 100);

 Point pt1 = new Point(101, 101);

 if (r1. Contains( pt3)) Console.WriteLine("Point находится внутри прямоугольника!");

 else Console.WriteLine("Point находится вне прямоугольника!");

 // Теперь поместим Point в прямоугольник.

 pt3.X = 50;

 pt3.Y = 30;

 if (r1. Contains( pt3)) Console.WriteLine("Point находится внутри прямоугольника!");

 else Console.WriteLine("Point находится вне прямоугольника!");

 Console.ReadLine();

}

 

Класс Region

Тип Region представляет внутреннюю часть геометрической фигуры. С учетом этого становится ясно, почему конструкторы класса Region требуют, чтобы вы предоставили им на вход некоторый уже существующий геометрический шаблон. Предположим, например, что вы создали прямоугольник размером 100×100 пикселей. Чтобы получить доступ к внутренней области прямоугольника, вы можете написать следующее.

// Получение внутренней части прямоугольника.

Rectangle r = new Rectangle(0, 0, 100, 100);

Region rgn = new Region(r);

Имея внутреннюю часть фигуры, вы можете манипулировать ею с использованием различных членов, наподобие следующих:

• Complement() – изменяет данный объект Region на часть указанного графического объекта, не пересекающуюся с данным объектом Region;

• Exclude() – изменяет данный объект Region на ту его часть, которая не пересекается с указанным графическим объектом;

• GetBounds() – возвращает Rectangle(F), который представляет прямоугольный регион, ограничивающий данный объект Region;

• Intersect() – изменяет данный объект Region на его пересечение с указанным графическим объектом:

• Transform() – трансформирует данный объект Region с помощью указанного объекта Matrix;

• Union() – изменяет данный объект Region на его объединение с указанным графическим объектом;

• Translate() – сдвигает координаты данного объекта Region на указанную величину.

Надеюсь, что вы получили общее представление об этих координатных примитивах. Если же вам нужны подробности, обратитесь к документации .NET Framework 2.0 SDK.

Замечание. Типы Size и SizeF заслуживают небольшого дополнительного комментария. Каждый из этих типов определяет свойства Height (высота) и Width (ширина), а также набор перегруженных операций.

Исходный код. Проект UtilTypes размещен в подкаталоге, соответствующем главе 20.

 

Наиболее общий способ получения объекта Graphics заключается во взаимодействии с событием Paint. Вспомните из предыдущей главы о том, что класс Control определяет виртуальный метод с именем OnPaint(). Чтобы форма отображала графические данные на своей поверхности, вы можете переопределить этот метод и извлечь объект Graphics из входного параметра PaintEventArgs. Для примера создайте новое приложение Windows Forms с именем BasicPaintForm и обновите полученный класс Form так, как предлагается ниже.

public partial class MainForm: Form {

 public MainForm() {

  InitializeComponent();

  CenterToScreen();

  this.Text = "Basic Paint Form";

 }

 protected override void OnPaint(PaintEventArgs e) {

   // При переопределении OnPaint() не забудьте вызвать

  // реализацию базового класса.

  base.OnPaint(e);

  // Получение объекта Graphics из поступившего на вход

  // PaintEventArgs.

  Graphics g = e.Graphics;

  // Визуализация текстового сообщения с заданными

  // цветом и шрифтом.

  g.DrawString("Привет GDI + ", new Font("Times New Roman", 20), Brushes. Green, 0, 0);

 }

}

Но, хотя переопределение OnPaint() и допустимо, более типичным подходом является обработка события Paint с помощью связанного делегата PaintEventHandler (именно это делается по умолчанию в Visual Studio 2005 при обработке событий с помощью окна свойств). Данный делегат может указывать на любой метод, получающий в качестве первого параметра System.Object, а в качестве второго – PaintEventArgs. В предположении о том, что вы обработали событие Paint (с помощью инструментов режима проектирования Visual Studio 2005 или в программном коде вручную), вы снова можете извлечь объект Graphics из поступающего на вход PaintEventArgs. Вот соответствующим образом модифицированный программный код.

public partial class MainForm: Form {

 public MainForm() {

  InitializeComponent();

  CenterToScreen();

  this.Text = "Basic Paint Form";

  // В Visual Studio 2005 поместите этот программный код

  // в InitializeComponent().

  this.Paint += new PaintEventHandler(MainForm_Paint);

 }

 private void MainForm_Paint(object sender, PaintEventArgs e) {

  Graphics g = e.Graphics;

  g.DrawString("Привет GDI+", new Font("Times New Roman", 20), Brushes.Green, 0, 0);

 }

}

Независимо от того, как вы отвечаете на событие Paint, следует знать, что событие Раint генерируется всегда, когда окно становится "грязным". Вы, возможно, знаете, что окно считается "грязным", если переопределяется его размер, окно (или его часть) открывается из-под другого окна, или окно сначала минимизируется, а затем восстанавливается. Во все случаях, когда требуется перерисовка формы, платформа .NET гарантирует, что обработчик события Paint (или переопределенный метод OnPaint() будет вызван автоматичеcки.

 

Обновление области клиента формы

В ходе выполнения приложения GDI+ может возникнуть необходимость в явном вызове события Paint вместо ожидания того, что окно станет "естественно грязным". Например, вы создаете программу, которая позволяет пользователю выбрать подходящий рисунок из набора точечных изображений в пользовательском диалоговом окне. После закрытия диалогового окна нужна отобразить выбранный пользователем рисунок в области клиента формж. Очевидно, если ждать, когда окно станет "естественно грязным", пользователь не увидит изменений до того, как изменятся размеры окна или его часть откроется из-под другого окна. Чтобы вызвать перерисовку окна программно, просто вызовите наследуемый метод Invalidate().

public partial class MainForm: Form {

 …

 private void MainForm_Paint(object sender, PaintEventArgs e) {

  Graphics g = e.Graphics;

  // Здесь выполняется визуализация изображения.

 }

 private void GetNewBitmap() {

  // Отображение диалогового окна и получение нового образа.

  // Перерисовка клиентской области.

  Invalidate();

 }

}

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

// Перерисовка прямоугольной части формы.

private void UpdateUpperArea() {

 Rectangle myRect = new Rectangle(0, 0, 75, 150);

 Invalidate(myRect);

}

 

Доступ к объекту Graphics вне обработчика Paint

В некоторых редких случаях может понадобиться доступ к объекту Graphics вне контекста обработчика события Paint. Предположим, например, что нужно перерисовать небольшой круг с центром в точке (х, у), где был выполнен щелчок кнопки мыши. Чтобы получить действительный объект Graphics в рамках контекста обработчика событий MouseDown, можно, например, вызвать статический метод Graphics.FromHwnd(). Имея опыт использования Win32, вы можете знать, что HWND является структурой данных, представляющей окно Win32. В рамках платформы .NET наследуемое свойство Handle извлекает соответствующую структуру HWND, которую затем можно использовать в качестве параметра для Graphics. FromHwnd().

private void MainForm_MouseDown(object sender, MouseEventArgs e) {

  // Получение объекта Graphics через Hwnd.

 Graphics g = Graphics .FromHwnd (this.Handle);

 // Рисование круга 10*10 по щелчку мыши.

 g.FillEllipse(Brushes.Firebrick, e.X, e.Y, 10, 10);

 // Освобождение объектов Graphic, созданных напрямую.

 g.Dispose();

}

Эта логика отображает круг за пределами обработчика OnPaint(), но очень важно понимать, что когда выполняется обновление формы, все такие круги стираются! Это разумно, поскольку соответствующая визуализация выполнялась в контексте события MouseDown. Значительно лучшим подходом Является создание в обработчике события MouseDown нового типа Point, который добавляется к некоторой внутренней коллекции (например, List‹T›), и только затем вызывается Invalidate(). Тогда обработчик события Раint может просто "пройти" по коллекции и перерисовать каждый Point.

public partial class MainForm: Form {

 // Используется для хранения всех Point.

 private List‹Point› myPts = new List‹Point›();

 publiс MainForm() {

  …

  this.MouseDown += new MouseEventHandler(MainForm_MouseDown);

 }

 private void MainForm_MouseDown(object sender, MouseEventArgs e) {

  // Добавление в коллекцию.

  myPts.Add(new Point(e.X, e.Y));

  Invalidate();

 }

 private void MainForm_Paint(object sender, PaintEventArgs e) {

  Graphics g = e.Graphics;

  g.DrawString("Привет GDI+", new Font("Times New Roman", 20), new SolidBrush(Color.Black), 0, 0);

  foreach(Point p in myPts) g.FillEllipse(Brushes.Firebrick, p.X, p.Y, 10, 10);

 }

}

При таком подходе уже отображенные круги будут оставаться на месте, поскольку графическая визуализация обрабатывается в рамках события Paint. На рис. 20.1 показано окно тестового запуска этого приложения.

Рис 20.1. Простое графическое приложение

Исходный код. Проект BasiсPaintForm размещен в подкаталоге, соответствующем главе 20.

 

Освобождение объекта Graphics

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

• Если объект Graphics был создан вами непосредственно, после окончания его использования его следует освободить.

• Если вы ссылаетесь на существующий объект Graphics, его освобождать не следует.

Для того чтобы это стало более понятным, рассмотрите следующий обработчик события Paint.

private void MainForm Paint(object sender, PaintEventArgs e) {

 // Загрузка локального файла *. jpg.

 image myImageFile = Image.FromFile("landscape.jpg");

  // Создание нового объекта Graphics на основе изображения.

 Graphics imgGraphics = Graphics.FromImage(myImageFile);

  // Визуализация новых данных.

 imgGraphics.FillEllipse(Brushes.DarkOrange, 50, 50, 150, 150);

 // Нанесение изображения на форму.

 Graphics g = e.Graphics;

 g.DrawImage(myImageFile, new PointF(0.0F, 0.0F));

 // Освобождение созданного нами объекта Graphics.

 imgGraphics.Dispose();

}

На данном этапе обсуждения не беспокойтесь о том, что некоторые элементы программной логики GDI+ могут быть для вас не вполне понятны. Однако обратите внимание на то, что здесь объект Graphics получается из файла *.jpg, загружаемого (с помощью статического метода Graphics.FromImage()) из локального каталога приложения. Поскольку объект Graphics создается явно, после окончания использовании этого объекта лучше использовать Dispose(), чтобы освободить внутренние ресурсы и сделать их снова доступными для использования другими компонентами системы.

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

В связи с этим заметим, что если вы забудете вызвать метод Dispose() для объекта, реализующего IDisposable, внутренние ресурсы будут освобождены позже, при обработке объекта сборщиком мусора (см. главу 5). В этом смысле освобождение объекта imgGraphics, строго говоря, не является необходимым. Так что, хотя явное освобождение объектов GDI+, созданных вами непосредственно, делает программный код совершеннее, мы с вами, чтобы сделать примеры программного кода в этой главе более краткими, не будем освобождать каждый тип GDI+ вручную.

 

Нашей следующей задачей будет рассмотрение координатных систем GDI+. В GDI+ определяются три разные системы координат, которые используются средой выполнения, при определении места размещения и размеров содержимого визуализации. Во-первых, есть так называемые мировые координаты (или внешние координаты). Мировые координаты представляют абстракцию размеров данного типа GDI+, независимую от единиц измерения. Например, при прорисовке прямоугольника с указанием для размерности (0, 0, 100, 100), вы на самом деле указываете прямоугольник размером 100×100 "единиц". Как вы можете догадаться, по умолчанию "единица" – это пиксель, однако ей можно назначить и другую единицу измерения (дюйм, сантиметр и т.п.),

Далее, есть страничные координаты (координаты страницы). Страничные координаты представляют смещение в применении к оригинальным мировым координатам. Это удобно тогда, когда вы не хотите вычислять смещение в своем программном коде вручную (вы не обязаны это делать). Например, если у вас есть форма, которая должна оставаться в границах 100×100 пикселей, вы можете указать страничную координату (100*100), чтобы визуализация выполнялась относительно точки (100*100). Тогда в своем базовом коде вы сможете просто указать мировые координаты (избежав, тем самым, необходимости вручную учитывать смещение),

Наконец, есть приборные координаты (координаты устройства). Приборные координаты представляют результат применения страничных координат к оригинальным мировым координатам. Эта координатная система используется для определения того, где именно будет показан соответствующий тип GDI+. При программировании с помощью средств GDI+ программист обычно мыслит в терминах мировых координат, которые являются базой для определения размеров и места размещения типа GDI+. Для визуализации в мировых координатах не требуется никаких специальных программных ухищрений – нужно просто передать значения измерений текущей операции визуализации,

void MainForm_Paint(object sender, PaintEventArgs s) {

 // Визуализация прямоугольника в мировых координатах.

 i.Graphics g = е.Graphics;

 g.DrawRectangle(Pens.Black, 10, 10, 100, 100);

}

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

Если перед визуализацией своей программной логики GDI+ вы хотите применить какие-то преобразования, вы должны использовать подходящие члены типа Graphics (например, метод TranslateTransform()), чтобы перед тем, как выполнить визуализацию, указать "страничные координаты" в существующей системе мировых координат. В результате устанавливаются приборные координаты, которые будут использоваться при выводе типа GDI+ на соответствующее устройство.

private void MainForm_Paint(object sender, PaintEventArgs e) {

 // Указание смещения (10 * 10) для страничных координат.

 Graphics g = е.Graphics;

 g.TranslateTransform(10, 10);

 g.DrawRectangle(10, 10, 100, 100);

}

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

 

Единица измерения, предлагаемая по умолчанию

В GDI+ единицей измерения по умолчанию является пиксель. Начало координат размещается в левом верхнем углу с увеличением оси абсцисс вправо, а оси ординат – вниз (рис. 20.2).

Рис. 20.2. Система координат GDI+, предлагаемая по умолчанию

Поэтому, если вы отобразите Rectangle с использованием пера толщиной в 5 пикселей и красного цвета, как показано ниже.

void MainForm_Paint (object sender, PaintEventArgs e) {

 // Установка мировых координат с использованием единиц измерения,

 // предлагаемых по умолчанию.

 Graphics g = е.Graphics;

 g.DrawRectangle(newPen(Color.Red, 5), 10, 10, 100, 100);

}

вы должны увидеть квадрат, смещенный на 10 пикселей вниз и вправо относительно верхнего и левого края клиентской области формы, как показано на рис. 20.3.

Рис. 20.3. Визуализация в пиксельных единицах

 

Выбор альтернативной единицы измерения

Если вы не хотите выполнять визуализацию изображений с использованием пиксельных единиц измерения, вы имеете возможность изменить эту принятую по умолчанию установку с помощью свойства PageUnit объекта Graphics. Свойству PageUnit можно присвоить любое значение из перечня GraphicsUnit.

public enum GraphicsUnit {

 // Мировые координаты.

 World,

 // Пиксель для видеодисплея и 1/100 дюйма для принтера.

 Display,

 // Пиксель.

 Pixel,

 // Стандартная точка принтера (1/72 дюйма).

 Point,

 // Дюйм.

 Inch,

 // Стандартная единица документа (1/300 дюйма).

 Document,

 // Миллиметр.

 Millimeter

}

Чтобы проверить, как изменяется базовая единица измерения, модифицируйте имеющийся программный код так, как предлагается ниже.

private void MainForm_Paint(object sender, PaintEventArgs e) {

 // Отображение прямоугольника а дюймах, а не в пикселях…

 Graphics g = e.Graphics;

 g.PageUnit = GraphicsUnit.Inch;

 g.DrawRectangle(new Pen(Color.Red, 5), 0, 0, 100, 100);

}

Вы должны увидеть совершенно другой прямоугольник, как показано на рис. 20.4.

Рис. 20.4. Визуализация в дюймах

Причина того, что здесь более 90% области клиента формы занято темным (красным) цветом, заключается в указании пера "шириной" в 5 дюймов! Сам прямоугольник теперь имеет размеры 100×100 дюймов, и тот маленький светлый прямоугольник, который вы видите на рисунке в правом нижнем углу, является левым верхним углом большого внутреннего прямоугольника.

 

Изменение начала координат

Напомним, что при использовании координат и единиц измерения, предлагаемых по умолчанию, точка (0, 0) находится в левом верхнем углу соответствующей области. Часто это и является именно тем, что требуется, но что делать, если вам нужно поменять точку, относительно которой выполняется визуализация? Предположим, например, что ваше приложение всегда должно (по какой-то причине) оставлять пустой полосу шириной в 100 пикселей вдоль границы области клиента формы. Тогда вы должны гарантировать, чтобы все операции GDI+ выполнялись в соответствующих пределах внутренней области,

Один из подходов, который можно при этом использовать, заключается в добавлении смещения вручную. Конечно, утомительно добавлять значения смещениях каждой операции визуализации. Значительно удобнее (и проще) было бы использовать свойство, которое, по сути, говорило бы следующее: "Хотя я даю указание отобразить прямоугольник с началом координат в точке (0, 0), вы должны использовать для начала координат точку (100, 100)". Это должно сильно "упростить вам жизнь", поскольку вы сможете указать параметры размещения без модификаций,

В рамках GDI+ вы можете указать точку начала координат, установив значение трансформации с помощью метода TranslateTransform() (класса Graphics), позволяющего указать страничные координаты, которые будут применяться к вашим оригинальным мировым координатам, например:

void MainForm_Paint(object sender, PaintEventArgs e) {

 Graphics g = e.Graphics;

 // Установка смещения (100, 100) для страничных координат.

 g.TranslateTransform(100, 100);

 // Значениями мировых координат остаются (0, 0, 100, 100),

 // но приборные координаты теперь равны (100, 100, 200, 200).

 g.DrawRectangle(new Pen(Color.Red, 5), 0, 0, 100, 100);

}

Здесь вы устанавливаете для мировых координат значения (0, 0, 100, 100). Однако для страничных координат вы указали смещение (100, 100). Поэтому для приборных координат будут использоваться значений (100, 100, 200, 200). Таким образам, хотя вызов DrawRectangle() выглядит так, как будто вы размещаете прямоугольник в левом верхнем углу формы, результат будет выглядеть так, как показано на рис. 20.5.

Рис. 20.5. Результат применения смещения страницы

Чтобы вы имели возможность поэкспериментировать с некоторыми способами изменения координатной системы GDI+, в файле с исходным текстом примеров этой книги (для его загрузки посетите раздел загрузки Web-узла Apress, размещенного по адресу ) есть пример приложения с именем CoorSystem. В этом приложении с помощью двух меню вы можете менять начало координат и единицу намерения (рис. 20.6).

Рис. 20.6. Изменение начала координат и единицы изменения

Теперь, когда вы имеете представление о роли базовых трансформаций для определения координат визуализации имеющегося GDI-типа на целевом устройстве, следующей задачей нашего обсуждения будет работа с цветовыми значениями.

Исходный код. Проект CoorSystem размещен в подкаталоге, соответствующем главе 20.

 

Многие методы визуализации, определенные классом Graphics, требуют от вас указания цвета, который должен использоваться в процессе рисования. Структура System.Drawing.Color представляет цветовую константу ARGB (от Alpha-Red-Green-Blue – альфа, красный, зеленый, синий). Функциональные возможности типа Color (цвет) представляются рядом статических доступных только для чтения свойств, возвращающих конкретный тип Color.

// Один из множества встроенных цветов…

Color с = Color.PapayaWhip;

Если стандартные цветные значения вам не подойдут, вы можете создать новый тип Color и указать для него значения A, R, G и В, используя метод FromArgb().

// Указание ARGB вручную.

Color myColor = Color.FromArgb(0, 255, 128, 64);

Используя метод FromName(), вы можете также сгенерировать тип Color по данному строковому значению. Строковый параметр должен при этом соответствовать одному из членов перечня KnownColor (который содержит значения для различных цветовых элементов Windows, например, таких как KnownColor.WindowFrame и KnownColor.WindowText).

// Получение Color по известному имени.

Color myColor = Color.FromName("Red") ;

Независимо от метода получения типа Color, с этим типом можно взаимодействовать с помощью его членов.

• GetBrightness() – возвращает значение яркости типа Color на основании измерения HSB (Hue-Saturation-Brightness – оттенок, насыщенность, яркость).

• GetSaturation() – возвращает значение насыщенности типа Color на основании измерения HSB.

• GetHue() – возвращает значение оттенка типа Color на основании измерения HSB.

• IsSystemColor – индикатор того, что данный тип Color является зарегистрированным системным цветом.

• A, R, G, В – возвращают значения, присвоенные для альфа, красной, зеленой и синей составляющих типа Color.

 

Класс ColorDialog

Чтобы обеспечить конечному пользователю приложения возможность конфигурировать тип Color, пространство имен System.Windows.Forms предлагает встроенный класс диалогового окна с именем ColorDialog (рис. 20.7).

Рис. 20.7. Диалоговое окно настройки цветов Windows Forms

Работать с этим диалоговым окном очень просто. Для действительного экземпляра типа ColorDialog вызовите ShowDialog(), чтобы отобразить диалоговое окно модально. После закрытия диалогового окна пользователем вы сможете извлечь соответствующей объект Color, используя свойство ColorDialog.Color.

Предположим, что вы хотите с помощью ColorDialog предоставить пользователю возможность выбрать цвет фона для области клиента формы. Чтобы упростить ситуацию, мы будем отображать ColorDialog тогда, когда пользователь щелкнет в любом месте области клиента.

public partial class MainForm: Form {

 private = ColorDialog colorDlg;

 private Color currColor = Color.DimGray;

 public mainForm() {

  InitializeComponent();

  colorDlg = new ColorDialog();

  Text = "Для изменения цвета щелкните здесь";

  this.MouseDown += new MouseEventHandler(MainForm_MouseDown);

 }

 private void MainForm_MouseDown(object sender, MouseEventArgs e) {

  if (colorDlg.ShowDialog() ! = DialogResult.Cancel) {

   currColor = colorDlg.Color;

   this.BackColor = currColor;

   string strARGB = ColorDlg.Color.ToString();

   MessageBox.Show(strARGB, "Выбранный цвет ");

  }

 }

}

Исходный код. Проект ColorDIg размещен в подкаталоге, соответствующем главе 20.

 

Теперь давайте выясним, как можно программно манипулировать шрифтами. Тип System.Drawing.Font представляет шрифт, установленный на машине пользователя, Типы шрифта могут определяться с помощью любого числа перегруженных конструкторов. Вот вам несколько примеров.

// Создание Font с заданными именем типа и размером.

Font f = new Font("Times New Roman", 12);

// Создание Font, с заданными именем типа, размером и начертанием.

Font f2 = new Font("WingDings", 50, FontStyle.Bold | FontStyle.Underline);

При создании f2 здесь используются связанные с помощью операции OR значения из перечня FontStyle.

public enum FontStyle {

 Regular, Bold,

 Italic, Underline, Strikeout

}

После установки параметров объекта Font следующей вашей задачей должна быть передача этого объекта методу Graphics.DrawString() в виде параметра. Хотя метод DrawString() перегружен, каждая из его вариаций требует одну и ту же информацию: отображаемый текст, шрифт для отображения этого текста, кисть, с помощью которой выполняется визуализация, и место, в которое нужно текст поместить.

private void MainForm_Paint(object sender, PaintEventArgs e) {

 Graphics g = e.Graphics;

 // Аргументы (String, Font, Brush, Point).

 g.DrawString("Моя строка", new Font("WingDings", 25), Brushes.Black, new Point(0,0));

 // Аргументы (String, Font, Brush, int, int)

 g.DrawString("Другая строка", new Font("Times New Roman", 16), Brushes.Red, 40, 40);

}

 

Работа с семействами шрифтов

Пространство имен System.Drawing определяет также тип FontFamily, предлагающий абстракцию для группы гарнитур, имеющих одинаковый базовый дизайн, но с определенными вариациями стиля. Семейство шрифтов, например, такое как Verdana, может включить в себя несколько шрифтов, отличающихся по стилю и размеру. Например, Verdana Bold (полужирный) 12 пунктов и Verdana Italic (курсив) 24 пункта являются разными шрифтами в рамках одного семейства шрифтов Verdana.

Конструктор типа FontFamily получает на вход строку с именем семейства шрифтов, которое вы пытаетесь представить. После создания "общего семейства" вы можете создать более специфичный объект Font.

private void MainForm_Paint(object sender, PaintEventArgs e) {

 Graphics g = e.Graphics;

 // Создание семейства шрифтов.

 FontFamily myFamily = new FontFamilу("Verdana");

 // Передача семейства конструктору Font.

 Font myFont = new Font(myFamily, 12);

 g.Drawstring("Привет!", myFont, "Brushes.Blue, 10 , 10);

}

Больший интерес представляет собой возможность сбора статистики в отношении данного семейства шрифтов. Скажем, вы создаете приложение текстового редактора и хотите определить среднюю ширину символа в конкретном объекте FontFamily. Или, например, вам нужна информация о надстрочных и подстрочных значениях для данного символа. Для получения такой информации тип FontFamily предлагает использовать специальные члены, описания которых приведены в табл. 20.5.

Таблица 20.5. Члены типа FontFamily

Для примера рассмотрите следующий обработчик события Paint, выводящий на печать ряд характеристик семейства шрифтов Verdana.

private void MainForm_Paint(object sender, PaintEventArgs e) {

 Graphics g = e.Graphics;

 FontFamily myFamily = new FontFamily("Verdana");

 Font myFont = new Font(myFamily, 12);

 int у = 0;

 int fontHeight = myFont.Height;

  // Отображение единицы измерения для членов FontFamily.

 this.Text = "Единица измерения: GraphicsUnit." + myFont.Unit;

 g.DrawString("Семейство Verdana.", myFont, Brushes.Blue, 10, y);

 у += 20;

 // Характеристики связей нашего семейства. …

 g.DrawString("Надстрочные для Verdana Bold: " + myFamily.GetCellAscent(FontStyle.Bold), myFont, Brushes.Black, 10, у + fontHeight);

 у += 20;

 g.DrawString("Подстрочные для Verdana Bold: " + myFamily.GetCellDescent(FontStyle.Bold), myFont, Brushes.Black, 10, у + fontHeight);

 у += 20;

 g.DrawString("Интерлиньяж для Verdana Bold: " + myFamily.GetLineSpacing(FontStyle.Bold), myFont, Brushes.Black, 10, у + fontHeight);

 у += 20;

 g.DrawString("Высота для Verdana Bold: " + myFamily.GetEmHeight(FontStyle.Bold), myFont, Brushes.Black, 10, у + fontHeight);

 у += 20;

}

На рис. 20.8 показан результат.

Рис. 20.8. Сбор статистики для семейства шрифтов Verdana

Заметьте, что указанные члены типа Font Family возвращают значения с использованием в качестве единицы измерения GraphicsUnit.Point (а не Pixel), что соответствует 1/72 дюйма. Вы можете преобразовать эти значения в те единицы, которые вам подходят лучше всего.

Исходный код. Проект FontFamilyApp размещен в подкаталоге, соответствующем главе 20.

 

Работа с гарнитурами и размерами шрифтов

Давайте теперь построим более сложное приложение. Позволяющее пользователю манипулировать объектом Font, поддерживаемым формой. Это приложение предоставит пользователю возможность указать гарнитуру шрифта, используя встроенный набор гарнитур, доступный путем выбора Сервис→Гарнитура из меню. Пользователю также будет позволено косвенно управлять размером объекта Font с помощью объекта Timer Windows Forms. Если пользователь активизирует Timer, выбрав из меню Сервис→Рост?, то размер объекта Font начнет увеличиваться (до максимального верхнего предела) через регулярные интервалы времени. При этом отображаемый текст будет постепенно увеличиваться, что обеспечит анимационный эффект "живого текста". Наконец, третий элемент меню Сервис будет называтъся Список шрифтов и показывать список всех шрифтов, установленных на машине конечного пользователя. На рис. 20.9 демонстрируется логика меню, о котором идет речь.

Рис. 20.9. Меню проекта FontApp

Чтобы начать реализацию приложения, добавьте в форму член Timer (с именем swellTimer), строку (strFontFace) для представления текущего названия гарнитуры шрифта и целое число (swellValue) для представления величины корректировки для размера шрифта. В окне проектирования формы сконфигурируйте Timer так, чтобы он генерировал событие Tick каждые 100 миллисекунд.

public partial class MainForm: Form {

 private Timer swellTimer = new Timer();

 private int swellValue;

 private string strFontFace = "WingDings";

 public MainForm() {

  InitializeComponent();

  BackColor = Color.Honeydew;

  CenterToScreen();

  // Конфигурация таймера.

  swellTimer.Enabled = true;

  swellTimer.Interval = 100;

  swellTimer.Tick += new EventHandler(swellTimerTick);

 }

}

В обработчике события Tick увеличьте значение члена swellValue на 5. Напомним, что целое число swellValue будет добавляться к текущему размеру шрифта, чтобы обеспечивался простой эффект анимации (предполагается, что swellValue будет ограничено сверху максимальным значением 50). Чтобы не допустить мерцания, которое может происходить при перерисовке всей области клиента, при вызове Invalidate() будет обновляться только верхняя прямоугольная область формы.

private void swellTimer Tick(object sender, EventArgs e) {

 // Увеличение текущего значения swellValue на 5.

 swellValue += 5;

 // Если значение больше или равно 50, сбросить его в ноль.

 if (swellValue ›= 50) swellValue = 0;

  // Обновление минимальной области для уменьшения мерцания.

 Invalidate(new Rectangle(0, 0, ClientRectangle.Width, 100));

}

Теперь, когда с каждым циклом Timer обновляются верхние 100 пикселей области клиента, нужно найти что-нибудь подходящее для визуализации. В обработчике Paint формы создайте объект Font на основе выбранной пользователем гарнитуры шрифта (она выбирается с помощью соответствующего пункта меню) и текущего значения swellValue (оно задается таймером Timer), Настроив объект Font, поместите сообщение в центр соответствующего прямоугольника.

private void MainForm Paint(object sender, PaintEventArgs e) {

 Graphics g = e.Graphics;

  // Размер шрифта должен находиться в диапазоне от 12 до 62,

 // в зависимости от swellValue.

 Font theFont = new Font(strFontFace, 12 + swellValue);

 string message = "Привет GDI+";

 // Вывод сообщения в центре прямоугольника.

 float windowCenter = this.DisplayRectangle.Width/2;

 SizeF stringSize = g.Measure.String(message, theFont);

 float startPos = windowCenter – (stringSize.Width/2);

 g.Drawstring(message, theFont, new SolidBrush(Color.Blue), startPos, 10);

}

Легко догадаться, что при выборе пользователем конкретной гарнитуры шрифта обработчик Clicked для соответствующего варианта выбора из меню должен обновить строковую переменную fontFace и перерисовать область клиента, например:

private void arialToolStripMenuItem_Click(object sender, EventArgs e) {

 strFontFace = "Arial";

 Invalidate();

}

Обработчик Click для пункта меню Рост? будет использоваться для запуска и остановки процесса увеличения текста (т.е. для разрешения и отключения анимаций). Здесь используйте свойство Enabled объекта Timer так, как показано ниже.

private void swellToolStripMenuItem_Click(object sender, EventArgs e) {

 swellTimer.Enabled = !swellTimer.Enabled;

}

 

Список установленных шрифтов

Давайте расширим программу так, чтобы она отображала множество установленных на машине шрифтов с помощью типов из пространства имен System.Drawing.Text. Это пространство имен содержит набор типов, которые можно использовать для получения списка шрифтов, установленных на целевой машине, и для работы с ними. Дня наших целей достаточно рассмотреть только класс InstalledFontCollection.

Когда пользователь выбирает из меню Сервис→Список шрифтов, соответствующий обработчик Clicked создает экземпляр класса InstalledFormCollection. Этот класс содержит массив FontFamily, представляющий набор всех шрифтов, установленных на целевой машине, и этот массив можно получить, используя свойство InstalledFontCollection.Families. С помощью свойства FontFamily.Name вы можете извлечь название гарнитуры шрифта (например, Times New Roman, Arial и т.п.).

Добавьте в форму приватный член-строку с именем installedFonts для хранения названия гарнитур. Программная логика обработки пункта меню Список Шрифтов создает экземпляр типа InstalledFontCollection, читает имя каждого элемента и добавляет новую гарнитуру в приватный член installedFonts.

public partial class MainForm: Form {

 // Содержит список шрифтов.

 private string installedFonts;

// Обработчик меню для получения списка шрифтов.

 private void mnuConfigShowFonts_Clicked(object sender, EventArgs e) {

  InstalledFontCollection fonts = new InstalledFontCollection();

  for (int i = 0; i ‹ fonts.Families.Length; i++) installedFonts += fonts.Families[i].Name + " ";

  // На этот раз нужно обновить всю область клиента,

  // поскольку обновляется строка installedFonts в нижней части

  // области клиента.

  Invalidate();

 }

}

Заключительной нашей задачей будет отображение строки installedFonts в области клиента, расположенной сразу же под той частью экрана, которая исполь-зуетcя для движущегося текста.

private void MainForm_Paint(object sender, PaintEventArgs e) {

 Graphics g = e.Graphics;

 Font theFont = new Font(strFontFace, 12 + swellValue);

 string message = "Привет GDI+";

 // Отображение сообщения в центре окна.

 float windowCenter = this.DisplayRectangle.Width/2;

 SizeF.stringSize = e.Graphics.MeasureString(message, theFont);

 float startPos = windowCenter – (stringSize.Width/2);

 g.DrawString(message, theFont, Brushes.Blue, startPos, 10);

 // Показ списка установленных шрифтов в прямоугольнике

 // под движущимся текстом.

 Rectangle myRect = new Rectangle(0, 100, ClientRectangle.Width, ClientRectangle.Height);

 // Закрашивание данной области формы черным цветом.

 g.FillRectangle(new SolidBrush(Color.Black), myRect);

 g.DrawString(installedFonts, new Font("Arial", 12), Brushes.White, myRect);

}

Напомним, что размеры "грязного прямоугольника" проецировались в верхние 100 пикселей области клиента. Поскольку обработчик Tick обновляет только часть формы, остальная ее часть при посылке события Tick не перерисовывается (чтобы оптимизировать задачу визуализации в области клиента).

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

private void Main.Form_Resize(object sender, System.EventArgs e) {

 Rectangle myRect = new Rectangle(0, 100, ClientRectangle.Width, ClientRectangle.Height);

 Invalidate(myRect);

}

На рис. 20.10 показан результат (с текстом, представленным шрифтом WingDings!).

Рис. 20.10. Приложение SwellingFontApp в действии

Исходный код. Проект SwellingFontApp размещен в подкаталоге, соответствующем главе 20.

 

Класс FontDialog

Как вы можете догадываться, существует и класс диалогового окна для настройки шрифтов (FontDialog). Вид этого окна показан на рис. 20.11.

Рис. 20.11. Диалоговое окно Шрифт Windows Forms

Подобно типу ColorDialog, рассмотренному в этой главе выше, для работы с FontDialog нужно просто вызвать метод ShowDialog(). Используя свойства Font, можно извлечь текущие характеристики шрифта для использования в приложении. Для примера рассмотрите следующую форму, имитирующую логику предыдущего проекта ColorDlg. При щелчке пользователя в любом месте окна формы отображается диалоговое окно Шрифт и выводится информация о текущем выборе.

public partial class MainForm: Form {

 private FontDialog fontDlg = new FontDialog();

 private Font currFont = new Font("Times New Roman", 12);

 public MainForm() {

  InitializeComponent(); CenterToScreen();

 }

 private void MainForm_MouseDown(object sender, MouseEventArgs e) {

  if (fontDlg.ShowDialog() != DialogResult.Cancel) {

   currFont = fontDlg.Font;

   this.Text = string.Format("Selected Font: {0}", currFont); Invalidate();

  }

 }

 private void MainForm_Paint(object sender, PaintEventArgs e) {

  Graphics g = e.Graphics;

  g.DrawString("Проверка…", currFont, Brushes.Black, 0, 0);

 }

}

Исходный код. Проект FontDlgForm размещен в подкаталоге, соответствующем главе 20.

 

Типы Pen GDI+ используются для построения линий, соединяющих конечные точки. Сам по себе тип Pen не слишком полезен. Для выполнения визуализации геометрической формы на поверхности производного от Control типа действительный тип Pen следует направить подходящему методу визуализации, определенному классом Graphics. Вообще говоря, с объектами Pen обычно используются методы DrawXXX(), позволяющие отобразить некоторый набор линий на соответствующей графической поверхности.

Тип Pen определяет небольшой набор инструкторов, позволяющих задать начальный цвет и ширину пера. По большей части функциональные возможности Pen задаются свойствами, поддерживаемыми данным типом. Описания некоторых из этих свойств предлагаются в табл. 20.7.

Таблица 20.7. Свойства Pen

Помните о том, что вдобавок к типу Pen в GDI+ предлагается коллекция Pens. Используя ряд статических свойств, вы можете извлечь из этой коллекции объект Pen (или нужный цвет) "на лету", не создавая пользовательский тип Pen вручную. Однако следует знать, что возвращаемый: при этом тип Pen всегда имеет ширину, равную 1.

Если вам понадобятся какие-то экзотические перья, вы должны создать тип Pen вручную. Предоставив вам эту информацию, я теперь могу перейти к построению примеров геометрических изображений с помощью простых типов Pen. Предположим, что у нас есть главный объект Form, способный отвечать на запросы визуализации. Реализация ответа выглядит так.

private void MainForm_Paint(object sender, PaintEventArgs e) {

 Graphics g = e.Graphics;

 // Создание большого пера синего цвета.

 Pen bluePen = new Pen(Color.Blue, 20);

 // Получение готового пера из типа Pens.

 Pen pen2 = Pens.Firebrick;

  // Визуализация некоторых шаблонов.

 g.DrawEllipse(bluePen, 10, 10, 100, 100);

 g.DrawLine(pen2, 10, 130, 110, 130);

 g.DrawPie(Pens.Black, 150, 10, 120, 150, 90, 80);

  // Рисование пурпурного полигона с пунктирной границей.…

 Pen pen3 = new Pen(Color.Purple, 5);

 pen3.DashStyle = DashStyle.DashDotDot;

 g.DrawPolygon(pen3, new Point[] { new Point(30, 140), new Point(265, 200), new Point(100, 225), new Point(190, 190), new Point(50, 330), new Point(20, 180) });

  //… и прямоугольника, содержащего текст.…

 Rectangle r = new Rectangle (150, 10, 130, 60);

 g.DrawRectangle(Pens.Blue, r);

 g.DrawString("Эй, вы, там, наверху!… Я вам привет передаю.", new Font("Arial", 11), Brushes.Black, r);

}

Заметьте, что тип Pen, применяемый для отображения многоугольника, использует перечень DashStyle (определенный в System.Drawing.Drawing2D).

public enum DashStyle {

 Solid, Dash, Dot,

 DashDot, DashDotDot, Custom

}

В дополнение к уже имеющимся элементам DashStyle вы можете определить пользовательские шаблоны, используя для этого свойство DashPattern типа Pen.

private void MainForm_Paint(object sender, PaintEventArgs e) {

 Graphics g = e.Graphics;

 …

 // Рисование прерывистой линии вдоль границы формы

 // по пользовательскому шаблону.

 Pen customDashPen = new Pen(Color.BlueViolet, 10);

 float[] myDashes = {5.0f, 2.0f, 1.0f, 3.0f};

 customDashPen.DashPattern = myDashes;

 g.DrawRectangle(customDashPen, ClientRectangle);

}

На рис. 20.12 показан вывод этого варианта обработчика событий Paint.

Исходный код. Проект CustomPenApp размещен в подкаталоге, соответствующем главе 20.

Рис. 20.12. Работа с типами Pen

 

Концы линий

Если рассмотреть вывод предыдущего примера, вы должны заметить, что начало и конец каждой линии там оформлен вполне стандартно – линия "срезается" под углом 90° к ее направлению. Но, используя перечень LineCap, вы имеете возможность создавать объекты Pen, демонстрирующие иное поведение.

public enum LineCap {

 Flat, Square, Round,

 Triangle, NoAnchor,

 SquareAnchor, RoundAnchor,

 DiamondAnchor, ArrowAnchor,

 AnchorMask, Custom

}

Следующее приложение отображает набор линий, по очереди используя каждый из стилей LineCap. Конечный результат показан на рис. 20.13.

Рис. 20.13. Работа с концами линий

В соответствующем программном коде просто используется цикл по всем членам перечня LineCap с выводам имени соответствующего элемента (например, ArrowAnchor) и отображением линии с соответствующим оформлением ее концов.

private void MainForm_Paint(object sender, PaintEventArgs e) {

 Graphics g = e.Graphics;

 Pen thePen = new Pen(Color.Black, 10);

 int yOffSet = 10;

 // Получение всех членов перечня LineCap.

 Array obj = Enum.GetValues(typeof(LineCap));

 // Рисование линии для данного члена LineCap.

 for (int х = 0; х ‹ obj. Length; x++) {

  // Получение следующего стиля конца линии и настройка пера.

  LineCap temp = (LineCap)obj.GetValue(x);

  thePen.StartCap = temp;

  thePen.EndCap = temp;

  // Вывод имени из перечня LineCap.

  g.Drawstring(temp.ToString(), new Font("Times New Roman", 10), new SolidBrush(Color.Black), 0, yOffSet);

   // Рисование линии с соответствующим стилем концов.

  g.DrawLine(thePen, 100, yOffSet, Width – 50, yOffSet);

  yOffSet += 40;

 }

}

Исходный код. Проект PenCapApp размещен в подкаталоге, соответствующем главе 20.

 

Типы, производные от System.Drawing.Brush, используются для заполнения имеющегося региона заданным цветом, узором или изображением. Сам класс Brush является абстрактным типом, поэтому он не позволяет создать соответствующий экземпляр непосредственно. Однако Brush может играть роль базового класса для родственных ему типов кисти (например, SolidBrush, HatchBrush, LinearGradientBrush и т.д.). Кроме относящихся к Brush типов, пространство имей System.Drawing определяет также два вспомогательных класса, возвращающие кисти, уже сконфигурированные с помощью ряда статических свойств: это классы Brushes и SystemBrushes. Так или иначе, получив кисть, вы получаете возможность вызвать любой из методов FillXXX() типа Graphics.

Интересно то, что на основе кисти вы можете создать пользовательский тип Pen. Подобным образом вы можете создать себе любую подходящую кисть (кисть, которая "рисует" точечное изображение) и выполнять визуализацию заданных геометрических шаблонов с помощью сконфигурированного объекта Pen. Для примера рассмотрите следующий вариант программы, в котором используются различные кисти.

private void MainForm_Paint(object sender, PaintEventArgs e) {

 Graphics g = e.Graphics;

 // Создание SolidBrush синего цвета .

 SolidBrush blueBrush = new SolidBrush(Color.Blue);

 // Получение готовой кисти из типа Brushes.

 SolidBrush pen2 = (SolidBrush)Brushes.Firebrick;

 // Визуализация некоторых шаблонов.

 g.FillEllipse(blueBrush, 10, 10, 100, 100);

 g.FillPie(Brushes.Black, 150, 10, 120, 150, 90, 80);

 // Рисование пурпурного полигона…

 SolidBrush brush3= new SolidBrush(Color.Purple);

 g.FillPolygon(brush3, new Point[]{ new Point(30, 140), new Point(265, 200), new Point(100, 225), new Point(190, 190), new Point(50, 330), new Point(20, 180) });

 // … и прямоугольника, содержащего текст …

 Rectangle r = new Rectangle(150, 10, 130, 60);

 g.FillRectangle(Brushes.Blue, r);

 g.DrawString("Эй, вы, там, наверху!… Я вам привет передаю.", new Font("Arial", 11), Brushes.White, r);

}

Надеюсь, вы согласитесь, что это приложение почти идентично созданной выше программе CustomPenApp, но использует методы FillXXX() и типы SolidBrush вместо перьев и соответствующим им методов DrawXXX(). На рис. 20.14 показан соответствующий вывод.

Исходный код. Проект SolidBrushApp размещен в подкаталоге, соответствующем главе 20.

Рис. 20.14. Работа с типами Brush

 

Работа с HatchBrush

В пространстве имен System.Drawing.Drawing2D определен производный от Brush тип с именем HatchBrush. Этот тип позволяет закрасить регион, используя один из (очень большого) набора встроенных видов узоров, представленных перечнем HatchStyle. Вот часть соответствующего списка имен.

public enum HatchStyle {

 Horizontal, Vertical, ForwardDiagonal,

 BackwardDiagonal, Cross, DiagonalCross,

 LightUpwardDiagonal, DarkDownwardDiagonal,

 DarkUpwardDiagonal, LightVertical,

 NarrowHorizontal, DashedDownwardDiagonal,

 SmallConfetti, LargeConfetti, ZigZag,

 Wave, DiagonalВrick, Divot, DottedGrid, Sphere,

 OutlinedDiamond, SolidDiamond,

 …

}

При конструировании HatchBrush вы должны указать цвет для переднего плана и цвет для фона, которые будут использоваться при выполнении операции закрашивания. Для примера давайте немного подкорректируем программную логику из приведенного выше примера PenCapApp.

private void MainForm_Paint(object sender, PaintEventArgs e) {

 Graphics g = e.Graphics;

 int yOffSet = 10;

 // Получение всех членов перечня HatchStyle.

 Array obj = Enum.GetValues(typeof(HatchStyle));

 // Отображение овалов для первых 5 значений из HatchStyle.

 for (int x = 0; x ‹ 5; x++) {

  // Конфигурация кисти.

  HatchStyle temp = (HatchStyle)obj.GetValue(x);

  HatchBrush theBrush = new HatchBrush(temp, Color.White, Color.Black);

  // Вывод имени из перечня HatchStyle.

  g.DrawString(temp.ToString(), new Font (''Times New Roman", 10), Brushes.Black, 0, yOffSet);

   // Закраска объекта подходящей кистью.

  g.FillEllipse(theBrush, 150, yOffSet, 200, 25);

  yOffSet += 40;

 }

}

В окне вывода будут показаны заполненные овалы для первых пяти значений видов штриховки (рис. 20.15).

Рис. 20.15. Некоторые стили штриховки

Исходный код. Проект BrushStyles размещен в подкаталоге, соответствующем главе 20.

 

Работа с TextureBrush

Тип TextureBrush позволяет связать с кистью точечное изображение, чтобы затем использовать ее в операциях закрашивания. Чуть позже будет подробно обсуждаться класс image (изображение) GDI+. Типу TextureBrush предоставляется ссылка на image, используемая этим типом в течение всего цикла его существования. Само изображение обычно хранится в некотором локальном файле (*.bmp. *.gif, *.jpg) или же встроено в компоновочный блок .NET.

Давайте построим пример приложения, использующего тип TextureBrush. Одна кисть будет использоваться дня закраски области клиента изображением из файла clouds.bmp, в то время как другая кисть будет выводить текст с помощью изображения, находящегося в файле Soap bubbles.bmp. Соответствующий вывод показан на рис. 20.16.

Рис. 20.16. Точечные рисунки в качестве кисти

Ваш производный от Form класс должен поддерживать два члена типа Brush, которым присваивается новый объект TextureBrush в конструкторе. Обратите внимание на то, что конструктору типа TextureBrush требуется предоставить на вход тип, производный от Image.

public partial class MainForm: Form {

 // Данные для кисти с изображением.

 private Brush texturedTextBrush; private Brush texturedBGroundBrush;

 public MainForm() {

  …

  // Загрузка изображения для кисти фона.

  Image bGroundBrushImage = new Bitmap("Clouds.bmp");

  texturedBGroundBrush = new TextureBrush(bGroundBrushImage);

  // Загрузка изображения для кисти текста.

  Image textBrushImage = new Bitmap("Soap Bubbles.bmp");

  texturedTextBrush = new TextureBrush(textBrushImage);

 }

}

Замечание. Файлы *.bmp, которые используются в этом примере, должны находиться в той же папке, где находится само приложение (или должны быть "жестко" указаны пути, по которым эти изображения можно найти). Соответствующая проблема будет обсуждаться в этой главе чуть позже.

Теперь, когда у вас есть два типа TextureBrush, способные выполнить визуализацию, создать обработчик события Paint очень просто.

private void MainForm_Paint(object sender, PaintEventArgs e) {

 Graphics g = e.Graphics;

 Rectangle r = ClientRectangle;

 // Рисование облаков в области клиента.

 g.FillRectangle(texturedBGroundBrush, r);

 // Отображение текста кистью с текстурой.

 g.DrawString("Изображения в качестве кисти. Стильно!", new Font("Arial", 30, FontStyle.Bold | FontStyle.Italic), texturedTextBrush, r);

}

Исходный код. Проект TexturedBrushes размещен в подкаталоге, соответствующем главе 20.

 

Работа с LinearGradientBrush

Последним из рассматриваемых в этом разделе типов будет тип LinearGradientBrush, который можно использовать тогда, когда нужно смешать два цвета в градиентной закраске. Работать с этим типом так же просто, как и с остальными типами кисти. Важным моментом здесь Является то, что при создании LinearGradientBrush нужно указать пару типов Color и значение для направления смешивания из перечня LinearGradientMode.

public enum LinearGradientMode {

 Horizontal, Vertical,

 ForwardDiagonal, BaсkwardDiagonal

}

Чтобы проверить эти значения, с помощью LinearGradientBrush отобразим серию прямоугольников.

private void MainForm_Paint(object sender, PaintEventArgs e) {

 Graphics g = e.Graphics;

 Rectangle r = new Rectangle(10, 10, 100, 100);

 // Градиентная кисть.

 LinearGradientBrush theBrush = null;

 int yOffSet = 10;

 // Получение членов перечня LinearGradientMode .

 Array obj = Enum.GetValues(typeof(LinearGradientMode));

  // Отображение прямоугольников для членов LinearGradientMode.

 for(int x = 0; x ‹ obj.Length; x++) {

  // Конфигурация кисти.

  LinearGradientMode temp = (LinearGradientMode)obj.SetValue(x);

  theBrush = new LinearGradientBrush(r, Color.GreenYellow, Color.Blue, temp);

  // Вывод имени из перечня LinearGradientMode.

  g.DrawString(temp.ToString(), new Font("Times New Roman", 10), new SolidBrush(Color.Black), 0, yOffSet);

  // Закраска прямоугольника подходящей кистью.

  g.FillRectangle(theBrush, 150, yOffSet, 200, 50);

  yOffSet += 80;

 }

}

На рис. 20.17 показан результат.

Рис. 20.17. Градиентная кисть за работой

Исходный код. Проект GradientBrushes размещен в подкаталоге, соответствующем главе 20.

 

Вы, конечно, можете отображать изображения Bitmap на поверхности любого производного класса Control непосредственно, но вы быстро обнаружите, что гораздо более широкие возможности и лучший контроль дает размещение изображения в рамках типа PictureBox. Например, поскольку тип PictureBox является производным от Control, он наследует соответствующие функциональные возможности, например, способность обрабатывать различные события, поддерживать всплывающие подсказки или контекстные меню и т.д. Такого поведения можно добиться и при непосредственном использовании Bitmap, но при этом вам придется создавать соответствующий программный код самостоятельно.

Чтобы продемонстрировать пользу типа PictureBox, давайте создадим простую "игру", которая будет способна "распознать" присутствие указателя мыши на графическом изображении. При щелчке пользователя кнопкой мыши в границах изображения включается режим "перетаскивания", и пользователь может перемещать изображение по форме. Чтобы сделать ситуацию интереснее, давайте проконтролируем, где пользователь "отпустит" изображение. Если это произойдет в рамках некоторого прямоугольника визуализации GDI+, будет выполнено некоторое заданное действие (оно будет описано чуть позже). Вы, возможно, знаете, что процесс обнаружения событий мыши в заданной области называется проверкой попадания в заданную область.

Тип PictureBox наследует большинство своих функциональных возможностей от базового класса Control. Ряд членов Control был уже рассмотрен в предыдущей главе, и это позволяет нам сразу перейти к обсуждению вопроса назначения изображения члену PictureBox с помощью свойства Image (снова заметим, что файл happyDude.bmp должен находиться в каталоге приложения).

public partial class MainForm: Form {

 // Содержит изображение улыбающегося лица.

 private PictureBox happyBox = new PictureBox();

 public MainForm() {

  // Конфигурация PictureBox.

  happyBox.SizeMode = PictureBoxSizeMode.StretchImage;

  happyBox.Locaton = new System.Drawing.Point(64, 32);

  happyBox.Size = new System.Drawing.Size(50, 50);

  happyBox.Cursor = Cursors.Hand;

  happyBox.Image = new Bitmap("happyDude.bmp");

  // Добавление в коллекцию Controls формы.

  Controls.Add(happyBox);

 }

}

Кроме свойства Image, нам будет интересно только свойство SizeMode, для которого используются значения перечня PiсtureBoxSizeMode. Этот тип используется для контроля того, как соответствующее изображение должно отображаться в рамках рабочего прямоугольника PictureBox. Здесь мы используем PictureBoxSizeMode.StretchImage, означающее то, что изображение следует растянуть на всю заданную типом PictureBox область (которая в данном случае имеет размеры 50×50 пикселей).

Следующей задачей является обработка событий MouseMove.MouseUр и MouseDown для члена-переменной PictureBox с помощью вполне стандартного синтаксиса обработки событий C#.

public MainForm() {

 …

 // Добавление обработчиков для ряда событий.

 happyBox.MouseDown += new MouseEventHandler(happyBox_MouseDown);

 happyBox.MouseUp += new MouseEventHandler(happyBox_MouseUp);

 happyBox.MouseMove += new MouseEventHandler(hарруВох_MouseMove);

 Controls.Add(happyBox);

 InitializeComponent();

}

Обработчик событий MouseDown сохраняет поступающие на вход значения координат (х, у) местоположения указателя в двух членах-переменных (oldX и oldY) для использования в дальнейшем, а также устанавливает значение true (истина) для члена-переменной (isDragging) типа System.Boolean, когда происходит перетаскивание. Добавьте эти члены-переменные в форму и реализуйте обработчик события MouseDown так, как предлагается ниже.

private void happyBox_MouseDown(object sender, MouseEventArgs e) {

 isDragging = true;

 oldX = e.X;

 oldY = e.Y;

}

Обработчик события MouseMove просто изменяет местоположение PictureBox (с помощью свойств Тор и Left), в зависимости от сдвига положения указателя по сравнению со значениями, полученными при обработке события MouseDown.

private void happyBox_MouseMove(object sender, MouseEventArgs e) {

 if (isDragging) {

  // Необходимо для вычисления нового значения Y в зависимости

  // от того, где была нажата кнопка мыши.

  happyBox.Top = happyBox.Top + (e.Y – oldY);

   // То же для X (используя в качестве основы oldX) .

  happyBox.Left = happyBox.Left + (e.X – oldX);

 }

}

Обработчик события MouseUp устанавливает для isDragging значение false (ложь), чтобы сигнализировать об окончаний операции перетаскивания. Кроме того, если событие MouseUp происходит в тот момент, когда PictureBox содержится в пределах отображаемого средствами GDI+ Rectangle, мы будем считать, что пользователь победил в этой (очень примитивной) игре. Сначала добавьте в класс Form член Rectangle (с именем dropRect и заданными размерами).

public partial class MainForm: Form {

 private PictureBox happyBox = new PictureBox();

 private int oldX, oldY;

 private bool isDragging;

 private Rectangle dropRect = new Rectangle(100, 100, 140, 170);

 …

}

Обработчик события MouseUp теперь можно реализовать так.

private void happyBox_MouseUp(object sender, MouseEventArgs e) {

 isDragging = false;

 // Находится ли указатель внутри заданного прямоугольника?

 if (dropRect.Contains(happyBox.Bounds)) MessageBox.Show("Вы победили!", "Этот сладкий вкус умения…");

}

Наконец, в рамках обработки события Paint нужно отобразить в форме прямоугольную область (заданную переменной dropRect).

private void MainForm_Paint(object sender, PaintEventArgs e) {

 // Отображение целевого прямоугольника.

 Graphics g = e.Graphics;

 g.FillRectangle(Brushes.AntiqueWhite, dropRect);

 // Вывод инструкции.

 g.DrawString("Тащите этого парня сюда!", new Font("Times New Roman", 25), Brushes.Red, dropRect);

}

Запустив свое приложение, вы увидите окно, подобное показанному на рис. 20.19.

Рис. 20.19. Увлекательная игра "Счастливый пижон"

Если вы сделаете все, что требуется для победы в игре, вы увидите окно "восхваления", показанное на рис. 20.20.

Рис 20.20. У вас железные нервы!

Исходный код. Проект DraggingImages размещен в подкаталоге, соответствующем главе 20.

 

Проверка попадания в область изображения

Проверить попадание в область типа, производного от Control (например, типа PictureBox очень просто, поскольку такой тип может сам отвечать на события мыши. Но что делать в том случае, когда нужно выполнять проверку попадания в область геометрического шаблона, отображенного на поверхности формы?

Для иллюстрации соответствующего процесса давайте снова рассмотрим предыдущее приложение BasicImages, чтобы наделить его некоторыми дополнительными возможностями. Нашей целью является выявление того, что пользователь щелкнул на одном из трех изображений. Выяснив, на каком именно изображении был выполнен щелчок, мы с помощью изменения свойства Text формы выделяем это изображение рамкой шириной в 5 пикселей.

Первым шагом должно быть определение нового множества членов-переменных типа Form, представляющих объекты Rectangle, для которых будет выполняться регистрация события MouseDown. При наступлении такого события нужно программно выяснить, находятся ли поступающие координаты (x, y) в рамках границ объектов Rectangle, используемых для визуализации объектов Image. Выяснив, что пользователь щелкнул на изображении, мы должны установить приватную булеву переменную (isImageClicked) равной true (истина) и указать, какое изображение было выбрано, используя для этого другую переменную и соответствующее значение из пользовательского перечня ClickedImage, определенного следующим образом.

enum ClickedImage {

 ImageA, ImageB, ImageC

}

С учетом сказанного, вот как может выглядеть исходная модификация нашего класса формы.

public partial class MainForm: Form {

 private Bitmap[] myImages = new Bitmap(3];

 private Rectangle[] imageRects = new Rectangle[3];

 private bool isImageClicked = false;

 ClickedImage imageClicked = ClickedImage.ImageA;

 public MainForm() {

  …

  // Установка прямоугольников.

  imageRects[0] = new Rectangle(10, 10, 90, 90);

  imageRects[1]Символы кириллицы в пользовательских строках программа ildasm.exe просто игнорирует и в окне метаданных не отображает. – Примеч. ред.
= new Rectangle(10, 110, 90, 90);

  imageRects[2]Сообщение гласит: "Чтобы выполнить это приложение, установите одну из следующих версий .NET Framework: v1.0.3705. Обратитесь к разработчику приложения для получения инструкций по поводу установки нужной версии .NET Framework."
= new Rectangle (10, 210, 90, 90);

 }

 private void MainForm_MouseDown(object sender, MouseEventArgs e) {

   // Получение координат (х, у) щелчка.

  Point mousePt = new Point(e.X, e.Y);

   // Проверка попадания указателя в любой из прямоугольников.

  if (imageRects[0].Contains(mousePt)) {

   isImageClicked = true;

   imageClicked = ClickedImage.ImageA;

   this.Text = "Вы щелкнули на изображении А";

  } else if (imageRects[1]Символы кириллицы в пользовательских строках программа ildasm.exe просто игнорирует и в окне метаданных не отображает. – Примеч. ред.
.Contains(mousePt)) {

   isImageClicked = true;

   imageClicked = Clickedlmage.ImageB;

   this.Text = "Вы щелкнули на изображении В";

  } else if (imageRects[2]Сообщение гласит: "Чтобы выполнить это приложение, установите одну из следующих версий .NET Framework: v1.0.3705. Обратитесь к разработчику приложения для получения инструкций по поводу установки нужной версии .NET Framework."
.Contains(mousePt)) {

   isImageClicked = true;

   imageClicked = ClickedImage.ImageC;

   this.Text = "Вы щелкнули на изображении C";

  } else { // Попадания не обнаружено, использовать умолчания.

   isImageClicked = false;

   this.Text = "Проверка попаданий в зону изображения";

  }

  // Обновление области клиента.

  Invalidate();

 }

}

Обратите внимание на то, что при последней проверке член-переменная isImagеCliсked устанавливается равной false (ложь), поскольку пользователь не выполнил щелчка ни одном из трех изображений. Это важно, если вы хотите удалить контур у ранее выделенного изображения. После проверки всех элементов область клиента обновляется. Вот как выглядит модифицированный обработчик Paint.

private void MainForm_Paint(object sender, PaintEventArgs e) {

 Graphics g = e.Graphics;

  // Визуализация изображений.

 …

 // Прорисовка контура (при щелчке в соответствующем месте)

 if (isImageClicked == true) {

  Pen outline = new Pen(Color.Tomato, 5);

  switch (imageClicked) {

  case ClickedImage.ImageA:

   g.DrawRectangle(outline, imageRects[0]);

   break;

  case Clickedlmage.ImageB:

   g.DrawRectangle(outline, imageRects[1]Символы кириллицы в пользовательских строках программа ildasm.exe просто игнорирует и в окне метаданных не отображает. – Примеч. ред.
);

   break;

  case ClickedImage.ImageC:

   g.DrawRectangle(outline, imageRects[2]Сообщение гласит: "Чтобы выполнить это приложение, установите одну из следующих версий .NET Framework: v1.0.3705. Обратитесь к разработчику приложения для получения инструкций по поводу установки нужной версии .NET Framework."
);

   break;

  default:

   break;

  }

 }

}

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

 

Проверка попадания в область, отличную от прямоугольной

Теперь давайте выясним, как выполнить проверку попадания в область, форма которой отличается от прямоугольника? Предположим, что вы обновили свое приложение так, что теперь в нем отображается геометрический шаблон неправильной формы, и при щелчке на этом шаблоне его тоже требуется выделить с помощью контура (рис. 20.21).

Рис. 20.21. Проверка попадания в многоугольники

Этот геометрический образ был создан на форме с помощью метода FillPath() типа Graphics. Указанный метод получает на вход экземпляр объекта GraphicsPath, инкапсулирующий последовательность соединенных линий, кривых и строк. Добавление новых элементов в экземпляр GraphicsPath осуществляется с помощью последовательности связанных методов Add, как описывается в табл. 20.9.

Таблица 20.9. Связанные методы Add класса GraphicsPath

Укажите using System.Drawing.Drawing2D и добавьте новый член GraphicsPath в класс Form. В рамках конструктора формы постройте множество элементов, представляющих соответствующую траекторию.

public partial class MainForm: Form {

 GraphicsPath myPath = new GraphicsPath();

 public MainForm() {

  // Создание нужного пути.

  myPath.StartFigure();

  myPath.AddLine(new Point(150, 10), new Point(120, 150));

  myPath.AddArc(200, 200, 100, 100, 0, 90);

  Point point1 = new Point(250, 250);

  Point point2 = new Point(350, 275);

  Point point3 = new Point (350, 325);

  Point point4 = new Point(250, 350);

  Point[] points = {point1, point2, point3, point4};

  myPath.AddCurve(points);

  myPath.CloseFigure();

  …

 }

}

Обратите внимание на вызовы StartFigure() и CloseFigure(). При вызове StartFigure() вы можете вставить новый элемент в траекторию, которую вы строите. Вызов CloseFigure() закрывает имеющуюся фигуру и начинает новую (если это требуется). Также следует знать, что в том случае, когда фигура содержит последовательность соединенных линий и кривых (как в случае с экземпляром myPath), цикл завершается путем соединения конечной и начальной точек с помощью линий. Сначала добавьте в перечень ClickedImage дополнительное имя StrangePath.

enum ClickedImage {

 ImageA, ImageB,

 ImageC, StrangePath

}

Затем обновите имеющийся обработчик события MouseDown, чтобы проверить присутствие указателя мыши в границах GraphicsPath. Как и для типа Region, это можно сделать с помощью члена IsVisible().

protected void OnMouseDown(object sender, MouseEventArgs e) {

 // Получение значений (х, у) для щелчка мыши.

 Point mousePt = new Point(e.X, e.Y);

 …

 else if(myPath.IsVisible(mousePt)) {

  isImageClicked = true;

  imageClicked = ClickedImage.StrangePath;

  this.Text = "Вы щелкнули на странной фигуре…";

 }

 …

}

Наконец, измените обработчик Paint, как предлагается ниже.

private void MainForm_Paint(object sender, PaintEventArgs e) {

 Graphics g = e.Graphics;

  // Рисование фигуры.

 g.FillPath(Brushes.Sienna, myPath);

 // Рисование контура (при щелчке на соответствующей фигуре)

 if (isImageClicked == true) {

  Pen outline = new Pen(Color.Red, 5);

  switch(imageClicked) {

   …

  case ClickedImage.StrangePath:

   g.DrawPath(outline, myPath);

   break;

  default:

   break;

  }

 }

}

Исходный код. Проект HitTestinglmages размещен в подкаталоге, соответствующем главе 20.

 

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

// Загрузка изображений в объекты.

bMapImageA = new Bitmap("imageA.bmp");

bMapImageB = new Bitmap("imageB.bmg");

bMapImageC = new Bitmap("imageC.bmp");

Такая программная логика требует, чтобы каталог приложения содержал три файла с именами imageA.bmp, imageB.bmp и imageС.bmp, иначе в среде выполнения будет сгенерировано соответствующее исключение.

Вы можете помнить из главы 11, что компоновочный блок представляет собой коллекцию типов и, необязательно, ресурсов. В этой связи нашей заключительной темой обсуждения в этой главе будет выяснение того, как выполнить привязку внешних ресурсов (например, файлов изображений и строк) непосредственно к компоновочному блоку. Тогда ваш двоичный блок .NET будет истинно самодостаточным. На элементарном уровне объединение внешних ресурсов в компоновочном блоке .NET предполагает выполнение следующих шагов.

1. Создание файла *.resx в котором задаются пары имен и значений для каждого ресурса приложения в формате XML-представления данных.

2. Использование утилиты командной строки resgen.exe для преобразования XML-файла *.resx в двоичный эквивалент (файл *.resources).

3. Использование флага /resource компилятора C# для того, чтобы встроить двоичный файл *.resources в компоновочный блок.

Как вы можете догадаться, в Visual Studio 2006 эти шаги автоматизированы. Чуть позже вы узнаете, как указанная среда разработки может вам в этом помочь. А пока давайте выясним, как сгенерировать и встроить ресурсы .NET в командной строке.

 

Пространство имен System.Resources

Ключом к пониманию формата ресурсов .NET является понимание типов, определенных в пространстве имен System.Resources. Соответствующее множество типов обеспечивает программные средства чтения и записи файлов *.resx (в формате XML) и *.resources (в двоичном формате), а также получения ресурсов, встроенных в компоновочный блок. Описания базовых типов этого пространства имен предлагаются в табл. 20.10.

Таблица 20.10. Члены пространства имен System.Resources

 

Создание файла *.resx программными средствами

Как было отмечено выше, файл *.resx содержит XML-данные, представляющие пары имен и значений для каждого ресурса приложения. Класс ResXResourceWriter предлагает набор членов, с помощью которых вы можете создать файл *.resx, добавить в него двоичные и строковые ресурсы и сохранить их. Для примера мы создадим простое приложение (ResXWriter), которое будет генерировать файл *.resx, содержащий информацию, необходимую для загрузки файла happyDude.bmp (впервые упомянутого в примере DraggingImages) и некоторого строкового ресурса. Графический интерфейс пользователя будет образован единственным типом Button (рис. 20.22).

Рис. 20.22. Приложение ResX

Обработчик события Click для Button добавляет happyDude.bmp и строковый ресурс в файл *.resx, который сохраняется на локальном диске C.

private void btnGenResX_Click(object sender, EventArgs e) {

 // Создание объекта, записывающего данные resx,

 // и указание файла для записи.

 ResXResourceWriter w = new ResXResourceWriter(@"C:\ResXForm.resx");

 // Добавление изображения и строки.

 Image i = new Bitmap ("happyDude.bmp");

 w.AddResource("happyDude", i);

 w.AddResource("welcomeString", "Приветствие формата ресурсов");

 // Фиксация файла.

 w.Generate();

 w.Close();

}

Здесь наибольший интерес представляет собой член ResXResourceWriter.AddResource(). Этот метод является перегруженным, чтобы вы имели возможность вставить как двоичные данные (такие, как изображение happyDude.bmp), так и текстовые (наподобие указанной выше строки). Обратите внимание на то, что каждый из вариантов предполагает использование двух параметров: имени соответствующего ресурса в файле *.resx и непосредственно данных. Метод Generate() фиксирует информацию в файле. В результате вы получаете XML-описание ресурсов изображения и строки. Для проверки откройте новый файл ResXForm.resx с помощью текстового редактора (рис. 20.23).

Рис. 20.23. XML-представление *.resx

 

Создание файла *.resources

Имея файл *.resx, вы можете использовать утилиту resgen.exe, чтобы сгенерировать двоичный эквивалент этого файла. Для этого откройте окно командной строки Visual Studio 2005, перейдите в корневой каталог вашего диска C и выполните следующую команду.

resgen resxform.resx resxform.resources

Теперь вы можете открыть новый файл *.resources с помощью Visual Studio 2005, чтобы увидеть данные в двоичном формате (рис. 20.24).

Рис. 20.24. Двоичное представление *.resources

 

Добавление файла *.resources в компоновочный блок .NET

Теперь можно встроить файл *.resources в компоновочный блок.NET, используя опцию /resources компилятора командной строки C#. Для примера скопируйте соответствующие файлы Program.cs, Form1.cs и Form1.Designer.cs в корневой каталог вашего диска C, откройте окно командной строки Visual Studio 2005 и выполните следующую команду.

csc /resource:resxform.resources /r:System.Drawing.dll *.cs

Если открыть созданный в результате этого компоновочный блок с помощью ildasm.exe, вы увидите, что манифест соответствующим образом обновлен, как показано на рис. 20.25.

Рис. 20.25. Встроенные ресурсы

 

Работа с ResourceWriter

В предыдущем примере мы использовали тип ResXResourceWriter, чтобы сгенерировать XML-файл, содержащий пары имен и значений для каждого ресурса приложения. Полученный в результате файл *.resx был затем обработан утилитой resgen.exe. Наконец, с помощью флага /resource компилятора C# файл *. resources был встроен в компоновочный блок. Но дело в том. что создавать файл *.resx совсем не обязательно (хотя наличие XML-представления ресурсов может оказаться полезным, поскольку оно вполне пригодно для анализа). Если вам не нужен файл *.resx, вы можете использовать тип ResourceWriter, с помощью которого двоичный файл *.resources можно создать непосредственно.

private void GenerateResourceFile() {

 // Создание нового файла *.resources .

 ResourceWriter rw;

 rw = new ResourceWriter(@"C:\myResources.resources");

 // Добавление одного изображения и одной строки.

 rw.AddResource("happyDude", new Bitmap("happyDude.bmp"));

 rw.AddResource("welcomeString", "Приветствие формата ресурсов.");

 rw.Generate();

 rw.Close();

}

Полученный файл *.resources можно добавить в компоновочный блок, используя опцию /resources компилятора.

csc /resource:myresources.resources *.cs

Исходный код. Проект ResXWriter размещен в подкаталоге, соответствующем главе 20.

 

Генерирование ресурсов в Visual Studio 2005

С файлами *.resx и *.resources можно, конечно, работать вручную в командной строке, но Visual Studio 2005 предлагает средства автоматизации создания и встраивания ресурсов в проект. Для примера создайте новое приложение Windows Forms, назвав его MyResourcesWinApp. Открыв для созданного проекта окно Solution Explorer, вы увидите, что теперь с каждой формой в вашем приложении автоматически связывается файл *.resx (рис. 20.26).

Рис. 20.26. Автоматическое генерирование файлов *.resx в Visual Studio 2005

При добавлении вами ресурсов (например, изображений в PictureBox) с помощью визуальных инструментов проектирования этот файл *.resx будет изменяться автоматически. Более того, вы не должны вручную обновлять этот файл, чтобы указать пользовательские ресурсы, поскольку Visual Studio 2005 регенерирует этот файл при каждой компиляции проекта. Чтобы гарантировать правильную структуру этого файла, лучше всего позволить среде разработки самой управлять файлом *.resx формы.

Если вы захотите предложить пользовательский набор ресурсов, не связанный непосредственно с данной формой, просто добавьте новый файл *.resx (в нашем примере это файл MyCustomResources.resx), выбрав команду Project→Add New Item из меню (рис. 20.27).

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

Теперь добавьте изображение happyDude.bmp, сначала выбрав Images из крайнего меню, после этого – Add Existing File (рис. 20.29), а затем – указав файл happyDude.bmp в появившемся окне загрузки файла.

Рис. 20.27. Добавление нового файла *.resx

Рис. 20.28. Добавление нового строкового ресурса с помощью редактора файлов *.resx

Рис. 20.29. Добавление нового ресурса *.bmp с помощью редактора файлов *.resx

После этого вы обнаружите, что файл *.bmp скопирован в каталог вашего приложения. Выбрав пиктограмму happyDude в редакторе *.resx и используя возможности свойства Persistеnce, можно потребовать, чтобы данное изображение было непосредственно встроено в компоновочный блок, а не задавалось ссылкой на внешний файл (рис. 20.30).

Рис. 20.30. Встраивание указанных ресурсов

Теперь окно Solution Explorer предлагает новую папку под названием Resources, которая содержит все элементы, встроенные в компоновочный блок. Легко догадаться, что при открытии ресурса Visual Studio 2005 запускает соответствующий редактор. В любом случае, если вы теперь скомпилируете свое приложение, указанные вами строка и изображение будут встроены в компоновочный блок.

 

Чтение ресурсов программными средствами

Теперь, когда вы понимаете суть процесса встраивания ресурсов в компоновочный блок (с помощью csc.exe или Visual Studio 2005), нужно выяснить, как с помощью типа ResourceManager программно прочитать соответствующую информацию для использования в программе. Для этого добавьте в свою форму элементы Button и PictureBox (рис. 20.31).

Рис. 20.31. Обновленный интерфейс пользователя

Теперь обработайте событие Click для Button. Добавьте в обработчик указанного события следующий программный код.

// Не забудьте указать 'using'

// для System.Resources и System.Reflection!

 private void btnGetStringData_Click(object sender, EventArgs e) {

 // Создание менеджера ресурсов.

 ResourceManager rm = new ResourceManager("MyResourcesWinApp.MyCustomResources", Assembly.GetExecutingAssembly());

 // Получение встроенной строки (с учетом регистра!)

 MessageBox.Show(rm.GetString("WelcomeString"));

 // Получение встроенного изображения (с учетом регистра!)

 myPictureBox.Image = (Bitmap)rm.GetObject("HappyDude");

 // Необходимая 'уборка'.

 rm.ReleaseAllResources();

}

Обратите внимание на то, что первый аргумент конструктора ResourceManager представляет собой полное имя файла *.resx (но без расширения файла). Второй параметр является ссылкой на компоновочный блок, содержащий соответствующий встроенный ресурс (в данном случае это текущий компоновочный блок). После создания ResourceManager вы можете вызвать GetString() или GetObject(), чтобы извлечь встроенные данные. Если вы запустите приложение и щелкнете на его кнопке, вы увидите, что извлеченные из компоновочного блока строковые данные отобразятся в MessageBox, а данные изображения – в PictureBox.

Исходный код. Проект MyResourcesWinApp размещен в подкаталоге, соответствующем главе 20.

На этом мы завершаем наш обзор возможностей GDI+ и пространств имен System.Drawing. Если вы заинтересованы в дальнейшем исследовании GDI+ (включая поддержку печати), обратитесь к книге Nick Symmonds, GDI+ Programming in C# and VB.NET (Apress, 2002).

 

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

Чтобы рассмотреть процесс добавления элементов управления в форму, давайте начнем с построения типа Form без помощи мастеров, используя только текстовый редактор и компилятор командной строки C#. Создайте новый файл C# с именем ControlsByHand.cs и добавьте в этот файл следующий программный код, определяющий новый класс MainWindow.

using System;

using System.Drawing;

using System.Windows.Forms;

namespace ControlsByHand {

 class MainWindow: Form {

  // Члены-переменные элементов формы.

  private TextBox firstNameBox = new TextBox();

  private Button btnShowControls = new Button();

  public MainWindow() {

   // Конфигурация формы.

   this.Text = "Простые элементы управления";

   this.Width = 300;

   this.Height = 200;

   CenterToScreen();

   // Добавление в форму нового текстового окна.

   firstNameBox.Text = "Привет";

   firstNameBox.Size = new Size(150, 50);

   firstNameBox.Location = new Point(10, 10);

   this.Controls.Add(firstNameBox);

   // Добавление в форму новой кнопки.

   btnShowControls.Text = "Щелкните здесь";

   btnShowControls.Size = new Size(90, 30);

   btnShowControls.Location = new Point(10, 10);

   btnShowControls.BackColor = Color.DodgerBlue;

   btnShowControls Click += new EventHandler(btnShowControls_Clicked);

   this Controls.Add(btnShowControls);

  }

  // Обработка события Click кнопки.

  private void.btnShowControls_Clicked(object sender, EventArgs e) {

   // Вызов ToString() для каждого элемента управления

   // из коллекции Controls формы.

   string ctrlInfo = "";

   foreach (Control c in this.Controls) {

    ctrlInfo += string.Format.("Элемент: {0}\n:", s.ToString());

   }

   MessageBox.Show(ctrlInfo, "Элементы управления, помещенные в форму");

  }

 }

}

Добавьте в пространство имен ControlsByHand еще один класс, реализующий метод Main() программы.

class Program {

 public static void Main(string[] args) {

  Application.Run(new MainWindow());

 }

}

Теперь скомпилируйте полученный файл C# в командной строке, используя следующую команду.

csc /target:winexe *.cs

Запустив приложение и щелкнув на кнопке формы, вы увидите окно сообщения, в котором будет представлен список всех элементов, помещенных в эту форму (рис. 21.1).

Рис. 21.1. Взаимодействие с коллекцией элементов управления формы

 

Тип Control.ControlCollection

Процедура добавления нового элемента в форму исключительно проста, но свойство Controls требует дополнительного обсуждения. Это свойство возвращает ссылку на вложенный класс с именем ControlCollection, определенный в рамках класса Control. Вложенный тип ControlCollection содержит все элементы управления, помещенные в данную форму. Вы можете получить ссылку на эту коллекцию, чтобы "рассмотреть список" дочерних элементов формы.

// Получение доступа к вложенной коллекции ControlCollection формы.

Control.ControlCollection coll = this.Controls;

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

Таблица 21.1. Члены ControlCollection

Ввиду того, что форма поддерживает коллекцию элементов управления, в Windows Forms очень просто динамически создавать, удалять или как-то иначе обрабатывать визуальные элементы. Предположим, например, что вы хотите отключить все типы Button в данной форме (или выполнить иное подобное действие, например, изменить цвет фона всех TextBox). Для этого можно использовать ключевое слово is C#, чтобы обнаружить нужные элементы и соответственно изменить их состояние.

private void DisableAllButtos() {

 foreach (Control с in this.Controls) {

  if (c is Button) ((Button)c).Enabled = false;

 }

}

Исходный код. Проект ControlsByHand размещен в подкаталоге, соответствующем главе 21.

 

Пространство имен System.Windows.Forms определяет множество "базовых элементов управления", которые можно видеть во многих типичных окнах (это кнопки, надписи, текстовые окна, переключатели и т.д.). Вы, наверное, уже знаете об основных возможностях соответствующих типов, но давайте рассмотрим некоторые наиболее интересные особенности следующих базовых элементов пользовательского интерфейса:

• Label (надпись), TextBox (текстовое окно) и MaskedTextBox (маскированное текстовое окно);

• Button (кнопка);

• CheckBox (кнопка с независимой фиксацией), RadioButton (кнопка с зависимей фиксацией) и GroupBox (групповой блок);

• CheckedListBox (окно отмечаемого списка), ListBox (окно списка) и ComboBox (комбинированное окно).

Освоив работу с этими элементами управления, производными от типа Control, мы с вами обратим внимание на более "экзотические" элементы, такие как MonthCalendar, TabControl, TrackBar, WebBrowser и т.д.

 

Элемент Label

Элемент управления Label (надпись) может содержать информацию, доступную только для чтения (текст или изображение), например, для того, чтобы пояснить пользователю роль и возможности использования остальных элементов управления, помещенных в форму. Предположим, вы создали в Visual Studio 2005 новый проект Windows Forms с именем LabelsAndTextBoxes. В рамках полученного экземпляра типа Form определите метод с именем CreateLabelControl(), который сначала создает и конфигурирует тип Label, а затем добавляет его в коллекцию элементов управления формы,

private void CreateLabelControl() {

 // Создание и конфигурация Label.

 Label lblInstructions = new Label();

 lblInstructions.Name = "lblInstructions";

 lblInstructions.Text = ''Введите значения во все окна текста";

 lblInstructions.Font = new Font("Times New Roman", 9.75F, FontStyle.Bold);

 lblInstructions.AutoSize = true;

 lblInstructions.Location = new System.Drawing.Point(16, 13);

 lblInstructions.Size = new System.Drawing.Size(240, 16);

 // Добавление в коллекцию элементов управления формы.

 Controls.Add(lblInstructions);

}

Чтобы увидеть соответствующую подсказку в верхней части главного окна формы, поместите вызов этой вспомогательной функции в конструктор формы.

public MainWindow() {

 InitializeComponent();

 CreateLabelControl();

 CenterToScreen();

}

В отличие от большинства других элементов, элементы управления Label не могут получать фокус ввода при переходах по клавише табуляции. Однако в .NET 2.0 для любого элемента управления Label можно создать мнемонические клавиши установив для свойства UseMnemonic значение true (именно это значение устанавливается для данного свойства по умолчанию). После этого в свойстве Text надписи можно (с помощью символа амперсанда &) определить комбинацию клавиш для перехода к соответствующему элементу управления.

Замечание. Порядок переходов по табуляции подробнее будет обсуждаться позже, а пока что достаточно заметить, что порядок данного элемента управления при переходах по клавише табуляции устанавливается с помощью свойства TabIndex. По умолчанию значение TabIndex элемента управления соответствует порядку, в котором элементы добавлялись в окно проектирования формы. Поэтому, если вы сначала добавите Label, а затем – Textbox, то для Label значение TabIndex будет установлено равным 0, а для Textbox – равным 1.

Для примера с помощью окна проектирования формы постройте пользовательский интерфейс, состоящий из трех Label и трех Textbox (рис. 21.3). Не забудьте оставить свободное место в верхней части формы для отображения элемента Labels динамически создаваемого в методе CreateLabelControl(), и обратите внимание на то, что здесь каждая надпись содержит подчеркнутую букву. Так выделяются буквы, которые в значении свойства Text надписи были помечены знаком &. Вы, наверное, знаете, что помеченные знаком & символы обеспечивают возможность активизации элемента пользователем с помощью выбора комбинации клавиш ‹Alt+ помеченный символ›.

Рис. 21.3. Назначение мнемоник элементам управления Label

Запустив проект, вы сможете перейти к любому из имеющихся элементов TextBox, используя ‹Alt+n›, ‹Alt+M› или ‹Alt+T›.

 

Элемент TextBox

В отличие от элемента управления Label, элемент управления TextBox (текстовое окно) обычно не является доступным только для чтения (хотя его можно сделать таким, если установить для свойства ReadOnly значение true) и часто используется как раз для того, чтобы позволить пользователю ввести текстовые данные для обработки. Тип TextBox можно настроить на поддержку одной строки текста или множества строк, его можно настроить на маскировку вводимых символов (например, с помощью звездочки, *) и в случае многострочного ввода этот элемент может содержать полосы прокрутки. Вдобавок к возможностям, унаследованным от базовых классов, TextBox определяет несколько своих интересных свойств (табл. 21.2).

Таблица 21.2. Свойства TextBox

Чтобы продемонстрировать некоторые возможности TextBox, поместите в форму три элемента управлений TextBox. Первый элемент TextBox (с именем txtPassword) следует настроить для ввода пароля, т.е. символы, вводимые в поле TextBox, не должны быть видимыми, а вместо них должны появляться символы, заданные значением свойства PasswordChar.

Второй элемент TextBox (с именем txtMultiline) – это окно многострочного текста, которое должно допускать обработку нажатия.клавиши ввода и отображать вертикальную полосу прокрутки, когда введенный текст не умещается в рамках видимого пространства TextBox. Наконец, третий элемент TextBox (с именем txtUppercase) будет настроен на перевод введенных символьных данных в верхний регистр.

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

private void InitializeComponent() {

 …

 // txtPassword

 //

 this.txtPassword.PasswordChar = '*';

 …

  // txtMultiline

 //

 this.txtMultiline.Multiline = true;

 this.txtMultiline.Scrollbars = System.Windows.Forms.ScrollBars.Vertical;

 …

 // txtUpperCase

  //

 this.txtUpperCase.CharacterCasing = System.Windows.Forms.CharacterCasing.Upper;

 …

}

Свойству ScrollBars присваивается значение из перечня ScrollBars, который определяет следующие элементы.

public enum System.Windows.Forms.ScrollBars {

 Both, Horizontal, None, Vertical

}

Свойство CharacterCasing работает в паре с перечнем CharacterCasing, который определен так.

public enum System.Windows.Forms.CharacterCasing {

 Normal, Upper, Lower

}

Сейчас предположим, что мы поместили в форму кнопку Button (с именем btnDisplayData) и добавили для этой кнопки обработчик события Click (щелчок]. Наша реализация соответствующего метода просто отображает значения всех элементов TextBox в окне сообщения.

private void btnDisplayData_Click(object sender, EventArgs e) {

 // Получение данных всех текстовых окон.

 string textBoxData = ";

 textBoxData += string.Format("MultiLine: {0}\n", txtMultiline.Text);

 textBoxData += string.Format("\nPassword: {0}\n", txtPassword.Text);

 textBoxData += string.Format("\nUppercase: {0}\n", txtUpperCase.Text);

 // Отображение полученных данных.

 MessageBox.Show(textBoxData, "Вот содержимое, элементов TextBox");

}

На рис. 21.4 показан один из возможных вариантов ввода (обратите внимание на то. что вы должны нажать клавишу ‹Alt›. чтобы увидеть мнемоники надписей).

Рис. 21.4. Множество "воплощений" типа TextBox

На рис. 21.5 показан результат выполнения щелчка на элементе типа Button.

Рис. 21.5. Извлечение значений из объектов TextBox

 

Элемент MaskedTextBox

В .NET 2.0 предлагается также маскированное текстовое окно, которое позволяет задать последовательность символов, допустимую для принятия буфером ввода (это может быть номер социальной страховки, телефонный номер с кодом региона, почтовый индекс или что-то другое). Маска, с которой производится сравнение (она называется шаблоном или выражением маски), создается с помощью специальных маркеров, встроенных в строковый литерал. Созданное значение выражения маски присваивается свойству Mask. В табл. 21.3 даются описания некоторых масочных маркеров.

Таблица 21.3. Маркеры типа MaskedTextBox

Замечание. Символы, допустимые для использования с типом MaskedTextBox, не вполне соответствуют синтаксису регулярных выражений. Хотя .NET и предлагает специальные пространства имен для работы со стандартными регулярными выражениями (это пространства имен System.Text.RegularExpressions и System.Web.RegularExpressions), тип MaskedTextBox использует синтаксис, аналогичный синтаксису элементов управления COM в VB6.

Вдобавок к свойству Mask, тип MaskedTextBox предлагает члены, определяющие реакцию этого элемента управления на ввод пользователем некорректных данных. Например, BeepOnError (очевидно) заставит элемент управления сгенерировать звуковой сигнал, если ввод не соответствует маске, и некорректный символ к обработке допущен не будет.

Чтобы показать возможности использования MaskedTextBox, добавьте в имеющуюся у вас форму дополнительные элементы Label и MaskedTextBox. Вы, конечно, можете построить шаблон маски непосредственно в программном коде вручную, но в строке свойства Mask в окне свойств предлагается кнопка с многоточием, которая открывает диалоговое окно с целым рядом уже готовых масок (рис. 21.6).

Рис. 21.6. Встроенные значения шаблонов маски для свойства Mask

Выберите подходящий шаблон (например, Phone number – телефонный номер), активизируйте свойство BeepOnError и снова выполните тестовый запуск программы. Вы обнаружите, что теперь вам не позволяется вводить никаких буквенных символов (в случае выбора маски Phone number).

Как и следует ожидать, элемент управления MaskedTextBox в цикле своего существования генерирует различные события, одно из которых – это событие MaskInputRejected, возникающее при вводе пользователем некорректных данных. Обработайте это событие, используя окно свойств, и обратите внимание на то, что вторым входным аргументом сгенерированного обработчика события является тип MaskInputRejectedEventArgs. Этот тип имеет свойство RejectionHint, содержащее краткое описание возникшей ошибки. Для проверки просто отобразите информацию об ошибке в строке заголовка формы.

private void txtMaskedTextBox_MaskInputRejected(object sender, MaskInputRejectedEventArgs e) {

 this.Text = string.Format("Ошибка: {0}", e.RejectionHint);

}

Чтобы гарантировать, что эта ошибка не будет отображаться при вводе пользователем корректных данных, обработайте событие KeyDown для MaskedTextBox и реализуйте в обработчике события восстановление заголовка формы к значению, принятому по умолчанию.

private void txtMaskedTextBox_KeyDown(object sender, KeyEventArgs e) {

 this.Text = "Забавы с Label и TextBox";

}

Исходный код. Проект LabelsAndTextBoxes размещен в подкаталоге, соответствующем главе 21.

 

Элемент Button

Задачей типа System.Windows.Forms.Button является "транспортировка" информации о выборе пользователя, обычно в ответ на щелчок кнопки мыши или нажатие клавиши пользователем. Класс Button (кнопка) получается непосредственно из абстрактного типа ButtonBase, обеспечивающего ряд ключевых возможностей поведения для всех производных типов (таких, как CheckBox, RadioButton и Button). В табл. 21.4 описаны некоторые базовые свойства ButtonBase.

Таблица 21.4. Свойства ButtonBase

Свойство TextAlign типа ButtonBase сильно упрощает задачу позиционирования соответствующего текста. Чтобы позиционировать текст на поверхности Button, используйте значения перечня ContentAlignment (определенного в пространстве имен System.Drawing). Позже вы увидите, что этот же перечень можно использовать и при размещении на поверхности Button изображения.

public enum System.Drawing.ContentAlignment {

 BottomCenter, BottomLeft, BottomRight,

 MiddleCenter, MiddleLeft, MiddleRight,

 TopCenter, TopLeft, TopRight

}

Другим объектом нашего интереса является свойство FlatStyle. Оно используется для управления общим внешним видом элемента управления Button, и ему может быть присвоено любое значение из перечня FlatStyle (определенного в пространстве имен System.Windows.Forms).

public enum System.Windows.Forms.FlatStyle {

 Flat, Popup, Standard, System

}

Для демонстрации возможностей использования типа Button создайте новое приложение Windows Forms с именем Buttons. В окне проектирования добавьте в форму три типа Button (с именами btnFlat, btnPopup и btnStandard) и установите для каждого Button соответствующие значения свойства FlatStyle (FlatStyle.Flat, FlatStyle.Popup и FlatStyle.Standard). Также установите для каждого Button подходящие значения свойства Text и обработайте событие Click для кнопки btnStandard. Как вы вскоре увидите, при щелчке пользователя на этой кнопке позиция текста на кнопке будете меняться в результате изменения значения свойства TextAlign.

Теперь добавьте последний, четвертый элемент Button (с именем btnImage) для поддержки фонового изображения (устанавливаемого с помощью свойства BackgroundImage) и маленькую пиктограмму (устанавливаемую с помощью свойства Image), которая тоже будет динамически перемещаться при щелчке на кнопке btnStandard. Для свойств BackgroundImage и Image вы можете использовать любые файлы изображений, и подходящие файлы изображений есть в папке с исходным программным кодом примера.

Средства проектирования формы создают почти весь необходимый подготовительный программный код в InitializeComponent(), и нам остается только использовать перечень ContentAlignment для перемещения текста на btnStandard и пиктограммы на btnImage. В следующем фрагменте программного кода обратите внимание на то, что для получения списка имен из перечня ContentAlignment вызывается статический метод Enum.GetValues().

partial class MainWindow: Form {

 // Используется для текущего значения выравнивания текста.

 ContentAlignment currAlignment = ContentAlignment.MiddleCenter;

 int currEnumPos = 0;

 public MainWindow() {

  InitializeComponent();

  CenterToScreen();

 }

 private void btnStandard_Click (object sender, EventArgs e) {

  // Получение всех значений перечня ContentAlignment,

  Array values = Enum.GetValues(currAlignment.GetType());

  // Чтение текущей позиции в перечне

  // и циклический возврат.

  currEnumPos++;

  if (currEnumPos ›= values.Length) currEnumPos = 0;

  // Чтение текущего значения перечня.

  currAlignment = (ContentAlignment)Enum.Parse(currAlignment.GetType(), values.GetValue(currEnumPos).ToString());

  // Вывод текста и его выравнивание на btnStandard.

  btnStandard.TextAlign = currAlignment;

  btnStandard.Text = сurrAlignment.ToString();

  // Размещение пиктограммы на btnImage.

  btnImage.ImageAlign = currAlignment;

 }

}

Теперь запустите свою программу. При щелчке на средней кнопке вы увидите, что текст займет позицию и изменится в соответствии с текущим значением переменной currAlignment. Пиктограмма в пределах btnImage тоже займет позицию, cоответствующую этому значению. На рис. 21.7 показан вывод программы.

Рис. 21.7. Вариации типа Button

Исходный код. Проект Buttons размещён в подкаталоге, соответствующем главе 21.

 

Элементы CheckBox, RadioButton и Group Box

Пространство имен System.Windows.Forms определяет целый ряд других типов, расширяющих возможности ButtonBase, и это, в частности, тип CheckBox (кнопка с независимой фиксацией, может поддерживать до трех возможных состояний) и тип RadioButton (кнопка с зависимой фиксацией, может иметь два состояния – "включена" и "выключено"). Подобно типу Button, эти типы тоже наследуют заметную долю своих функциональных возможностей от базового класса Control. Однако каждый класс определяет и свои уникальные дополнительные возможности. Сначала мы рассмотрим базовые свойства элемента управлений CheckBox, описанные в табл. 21.5.

Таблица 21.5. Свойства CheckBox

Тип RadioButton не требует пространных комментариев, поскольку этот тип представляет собой лишь немного модифицированный CheckBox. Члены RadioButton почти идентичны членам типа CheckBox. Единственной существенной разницей оказывается поддержка события CheckedChanged, которое (как и следует ожидать) генерируется тогда, когда изменяется значение Checked. Кроме того, тип RadioButton не поддерживает свойство ThreeState, поскольку кнопка типа RadioButton должна быть или включена, или выключена.

Обычно наборы объектов RadioButton группируются вместе, чтобы функционировать, как целое, в соответствии с логикой создаваемой формы. Например, для набора из четырех типов RadioButton. обеспечивающих выбор цвета для автомобиля, обычно нужно гарантировать, чтобы в каждый момент времени мог быть отмечен только один из этих типов. Вместо создания вручную программного кода для решения этой задачи, можно просто использовать элемент управления GroupBox (групповой блок), гарантирующий, что все соответствующие Типы RadioButton будут работать во взаимоисключающем режиме.

Чтобы проиллюстрировать работу с CheckBox, RadioButton и GroupBox, мы создадим новое приложение Windows Forms с именем CarConfig, которое будет расширено в следующих нескольких разделах. Главная форма позволяет пользователю ввести (и подтвердить) информацию о новом транспортном средстве, которое пользователь намеревается купить. Резюме заказа отображается типом Label после щелчка на кнопке Подтвердить заказ. На рис. 21.8 показан исходный вид соответствующего пользовательского интерфейса.

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

Рис. 21.8 Исходный пользовательский интерфейс формы CarConfig

Первой нашей задачей является настройка типа CheckBox. Как и в случае любого другого производного от Control типа, после установки внешнего вида элемента управления его следует добавить во внутреннюю коллекцию элементов управления формы.

private void InitializeComponent() {

 …

 // checkFloorMats

 //

 this.checkFloorMats.Name = "checkFloorMats";

 this.checkFloorMats.Text = "Запасные коврики для машины";

 this.Controls.Add(this.checkFloorMats);

 …

}

Затем нужно сконфигурировать GroupBox и содержащиеся в нем типы RadioButton. Чтобы разместить элемент управления в рамках GroupBox, нужно добавить элемент в коллекцию Controls типа GroupBox (точно так же, как вы добавляли элементы управления в коллекцию Controls формы). Чтобы сделать ситуацию интереснее, используйте окно свойств и задайте обработку событий Enter и Leave для объекта GroupBox, как показано ниже.

private void InitializеComponent() {

 …

 // RadioRed

 this.radioRed.Name = "radioRed";

 this.radioRed.Size = nеw System.Drawing.Size(04, 23);

 this.radioRed.Text = ''Красный";

 //

 // groupBoxColor

 //

 …

 this.groupBoxColor.Controls.Add(this.radioRed);

 this.groupBoxColor.Text = "Цвет";

 this.groupBoxColor.Enter += new System.EventHandler(this.groupBoxColor_Enter);

 this.groupBoxColor.Leave += new System.EventHandler(this.groupBoxColor_Leave);

 …

}

Понятно, что нет никакой необходимости выполнять захват событий Enter и Leave в GroupBox. Однако, для примера, обновите в обработчиках событий текст заголовка GroupBox, как показано ниже.

// Индикация посещения группы.

private void groupBoxColor_Leave(object sender, EventArgs e) {

 groupBoxColor.Text = "Цвет: спасибо, за посещение этой группы…";

}

private void groupBoxColor_Enter(object sender, EventArgs e) {

 groupBoxColor.Text = "Цвет: вы находитесь в этой группе…";

}

Последними элементами графического интерфейса в этой форме будут типы Label и Button, которые также будут сконфигурированы и вставлены в коллекцию Controls формы с помощью InitializeComponent(). Тип Label используется для отображения информации заказа, формирующейся в обработчике события Click кнопки Button подтверждения заказа, как показано ниже.

private void btnOrder_Click(object sender, System.EventArgs e) {

 // Построение строки для отображения информации.

 string orderInfo = "";

 if (checkFloorMats.Checked) orderInfo += "Вы хотите заказать коврики.\n";

 if (radioRed.Checked) orderInfo += "Вы выбрали красный цвет.\n";

 if (radioYellow.Checked) orderInfo += "Вы выбрали желтый цвет.\n";

 if (radioGreen.Checked) orderInfo += "Вы выбрали зеленый цвет.\n";

 if (radioPink.Checked) orderInfo += "А почему РОЗОВЫЙ цвет?\n";

 // Отправка строки элементу Label.

 infoLabel.Text = orderInfo;

}

Обратите внимание на то, что как CheckBox, так и RadioButton поддерживают свойство Checked, которое позволяет выяснить текущее состояние элемента. Кроме того, напомним, что если вы сконфигурировали CheckBox с тремя состояниями, то состояние элемента нужно проверять с помощью свойства CheckState.

 

Элемент CheckedListBox

Теперь, завершив исследование базовых элементов управления Button, давайте рассмотрим набор типов списка, в частности CheckedListBox, ListBox и ComboBox. Элемент управления CheckedListBox (окно отмечаемого списка) позволяет сгруппировать соответствующие элементы CheckBox в список, допускающий прокрутку. Предположим, что вы добавили в форму элемент управления CarConfig, дающий пользователю возможность указать на выбор ряд характеристик, которым должна удовлетворять система звуковоспроизведения автомобиля (рис. 21.9).

Рис. 21.9. Тип CheckedListBox

Чтобы добавить в CheckedListBox новые элементы, вызовите Add() для каждого элемента или используйте метод AddRange() с массивом объектов (строк, если быть точным), представляющих весь набор отмечаемых элементов управления. Следует знать о том, что в режиме проектирования любой тип списка можно заполнить с помощью свойств Items в окне свойств (просто щелкните на кнопке с многоточием и введите подходящие строковые значения). Вот часть программного кода InitializeComponent(), соответствующая конфигурации CheckedListBox.

private void InitializeComponent() {

 …

 // checkedBoxRadioOptions

 //

 this.checkedBoxRadioOptions.Items.AddRange(new object[] {

  "Фронтальная АС", "8-канальный звук",

  "CD-проигрыватель", "Кассетный проигрыватель",

  "Тыловая AC", "Ультра-бас(сабвуфер)"

 });

 …

 this.Controls.Add(this.checkedBoxRadioOptions);

}

Теперь обновите логику обработки события Click для кнопки Подтвердить заказ. Выясните, какие из элементов CheckedListBox в настоящий момент отмечены, и добавьте их в строку orderInfo. Вот как должен выглядеть соответствующий программный код.

private void btnOrder_Click(object sender, EventArgs e) {

 // Построение строки с информацией для отображения.

 string orderInfo = "";

 …

 orderInfo += "-------------------------------\n";

 // Для каждого элемента из CheckedListBox.

 for (int i = 0; i ‹ checkedBoxRadioOptions.Items.Count; i++) {

  // Отмечен ли элемент?

  if (checkedBoxRadioOptions.GetItemChecked(i)) {

   // Получение текста элемента и добавление к orderInfo.

   orderInfo += "Опция радио: ";

   orderInfo += checkedBoxRadioOptions.Items[i].ToString();

   orderInfo += "\n";

  }

 }

 …

}

В качестве заключительного замечания относительно типа CheckedListBox обращаем ваше внимание на то, что этот тип поддерживает многоколоночное представление, устанавливаемое с помощью унаследованного свойства MultiColumn. Поэтому, если вы добавите в программный код оператор

checkedBoxRadioOptions.MultiColumn = true;

вы увидите многоколоночный CheckedListBox, как показано на рис. 21.10.

Рис. 21.10. Многоколоночный тип CheckedListBox

 

Элемент Listbox

Как уже упоминалось выше, тип CheckedListBox наследует большинство своих возможностей от типа ListBox (окно списка). Чтобы продемонстрировать возможности использования типа ListBox, давайте добавим в наше приложение CarConfig возможность выбора пользователем марки автомобиля (BMW, Yugo и т.д.). Нa рис. 21.11 показан внешний вид того пользовательского интерфейса, который мы хотим получить.

Рис. 21.11. Тип ListBox

Как всегда, начните с создания члена-переменной для работы с типом (в данном случае это тип ListBox). Затем сконфигурируйте элемент управления в соответствии со следующим фрагментом из InitializeComponent().

private void InitializeComponent() {

 …

 // carMakeList

 //

 this.carMakeList.Items.AddRange(new object[] {"BMW", "Caravan", "Ford", "Grand Am", "Jeep", "Jetta", "Saab", "Viper", "Yugo"});

 …

 this.Controls.Add(this.carMakeList);

}

Изменения обработчика событий btnOrder_Click() также очень просты.

private void btnOrder_Click(object sender, EventArgs e) {

 // Построение строки для отображения информации.

 string orderInfo = "";

 …

 // Получение выбранного элемента (не индекса!) .

 if (carMakeList.SelectedItem != null) orderInfo += "Марка: " + carMakeList.SelectedItem + "\n";

 …

}

 

Элемент ComboBox

Подобно ListBox, тип ComboBox (комбинированное окно) позволяет пользователю сделать выбор из вполне определенного набора возможностей. Однако тип ComboBox уникален в том, что пользователю также позволяется вставить дополнительные элементы. Напомним, что ComboBox получается из ListBox (а последний, в свою очередь, получается из Control). Для иллюстрации возможностей использования рассматриваемого элемента добавьте в форму приложения CarConfig еще один элемент управления, который позволит ввести имя продавца, с которым пользователь предпочитает иметь дело. Если имени нужного продавца в списке нет, пользователь может ввести соответствующее имя. Одна из возможных модификаций интерфейса показана на рис 21.12 (можете назначить продавцам такие имена, какие захотите).

Рис. 21.12. Тип ComboBox

Соответствующая модификация начинается с настройки самого ComboBox. Как видите, используемая здесь программная логика аналогична логике ListBox.

private void InitializeComponent() {

 …

 // comboSalesPerson

 //

 this.comboSalesPerson.Items.AddRange(new object[] {"Малышка Би-Би", "Дэн \' Машина\'", "Джой Колесо", "Тимон Фара"});

 …

 this.Controls.Add(this.comboSalesPerson);

}

Модификация обработчика событий btnOrder_Click() снова оказывается очень простой.

private void btnOrder_Click(object sender, EventArgs e) {

 // Построение строки для отображения информации.

 string orderInfo = "";

 // Использование свойства Text для имени продавца,

 // указанного пользователем.

 if (comboSalesPerson.Text != "") orderInfo += "Продавец: " + comboSalesPerson.Text + "\n";

 else orderInfo += "Вы не указали имя продавца!" + "\n";

 …

}

 

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

Свойству TabStop можно присвоить значение true (истина) или false (ложь), в зависимости от того, хотите вы или нет, чтобы соответствующий элемент графического интерфейса был доступен по нажатию клавиши табуляции. Если свойству TabStop данного элемента управления присвоено true, то свойству TabOrder устанавливается значение (начиная с нуля), соответствующее порядку активизации этого элемента управления в последовательности нажатий клавиш табуляции. Рассмотрите следующий пример.

// Настройка свойств табуляции.

radioRed. TabIndex = 2;

radioRed. TabStop = true;

 

Мастер настройки переходов по табуляции

В Visual Studio 2005 IDE есть мастер настройки переходов по табуляции, доступ к которому можно получить с помощью выбора View→Tab Order из меню (этот пункт меню доступен только при активном окне проектирования формы). После активизации мастера ваша форма в режиме проектирования будет отображать текущие значения TabIndex всех элементов, Чтобы изменить эти значения, щелкните на порядковом номере выбранного вами элемента (рис. 21.13). Чтобы выйти из мастера настройки переходов по табуляции, достаточно нажать ‹Esc›.

Рис. 21.13. Мастер настройки переходов по табуляции

Установка кнопки, выбираемой по умолчанию

Многие формы, предназначенные для пользовательского ввода (особенно диалоговые окна), предполагают наличие кнопки, которая автоматически отвечает на нажатие пользователем клавиши ‹Enter›. Если вы хотите, чтобы при нажатии пользователем клавиши ‹Enter› в нашей форме автоматически вызывался обработчик события Click для btnOrder, просто установите свойство AcceptButton формы так, как показано ниже.

// При нажатии ‹Enter› все будет происходить так, как будто

// пользователь щелкнул на кнопке btnOrder.

this .AcceptButton = btnOrder;

Замечание. В форме можно также имитировать щелчок на кнопке Cancel (Отмена) при нажатии пользователем клавиши ‹Esc›. Для этого нужно назначить свойству CancelButton имя объекта Button, представляющего кнопку Cancel (Отмена).

 

Итак, мы с вами выяснили, как работать большинством базовых элементов управления Windows Forms (Label, TextBox, и т.д.). Следующей задачей будет рассмотрение элементов графического интерфейса, обладающих более сложными функциональными возможностями. К счастью, только то, что элемент управления выглядит "более экзотическим", обычно означает не то, что с таким элементом будет трудно работать, а то, что вам потребуется немного больше времени на его освоение. На следующих нескольких страницах мы рассмотрим следующие элементы графического интерфейса.

• MonthCalendar

• ToolTip

• TabControl

• TrackBar

• Panel

• Элементы управления UpDown

• ErrorProvider

• TreeView

• WebBrowser

Для начала давайте завершим проект CarConfig, рассмотрев элементы управления MonthCalendar и ToolTip.

 

Элемент MonthCalendar

Пространство имен System.Windows.Forms предлагает очень полезный элемент управления MonthCalendar, который дает пользователю возможность выбрать дату (или диапазон дат), используя дружественный интерфейс. Чтобы продемонстрировать этот элемент управления, обновим приложение CarConfig так, чтобы пользователь мог ввести дату доставки купленного транспортного средства. На рис. 21.14 показана обновленная (и слегка модифицированная в отношении размещения элементов) форма.

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

Рис. 21.14. Тип MonthCalendar

Чтобы получить выбранную в настоящий момент дату программно, можно обновить обработчик события Click для Button, как предлагается ниже.

private void btnOrder_Click(object sender, EventArgs e) {

 // Построение строки для отображения информации.

 string orderInfo = "";

 …

 // Получение даты доставки.

 DateTime d = monthCalendar.SelectionStart;

 string dateStr = string.Format("{0}.{1}.{2}", d.Day, d.Month, d.Year);

 orderInfo += "Машина должна быть доставлена\n" + dateStr;

 …

}

Обратите внимание на то, что информацию о выбранной в настоящий момент дате у элемента управления MonthCalendar можно запросить с помощью свойства SelectionStart. Это свойство возвращает ссылку DateTime, которая запоминается в локальной переменной. Используя свойства типа DateTime, можно извлечь нужную информацию в подходящем вам пользовательском формате.

В настоящий момент мы предполагаем, что пользователь указал только один день для доставки нового автомобиля. Но что делать, если вы хотите предоставить пользователю возможность выбора целого диапазона приемлемой даты доставки? В этом случае пользователю нужно просто "Протащить" указатель мыши через соответcтвующий диапазон дат. Вы уже видели, как можно получить начало диапазона выделения, используя свойство SelectionStart. Конец диапазона выделения можно определить с помощью свойства SelectiоnEnd. Вот как должен выглядеть программный код, модифицированный соответствующим образом.

private void btnOrder_Click(object sender, EventArgs e) {

 // Построение строки для отображения информации.

 string orderInfo = "";

 …

 // Получение диапазона дат доставки …

 DateTime startD = monthCalendar. SelectionStart ;

 DateTime endD = monthCalerdar. SelectionEnd ;

 string.dateStartStr = string.Format("{0}.{1}.{2}", stаrtD.Day, startD.Month, startD.Year);

 string dabeEndStr = string.Format("{0}.{1}.{2}", endD.Daу, endD.Month, endD.Year);

 // Тип DateTime поддерживает перегруженные операции!

 if (dateStartStr != dateEndStr) {

  orderInfo += "Машина должна быть доставлена\n" + "c " + dateStartStr + "по " + dateEndStr;

 } else // Когда выбрано одно значение даты.

  orderInfo += "Машина должна быть доставлена\n" + dateStartStr;

 …

}

Замечание. Windows Forms содержит элемент управления DateTimePicker, который позволяет предложить MonthCalendar в раскрывающемся элементе управления DropDown.

 

Элемент ToolTip

В связи с рассматриваемой формой CarConfig мы должны продемонстрировать еще одну, заключительную, возможность. Многие современные интерфейсы пользователя предлагают так называемые всплывающие подсказки. В пространстве имен System.Windows.Forms эта возможность представлена типом ToolTip. Соответствующие подсказки представляют собой небольшие плавающие окна, в которых отображаются вспомогательные сообщения, когда курсор задерживается вблизи данного элемента интерфейса.

Для примера добавьте такую подсказку для календаря CarConfig. Сначала перетащите новый элемент управления ToolTip из панели инструментов в окно проектирования формы и переименуйте этот элемент управления в calendarTip. Внешний вид элемента ToolTip можно задать, используя окно свойств, например.

private void InitializeComponent () {

 …

 // calendarTip

 //

 this.calendarTip.isBalloon = true;

 this.calendarTip.ShowAlways = true;

 this.calendarTip.ToolTipIcon = System.Windows.Forms.ToolTipIcon.Info;

 …

}

Чтобы связать ToolTip с данным элементом управления, выберите элемент управления, в котором должен активизироваться ToolTip, и соответствующим образом установите свойство ToolTip on (рис. 21.15).

Рис. 21.15. Ассоциация ToolTip с элементом управления

Теперь наш проект CarConfig можно считать завершенным. На рис. 21.16 созданная подсказка показана в действии.

Рис. 21.16. Элемент ToolTip в действии

Исходный код. Проект CarConfig размещен в подкаталоге, соответствующем главе 21.

 

Элемент TabControl

Чтобы проиллюстрировать остальные "экзотические" элементы управления, давайте построим новую форму, поддерживающую TabControl (элемент управления вкладками). Вы, возможно, знаете, что TabControl позволяет селективно скрывать или показывать страницы связанного содержимого с помощью щелчка на соответствующих "закладках". Сначала создайте новое приложение Windows Forms с именем ExoticControls и поменяйте имя исходной формы на MainWindow.

Затем добавьте TabControl в окно проектирования формы и, используя окно свойств, с помощью коллекции Tab Pages откройте редактор страниц (в соответствующей строке окна свойств щелкните на кнопке с многоточием). Появится диалоговое окно конфигурации инструмента. Добавьте в нем шесть страниц и установите свойства Text и Name страниц в соответствии с тем, как показано на рис. 21.17.

Рис. 21.17. Многостраничный элемент управления TabControl

При создании элемента управления TabControl следует учитывать то, что каждая страница представляется объектом TabPage, содержащимся во внутренней коллекции страниц TabControl. Сконфигурированный объект TabControl (подобно любому другому элементу графического интерфейса в форме) добавляется в коллекцию Controls формы. Рассмотрите соответствующий фрагмент метода InitializeComponent().

private void InitializeComponent() {

 …

 // tabControlExoticControls

 //

 this.tabControlExoticControls.Controls.Add(this.pageTrackBars);

 this.tabControlExoticControls.Controls.Add(this.pagePanels);

 this.tabControlExoticControls.Controls.Add(this.pageUpDown);

 this.tabControlExoticControls.Controls.Add(this.pageErrorProvider);

 this.tabControlExpticControls.Controls.Add(this.pageTreeView);

 this.tabControlExoticControls.Controls.Add(this.pageWebBrowser);

 this.tabControlExoticControls.Location = new System.Drawing.Point(13, 13);

 this.tabControlExoticControls.Name = "tabControlExoticControls";

 this.tabControlExoticControls.SelectedIndex = 0;

 this.tabControlExoticControls.Size = new System.Drawing.Size(463, 274);

 this.tabControlExoticControls.TabIndex = 0;

 this.Controls.Add(this.tabControlExoticControls);

}

Теперь, имея базовую форму, поддерживающую набор вкладок, вы можете настроить каждую страницу для демонстрации остальных "экзотических" элементов управления. Сначала давайте рассмотрим роль TrackBar.

Замечание. Элемент управления TabControl обеспечивает поддержку событий Selected, Selecting, Deselected и Deselecting. Это может оказаться полезным тогда, когда требуется динамически генерировать соответствующие элементы в пределах страницы.

 

Элемент TrackBar

Элемент управления TrackBar дает пользователям возможность выбора из диапазона значений, используя нечто, похожее на полосу прокрутки. При работе с этим типом нужно установить минимальное и максимальное значения диапазона, минимальное и максимальное значения приращения, а также начальное положение ползунка. Соответствующие значения можно установить с помощью свойств, описанных в табл. 21.6.

Таблица 21.6. Свойства TrackBar

Для примера обновите первую вкладку элемента TabControl, разместив на ней три элемента TrackBar, для каждого из которых верхнее значение диапазона равно 255, а нижнее – нулю, При смещении пользователем любого из ползунков приложение перехватывает событие Scroll и динамически создает новый тип System.Drawing.Color на основе новых значений ползунков. Этот тип Color будет использоваться для того, чтобы отображать соответствующим цветом элемент PictureBox (с именем colorBox) и соответствующие RGB-значения в пределах типа Label (с именем lblCurrColor). На рис. 21.18 первая страница окна показана в завершенном виде.

Рис. 21.18. Страница TrackBar

Сначала, используя окно проектирования формы, разместите три элемента управления TrackBar на первой вкладке и назначьте соответствующим членам-переменным подходящие имена (redTrackBar, greenTrackBar и blueTrackBar). Затем обработайте событие Scroll для каждого TrackBar. Вот подходящий программный код InitializeComponent() для blueTrackBar (программный код остальных полос почти идентичен данному, за исключением имени обработчика события Scroll).

private void InitializeComponent() {

 …

 //

 // blueTrackBar

 //

 this.blueTrackBar.Maximum = 255;

 this.blueTrackBar.Name = "blueTrackBar";

 this.blueTrackBar.TickFrequency = 5;

 this.blueTRackBar.TickStyle = System.Windows.Forms.TickStуle.TopLeft;

 this.blueTrackBar.Scroll += new System.EventHandler(this.blueTrackBar.Scroll);

 …

}

Заметим, что минимальным значением по умолчанию для TrackBar является 0, поэтому его явно устанавливать не нужно. В обработчиках событий Scroll для каждого TrackBar выполняется вызов вспомогательной функции UpdateColor(), которую нам еще предстоит написать.

private void blueTrackBar_Scroll(object sender, EventArgs e) {

 UpdateColor();

}

Функция UpdateColor() отвечает за решение двух главных задач. Во-первых, нужно прочитать текущее значение каждого TrackBar и использовать эти данные для вычисления нового Color с помощью Color.FromArgb(). Имея новый готовый цвет, следует соответствующим образом обновить член-переменную PictureBox (с именем colorBox), чтобы установить текущий цвет фона. Наконец, UpdateColor() комбинирует значения ползунков в строке, размещаемой в элементе Label(lblCurrColor), как показано ниже.

private void UpdateColor() {

 // Получение нового цвета на основе значений ползунков.

 Color с = Color.FromArgb(redTrackBar.Value, greenTrackBar.Value, blueTrackBar.Value);

  // Изменение цвета в PictureBox.

 colorBox.BackColor = c;

 // Установка текста для надписи.

 lblCurrColor.Text = string.Format("Текущие цветовые значения: ({0}, {1}, (2})", redTrackBar.Value, greenTrackBar.Value, blueTrackBar.Value);

}

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

public MainWindow() {

 InitializeComponent();

 CenterToScreen();

 // Установка исходного положения ползунков.

 redTrackBar.Value = 100;

 greenTrackBar.Value = 255;

 blueTrackBar.Value = 0;

 UpdateColor();

}

 

Элемент Panel

Как вы уже видели, элемент управления GroupBox может использоваться для того, чтобы логически объединить ряд элементов управления (например, переключателей) и заставить их функционировать во взаимосвязи. Элемент управления Panel в этом смысля является близким к GroupBox. Элементы управления Panel тоже используются для группировки родственных элементов управления в логические единицы. Одним из различий является то, что тип Panel получается из класса ScrollableControl, поэтому Panel может поддерживать полосы прокрутки, чего нет у GroupBox.

Элементы управления Panel могут также использоваться для "консервации" содержимого экрана. Например, если у вас есть группа элементов управления, которые занимают всю нижнюю половину формы, вы можете поместить эту группу в Panel половинного размера и установить значение true (истина) для свойства AutoScroll. Тогда пользователь сможет использовать полосу (или полосы) прокрутки, чтобы просмотреть весь набор элементов. К тому же, если для свойства BorderStyle элемента Panel установить значение None, то этот тип можно будет использовать для группировки набора элементов, которые очень легко показать или скрыть способом. совершенно прозрачным в отношении конечного пользователя.

Для примера давайте добавим на вторую страницу TabControl два типа Button (с именами btnShowPanel и btnHidePanel) и один тип Panel, который содержит пару текстовых блоков (txtNormalText и txtUpperText) с инструктирующим элементом Label. (Какие именно элементы находятся в Panel, для этого примера не очень важно.) На рис. 21.19 показан окончательный вид соответствующей страницы.

С помощью окна свойств обработайте событие TextChanged для первого элемента TextBox, и в сгенерированном обработчике события поместите в txtUpperText преобразованный в верхний регистр текст, введенный в txtNormalText.

private void txtNormal'Text_TextChanged(object sender, EventArgs e) {

 txtUpperText.Text = txtNormalText.Text.ToUpper();

}

Рис. 21.19. Страница Panel

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

private void btnShowPanel_Click(object sender, EventArgs e) {

 panelTextBoxes.Visible = true;

}

private void btnHidePanel_Click(object sender, EventArgs e) {

 panelTextBoxes.Visible = false;

}

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

 

Элементы UpDown

В рамках Windows Forms предлагается два элемента, функционирующие, как элементы управления с прокруткой (также известные, как элементы управления UpDown). Подобно ComboBox и ListBox, эти новые элементы также позволяют пользователю выбрать элемент из некоторого диапазона возможных элементов.

Разница в том, что при использовании элемента управления DomainUpDown или NumericUpDown варианты выбираются с помощью небольших стрелок, направляющих вверх и вниз. Взгляните, например, на рис. 21.20.

Рис. 21.20. Работа с типами UpDown

С учетом того, что вы уже освоили работу с подобными типами, вы не должны встретить особых сложностей при работе с элементами UpDown. Элемент DomainUpDown дает пользователю возможность сделать выбор из набора строковых данных. Элемент NumericUpDown позволяет выбрать подходящие значений из диапазона числовых данных. Каждый из этих элементов является прямым потомком общего базового класса UpDownBase. В табл. 21.7 описаны некоторые важные свойства этого класса.

Таблица 21.7. Свойства UpDownBase

Элемент управления DomainUpDown добавляет небольшой набор свойств, позволяющих конфигурировать и обрабатывать текстовые данные этого элемента (табл. 21.8).

Таблица 21.8. Свойства DomainUpDown

Элемент NumericUpDown так же прост (табл. 21.9).

Таблица 21.9. Свойства NumericUpDown

Вот та часть InitializeComponent (), которая задает конфигурацию NumericUpDown и DomainUpDown на этой странице.

private void InitializeComponent() {

 …

 //

 // numericUpDown

 //

 …

 this.numericUpDown.Maximum = new decimal(new int[] {5000, 0, 0, 0});

 this.numericUpDown.Name = "numericUpDown";

 this.numericUpDown.Thousands.Separator = true;

 //

 // domainUpDown

 //

 this.domainUpDown.Items.Add("Второй вариант");

 this.domainUpDown.Items.Add("Последний вариант");

 this.domainUpDown.Items.Add("Первый вариант");

 this.domainUpDown.Items.Add("Третий вариант");

 this.domainUpDown.Name = "domainUpDown";

 this.domainUpDown.Sorted = true;

 …

}

Обработчик события Click для типа Button этой страницы просто запрашивает у каждого типа его текущее значение и размещает его в рамках подходящего типа Label (с именем lblCurrSel) в виде форматированной строки, как показано ниже.

private void ntnGetSelections_Click(object sender, EventArgs e) {

 // Получение информации от элементов UpDown.…

 lblCurrSel.Text = string.Format("Строка: {0}\nЧисло: {1}", domainUpDown.Text, numericUpDown.Value);

}

 

Элемент ErrorProvider

В большинстве приложений Windows Forms приходится, так или иначе, проверять правильность пользовательского ввода. Это особенно касается диалоговых окон, поскольку вы должны информировать пользователя о том, что он сделал ошибку, прежде чем пользователь продолжит ввод. Тип ErrorProvider может использоваться для того, чтобы обеспечить пользователю визуальные подсказки в отношении ошибок ввода. Предположим, например, что у вас есть форма, содержащая элементы TextBox и Button. Если пользователь введет в TextBox более пяти символов и TextBox утрачивает фокус ввода, можно отобразить информацию, показанную на рис. 21.21.

Рис. 21.21 Действие ErrorProvider

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

Если вы хотите использовать такой вид проверки ввода, то вам. прежде всего, нужно изучить свойства класса Control, описания которых приводятся в табл. 21.10.

Таблица 21.10. Свойства и события Control

Каждый элемент графического интерфейса может установить для свойства CausesValidation значение true (истина) или false (ложь), причем значением по умолчанию является true. Если вы установите для указанных данных значение true, данный элемент управления при получении им фокуса ввода заставит остальные элемент управления в форме выполнить проверку ввода. При получении фокуса ввода проверяющим элементом управления генерируются события Validating и Validated для каждого элемента управления. В контексте обработчика события Validating вы должны конфигурировать соответствующий ErrorProvider. Также можно, но необязательно, обработать событие Validated, чтобы определить, когда элемент управления закончит цикл проверки.

Тип ErrorProvider предлагает очень небольшой набор членов. Для нашего примера самым важным является свойство BlinkStyle, которому можно присвоить любое значение из перечня ErrorBlinkStyle. Описания этих значений даются в табл. 21.11.

Таблица 21.11. Значения ErrorBlinkStyle

Для примера добавьте на вкладку ErrorProvider элементы управления Button, TextBox и Label, как показано на рис. 21.21. Затем перетащите в окно проектирования формы элемент ErrorProvider и присвойте этому элементу имя tooManyCharactersErrorProvider. Вот соответствующий фрагмент программного кода InitializeComponent().

private void InitializeComponent() {

 …

 //

 // tooManyCharactersErrorProvider

 //

 this.tooManyCharaсtersErrorProvider.BlinkRate = 500;

 this.tooManyCharactersErrorProvider.BlinkStyle = System.Windows.Forms.ErrorBlinkStyle.AlwaysBlink;

 this.tooManyCharactersErrorProvider.ContainerControl = this;

}

После настройки внешнего вида ErrorProvider вы должны выполнить привязку ошибки к TextBox в контексте обработчика события Validating, как показано ниже.

private void txtInput_Validating(object sender, CancelEventArgs е) {

 // Длина текста меньше 5?

 if (txtInput.Text.Length › 5) {

  errorProvider1.SetError(txtInput, "Больше 5 нельзя!");

 } else // Все в порядке, не показывать ничего.

  errorProvider1.SetError(txtInput, ");

}