• 1.1. Основы работы Windows API в VCL-приложениях
  • 1.1.1. Что такое Windows API
  • 1.1.2. Как получить справку по функциям Windows API
  • 1.1.3. Дескрипторы вместо классов
  • 1.1.4. Формы VCL и окна Windows
  • 1.1.5. Функции обратного вызова
  • 1.1.6. Сообщения Windows
  • 1.1.7. Создание окон средствами VCL
  • 1.1.8. Обработка сообщений с помощью VCL
  • 1.1.9. Сообщения, определяемые пользователем
  • 1.1.10. Особые сообщения
  • 1.1.11. Графика в Windows API
  • 1.1.12. ANSI и Unicode
  • 1.1.13. Строки в Windows API
  • 1.2. Примеры использования Windows API
  • 1.2.1. Пример EnumWnd
  • 1.2.2. Пример Line
  • 1.2.3. Пример CoordLabel
  • 1.2.4. Пример PanelMsg
  • 1.2.5. Пример NumBroadcast
  • 1.2.6. Пример ButtonDel
  • 1.2.7. Пример GDIDraw
  • 1.2.8. Пример BitmapSpeed
  • 1.3. Обобщающие примеры
  • 1.3.1. Обобщающий пример 1 — Информация о процессах
  • 1.3.1.1. Получение списка процессов
  • 1.3.1.2. Получение списка и свойств окон
  • 1.3.2. Обобщающий пример 2 — Ассоциированные файлы и предотвращение запуска второй копии приложения
  • 1.3.2.1. Ассоциирование расширения с приложением
  • 1.3.2.2. Командная строка
  • 1.3.2.3. Поиск уже запущенной копии приложения
  • 1.3.2.4. Перевод приложения на передний план
  • 1.3.3. Обобщающий пример 3 — "Дырявое" окно
  • 1.3.3.1. Сообщение WM_NCHCHITTEST
  • 1.3.3.2. Регионы
  • 1.3.3.3. Сообщения WM_SIZE и WM_SIZING
  • 1.3.3.4. А теперь — все вместе
  • 1.3.4. Обобщающий пример 4 — Линии нестандартного стиля
  • 1.3.4.1. Получение координат точек прямой
  • 1.3.4.2. "Резиновая" линия и растровые операции
  • 1.3.4.3. Кривые Безье
  • 1.3.4.4. Траектории 
  • 1.3.4.5. Интерактивная кривая
  • Глава 1

    Windows API и Delphi

    Библиотека VCL, делающая создание приложений в Delphi таким быстрым и удобным, все же не позволяет разработчику задействовать все возможности операционной системы. Полный доступ к ним дает API (Application Programming Interface) — интерфейс, который система предоставляет программам. С его помощью можно получить доступ ко всем документированным возможностям системы.

    Программированию в Windows на основе API посвящено много книг, а также материалов в Интернете. Но если все делать только с помощью API, то даже для того, чтобы создать пустое окно, потребуется написать несколько десятков строк кода, а о визуальном проектировании такого окна придется вообще забыть. Поэтому желательно как-то объединить мощность API и удобство VCL. О том, как это сделать, мы и поговорим в этой главе. В первой части главы рассматриваются общие принципы использования API и интеграции этого интерфейса с VCL. Во второй части разбираются простые примеры, иллюстрирующие теорию. В третьей части представлено несколько обобщающих примеров использования API — небольших законченных приложений, использующих различные функции API для решения комплексных задач.

    1.1. Основы работы Windows API в VCL-приложениях

    В данном разделе будет говориться о том. как совместить Windows API и компоненты VCL. Предполагается, что читатель владеет основными методами создания приложений с помощью VCL а также синтаксисом языка Delphi, поэтому на этих вопросах мы останавливаться не будем. Так как "официальные" справка и примеры работы с API предполагают работу на С или C++, и это может вызвать трудности у человека, знакомого только с Delphi, здесь также будет уделено внимание тому, как правильно читать справку и переводить содержащийся в ней код с C/C++ на Delphi.

    1.1.1. Что такое Windows API

    Windows API — это набор функций, предоставляемых операционной системой каждой программе. Данные функции находятся в стандартных динамически компонуемых библиотеках (Dynamic Linked Library. DLL), таких как kernel32.dll, user32.dll, gdi32.dll. Указанные файлы располагаются в системной директории Window. Вообще говоря, каждая программа должна самостоятельно заботиться о том. чтобы подключить эти библиотеки. DLL могут подключаться к программе статически и динамически. В первом случае связь с библиотекой прописывается в исполняемом файле программы, и система при запуске этой программы сразу же загружает в ее адресное пространство и библиотеку. Если требуемая библиотека на диске не найдена, запуск программы будет невозможен. В случае динамического подключения программа загружает библиотеку в любой удобный для нее момент времени с помощью функции

    LoadLibrary
    . Если при этом возникает ошибка из-за того, что библиотека не найдена на диске, программа может самостоятельно решить, как на это реагировать.

    Статическая загрузка проще динамической, но динамическая гибче. При динамической загрузке программист может, во-первых, выгрузить библиотеку, не дожидаясь окончания работы программы. Во-вторых, программа может продолжить работу, даже если библиотека не найдена. В-третьих, возможна загрузка тех DLL, имена которых неизвестны на момент компиляции. Это позволяет расширять функциональность приложения после передачи его пользователю с помощью дополнительных библиотек (в англоязычной литературе такие библиотеки обычно называются plug-in).

    Стандартные библиотеки необходимы самой системе и всем программам, они всегда находятся в памяти, и поэтому обычно они загружаются статически. Чтобы статически подключить в Delphi некоторую функцию Windows API. например, функцию

    GetWindowDC
    из модуля user32.dll, следует написать конструкцию вида

    function GetWindowDC(Wnd: HWnd); HDC; stdcall;

     external 'user32.dll' name 'GetWindowDC';

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

    GetWindowDC
    из библиотеки user32.dll. После такого объявления компилятор будет знать, как вызывать эту функцию, хотя ее реальный адрес будет внесен в таблицу импорта только при запуске программы. Обратите внимание, что функция
    GetWindowDC
    , как и все функции Windows API, написана в соответствии с моделью вызова
    stdcall
    , а в Delphi по умолчанию принята другая модель —
    register
    (модель вызова определяет, как функции передаются параметры). Поэтому при импорте функций из стандартных библиотек необходимо явно указывать эту модель (подчеркнем, что это относится именно к стандартным библиотекам; другие библиотеки могут использовать любую другую модель вызова, разработчик библиотеки свободен в своем выборе). Далее указывается, из какой библиотеки импортируется функция и какое название в ней она имеет. Дело в том, что имя функции в библиотеке может не совпадать с тем, под которым она становится известной компилятор). Это может помочь разрешить конфликт имен при импорте одноименных функций из разных библиотек, а также встречается в других ситуациях, которые мы рассмотрим позже. Главным недостатком DLL следует считать то. что в них сохраняется информация только об именах функций, но не об их параметрах. Поэтому если при импорте функции указать не те параметры, которые подразумевались автором DLL, то программа будет работать неправильно (вплоть до зависания), а ни компилятор, ни операционная система не смогут указать на ошибку.

    Обычно программе требуется много различных функций Windows API. Декларировать их все довольно утомительно. К счастью. Delphi избавляет программиста от этой работы: многие из этих функций уже описаны в соответствующих модулях, достаточно упомянуть их имена в разделе

    uses
    . Например, большинство общеупотребительных функций описаны в модулях
    Windows
    и
    Messages
    .

    Функции API, которые присутствуют не во всех версиях Windows, предпочтительнее загружать динамически. Например, если программа статически импортирует функцию

    SetLayeredWindowsAttributes
    , она не запустится в Windows 9x, где этой функции нет — система, встретив ее упоминание в таблице импорта, прервет загрузку программы. Поэтому, если требуется, чтобы программа работала и в Windows 9x, эту функцию следует импортировать динамически. Отметим, что компоновщик в Delphi помещает в таблицу импорта только те функции, которые реально вызываются программой. Поэтому наличие декларации
    SetLayeredWindowsAttributes
    в модуле Windows не помешает программе запускаться в Windows 9x, если она не вызывает эту функцию.

    1.1.2. Как получить справку по функциям Windows API

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

    Первоисточник информации по технологиям Microsoft для разработчика Microsoft Developer's Network (MSDN). Это отдельная справочная система, не входящая в комплект поставки Delphi. MSDN можно приобрести отдельно или воспользоваться online-версией, находящейся по адресу: http://msdn.microsoft.com (доступ к информации свободный, регистрация не требуется). MSDN содержит не только информацию об API, но и все, что может потребоваться программисту, использующему различные средства разработки от Microsoft. Кроме справочного материала, MSDN включает в себя спецификации стандартов и технологий, связанных с Windows, статьи из журналов, посвященных программированию, главы из некоторых книг. И вся эта информация крайне полезна разработчику. Кроме того, MSDN постоянно обновляется, информация в нем наиболее актуальна. Пример справки из MSDN показан на рис. 1.1.

    Рис. 1.1. Online-вариант MSDN (показана справка по функции

    DeleteObject
    )


    Примечание

    Отметим, что MSDN содержит также описание функций операционной системы Windows СЕ. Интерфейс Windows СЕ API на первый взгляд очень похож на Windows API, но различия между ними есть, и иногда весьма значительные. Поэтому при использовании MSDN не следует выбирать раздел API Reference — он целиком посвящен WinCE API.

    В комплект поставки Delphi входит справочная система, содержащая описание функций Windows API. Справочная система в Delphi до 7-й версии включительно была построена на основе hlp-файлов. Применительно к справке по Windows API это порождало две проблемы. Во-первых, hlp-файлы имеют ограничение по числу разделов в справочной системе, поэтому объединить в одной справке информацию и по Delphi, и по Windows API было невозможно, — эти две справки приходилось читать по очереди. Чтобы открыть файл справки по Windows API, нужно было в редакторе кода поставить курсор на название какой-либо функции API и нажать клавишу <F1>— в этом случае вместо справки по Delphi открывалась справка по Windows API. Второй вариант — в меню Программы найти папку Delphi, а в ней — папку Help\MS SDK Files и выбрать требуемый раздел. Можно также вручную открыть файл MSTools.hlp. В ранних версиях Delphi он находится в каталоге $(Delphi)\Help, в более поздних его нужно искать в $(Program Files)\Common Files. Окно старой справки показано на рис. 1.2.

    Вторая проблема, связанная со справкой на основе hlp-файлов,— это то обстоятельство, что разработчики Delphi, разумеется, не сами писали эту справку, а взяли ту, которую предоставила Microsoft. Microsoft же последнюю версию справки в формате НLР выпустила в тот момент, когда уже вышла Windows 95, но еще не было Windows NT 4. Поэтому про многие функции, прекрасно работающие в NT 4, там написано, что в Windows NT они не поддерживаются, т.к. в более ранних версиях они действительно не поддерживались. В справке, поставляемой с Delphi 7 (и, возможно, с некоторыми более ранними версиями), эта информация подправлена, но даже и там отсутствуют функции, которые появились только в Windows NT 4 (как, например,

    CoCreateInstanceEx
    ). И уж конечно, бесполезно искать в этой справке информацию о функциях, появившихся в Windows 98, 2000, XР. Соответственно, при работе в этих версиях Delphi даже не возникает вопрос, что предпочесть для получения информации о Windows API, — справку, поставляемую с Delphi, или MSDN. Безусловно, следует выбрать MSDN. Справка, поставляемая с Delphi, имеет только одно преимущество по сравнению с MSDN: ее можно вызывать из среды нажатием клавиши <F1>. Но риск получить неверные сведения слишком велик, чтобы это преимущество могло быть серьезным аргументом. Единственная ситуация, когда предпочтительна справка, поставляемая с Delphi, — это случай, если у вас нет достаточно быстрого доступа к Интернету для работы с online-версией MSDN и нет возможности приобрести и установить его offline-версию.

    Рис. 1.2. Старая (на основе hlp-файлов) справка по Windows API (показана функция

    DeleteObject
    )


    Начиная с BDS 2006, Borland/CodeGear реализовала новую справочную систему Borland Help (рис. 1.3). По интерфейсу она очень напоминает offline версию MSDN, а также использует файлы в том же формате, поэтому технологических проблем интеграции справочных систем по Delphi и по Windows API больше не существует. В справку BDS 2006 интегрирована справка по Windows API от 2002–2003 годов (разные разделы имеют разную дату) Справка Delphi 2007 содержит сведения по Windows API от 2006 года, т.е. совсем новые. Таким образом, при работе с Delphi 2007 наконец-то можно полностью отказаться от offline-версии MSDN, а к online-версии обращаться лишь изредка, когда требуется информация о самых последних изменениях в Windows API (например, о тех, которые появились в Windows Vista).

    Примечание

    Несмотря на очень высокое качество разделов MSDN, относящихся к Window API, ошибки иногда бывают и там. Со временем их исправляют. Поэтому, если вы столкнулись с ситуацией, когда есть подозрение, что какая-либо функция Windows API ведёт себя не так, как это описано в вашей offline-справке, есть смысл заглянуть в online-справку — возможно, там уже появились дополнительные сведения по данной функции.

    Рис. 1.3. Окно справки Delphi 2007 (функция

    DeleteObject
    )


    Система Windows написана на C++, поэтому все описания функций Windows API, а также примеры их использования приведены на этом языке (это касается как MSDN, так и справки, поставляемой с Delphi). При этом, прежде всего, необходимо разобраться с типами данных. Большинство типов, имеющихся в Windows API. определены в Delphi. Соответствие между ними показано в табл. 1.1.


    Таблица 1.1. Соответствие типов Delphi системным типам

    Тип Windows API Тип Delphi
    INT
    INT
    UINT
    LongWord
    WORD
    Word
    SHORT
    SmallInt
    USHORT
    Word
    CHAR
    Чаще всего соответствует типу
    Char
    , но может трактоваться также как
    ShortInt
    , т.к. в C++ нет разницы между символьным и целочисленным типами
    UCHAR
    Чаще всего соответствует типу
    Byte
    , но может трактоваться также как
    Char
    DWORD
    LongWord
    BYTE
    Byte
    WCHAR
    WideChar
    BOOL
    LongBool
    int
    Integer
    long
    LongInt
    short
    SmallInt
    unsigned int
    Cardinal

    Название типов указателей имеет префикс P или LP (Pointer или Long Pointer, в 16-разрядных версиях Windows были короткие и длинные указатели. В 32-разрядных все указатели длинные, поэтому оба префикса имеют одинаковый смысл). Например,

    LPDWORD
    эквивалентен типу
    ^DWORD
    ,
    PUCHAR
    ^Byte
    . Иногда после префикса P или LP стоит еще префикс C — он означает, что это указатель на константу. В C++ возможно объявление таких указателей, которые указывают на константное содержимое, т.е. компилятор разрешает это содержимое читать, но не модифицировать. В Delphi такие указатели отсутствуют, и при портировании эти типы заменяются обычными указателями, т.е. префикс C игнорируется.

    Типы

    PVOID
    и
    LPVOID
    соответствуют нетипизированным указателям (
    Pointer
    ).

    Для передачи символов чаще всего используется тип

    TCHAR
    . Windows поддерживает две кодировки: ANSI (1 байт на символ) и Unicode (2 байта на символ; о поддержке Unicode в Windows мы будем говорить далее). Тип
    CHAR
    соответствует символу в кодировке ANSI,
    WCHAR
    — Unicode. Для программ, которые используют ANSI, тип
    TCHAR
    эквивалентен типу CHAR, для использующих Unicode —
    WCHAR
    . В Delphi нет прямого аналога типу
    TCHAR
    . Программист сам должен следить за тем, какой символьный тип требуется в данном месте. Строки в Windows API передаются как указатели на цепочку символов, завершающихся нулем. Поэтому указатель на
    TCHAR
    может указывать как на единичный символ, так и на строку. Чтобы было легче разобраться, где какой указатель, в Windows API есть типы
    LPTCHAR
    и
    LPTSTR
    . Они эквивалентны друг другу, но первый принято использовать там, где требуется указатель на одиночный символ, а второй — на строку. Если строка передается в функцию только для чтения, обычно используют указатель на константу, т.е. тип
    LPCTSTR
    . В Delphi это соответствует PChar для ANSI и PWideChar для Unicode. Здесь следует отметить особенность записи строковых литералов в языках C/C++. Символ \ в литерале имеет специальное значение: после него идет один или несколько управляющих символов. Например, \n означает перевод строки, \t — символ табуляции и т.п. В Delphi таких последовательностей нет, поэтому при переводе примеров из MSDN следует явно писать коды соответствующих символов. Например, литерал
    "а\nb"
    в Delphi превращается в
    'a\'#13'b'
    . После символа 
    \
    может идти число — в этом случае оно трактуется как код символа, т.е. литерал
    "a\0b9"
     в C/C++ эквивалентен литералу '
    а'#0'b'#9
    в Delphi. Если нужно, чтобы строковый литерал включал в себя сам символ \, его удваивают, т.е. литерал
    "\\"
    в C++ соответствует
    '\'
    в Delphi. Кроме того, в примерах кода, приведенных в MSDN, можно нередко увидеть, что строковые литералы обрабатываются макросами
    TEXT
    или
    _T
    , которые служат для унификации записи строковых литералов в кодировках ANSI и Unicode. При переводе такого кола на Delphi эти макросы можно просто опустить. С учетом сказанного такой, например, код (взят из примера использования Named pipes):

    LPTSTR lpszPipename = TEXT("\\\\.\\pipe\\mynamedpipe");

    на Delphi будет выглядеть так:

    var

     lpszPipeName: PChar;

    ...

    lpszPipeName:= '\\.\pipe\mynamedpipe';

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

    HWND
    , первый параметр сообщения — тип
    WPARAM
    (в старых 16-разрядных Windows он был эквивалентен типу
    Word
    , в 32-разрядных —
    LongInt
    ). Эти специальные типы также описаны в модуле Windows.

    Записи (

    record
    ) в C/C++ называются структурами и объявляются с помощью слова
    struct
    . Из-за особенностей описания структур на языке С структуры в Windows API получают два имени: одно основное имя, составленное из главных букв, которое затем и используется, и одно вспомогательное, получающееся из основного добавлением префикса
    tag
    . Начиная с четвертой версии Delphi приняты следующие правила именования таких типов: простое и вспомогательное имена остаются без изменений и еще добавляется новое имя, получающееся из основного присоединением общеупотребительного в Delphi префикса
    T
    . Например, в функции
    CreatePenIndirect
    одни из параметром имеет тип
    LOGPEN
    . Это основное имя данного типа, а вспомогательное —
    tagLOGPEN
    . Соответственно, в модуле Windows определена запись
    tagLOGPEN
    и ее синонимы —
    LOGPEN
    и
    TLogPen
    . Эти три идентификатора в Delphi взаимозаменяемы. Вспомогательное имя встречается редко, программисты, в зависимости от личных предпочтений, выбирают либо основное имя типа, либо имя с префиксом
    T
    .

    Описанные здесь правила именования типов могут внести некоторую путаницу при использовании VCL. Например, для описания растра в Windows API определен тип

    BITMAP
    (он же—
    tagBITMAP
    ). В Delphi соответствующий тип имеет еще одно имя —
    TBitmap
    . Но такое же имя имеет класс
    TBitmap
    , описанный в модуле
    Graphics
    . В коде, который Delphi создает автоматически, модуль
    Graphics
    находится в списке
    uses
    после модуля
    Windows
    , поэтому идентификатор
    TBitmap
    воспринимается компилятором как
    Graphics.TBitmap
    , а не как
    Windows.TBitmap
    . Чтобы использовать
    Windows.ТBitmap
    , нужно явно указать имя модуля или воспользоваться одним из альтернативных имен. В более ранних версиях
    Delphi
    были другие правила именования типов. Например. в Delphi 2 существовал тип
    BITMAP
    , но не было
    TBitmap
    и
    tagBITMAP
    , а в Delphi 3 из этих трех типов был только
    TBitmap
    .

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

    packed
    , запрещающее выравнивание.

    При описании структур Windows API можно иногда встретить ключевое слово

    union
    (см., например, структуру
    in_addr
    ). Объединение нескольких полей с помощью этого слова означает, что все они будут размещены по одному адресу. В Delphi это соответствует вариантным записям (т. е. использованию сазе в record). Объединения в C/C++ гибче, чем вариантные записи Delphi, т.к. позволяют размещать вариантную часть в любом месте структуры, а не только в конце. При переносе таких структур в Delphi иногда приходится вводить дополнительные типы.

    Теперь рассмотрим синтаксис описания самой функции в C++ (листинг 1.1).

    Листинг 1.1. Синтаксис описания функции на C++

    <Тип функции> <Имя функции> ' ('

     [<Тип параметра> {<Имя параметра>}

      (',' <Тип параметра> {<Имя параметра>} }

     ]

    ')';

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

    VOID
    , о которых написано далее).

    Необходимо помнить, что в C/C++ различаются верхний и нижний регистры, поэтому

    HDC
    ,
    hdc
    ,
    hDC
    и т.д. — это разные идентификаторы (автор С очень любил краткость и хотел, чтобы можно было делать не 26, а 52 переменные с именем из одной буквы). Поэтому часто можно встретить, что имя параметра и его тип совпадают с точностью до регистра. К счастью, при описании функции в Delphi мы не обязаны сохранять имена параметров, значение имеют лишь их типы и порядок следования. С учетом всего этого функция, описанная в справке как

    HMETAFILE CopyMetaFile(HMETAFILE hmfSrc, LPCTSTR lpszFile);

    в Delphi имеет вид

    function СоруМеtaFile(hnfSrc: HMETAFILE; lpszFile: LPCTSTR): HMETAFILE;

    или, что то же самое.

    function CopyMetaFile(hnfSrc: HMETAFILE; lpszFile: PChar): HMETAFILE;

    Примечание

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

    Несколько особняком стоит тип

    VOID
    (или
    void
    , что то же самое, но в Windows API этот идентификатор встречается существенно реже). Если функции имеет такой тип, то в Паскале она описывается как процедура. Если вместо параметров у функции в скобках указан
    void
    , это означает, что функция не имеет параметров. Например, функция

    VOID CloseLogFile(VOID);

    в Delphi описывается как

    procedure CloseLogFile;

    Примечание

    Язык C++, в отличие от С, допускает объявление функций без параметров, т.е. функцию

    CloseLogFile
    можно было бы объявить так:
    VOID CloseLogFile();
    В C++ эти варианты объявления эквивалентны, но в Windows API варианту явного параметра встречается существенно реже из-за несовместимости с C.

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

    int GetRgnBox(HRGN hrgn, LPRECT lprc);

    в модуле Windows описана как

    function GetRgnBox(RGN: HRGN; var p2: TRec): Integer;

    Такая замена целесообразна в том случае, если значение параметра не может быть нулевым указателем, потому что при использовании var передать такой указатель будет невозможно. Нулевой указатель в C/C++ обозначается константой

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

    И наконец, если не удается понять, как функция, описанная в справке, должна быть переведена на Паскаль, можно попытаться найти описание этой функции в исходных текстах модулей, поставляемых вместе с Delphi. Эти модули находятся в каталоге $(DELPHI)\Source\RTL\Win (до Delphi 7) или $(BDS)\Source\Win32\RTL\Win (BDS 2006 и выше). Можно также воспользоваться подсказкой, которая всплывает в редакторе Delphi после того, как будет набрано имя функции.

    Если посмотреть справку, например, по функции

    GetSystemMetrics
    , то видно, что эта функция должна иметь один целочисленный параметр. Однако далее в справке предлагается при вызове этой функции подставлять в качестве параметра не числа, a
    SM_ARRANGE
    ,
    SM_CLEANBOOT
    и т.д. Подобная ситуация и со многими другими функциями Windows API. Все эти
    SM_ARRANGE
    ,
    SM_CLEANBOOT
    и т.д. являются именами числовых констант. Эти константы описаны в том же модуле, в котором описана функция, использующая их, поэтому можно не выяснять численные значения этих констант, а указывать при вызове функций их имена, например,
    GetSystemMetrics(SM_ARRANGE);
    . Если по каким-то причинам все-таки потребовалось выяснить численные значения, то в справочной системе их искать не стоит — их там нет. Их можно узнать из исходных текстов модулей Delphi, в которых эти константы описаны. Так, например, просматривая Windows.pas, можно узнать, что
    SM_ARRANGE = 56
    .

    В справке, поставляемой вместе с Delphi до 7-й версии включительно, в описании многих функций Windows API вверху можно увидеть три ссылки: QuickInfo, Overview и Group. Первая дает краткую информацию о функции: какой библиотекой реализуется, в каких версиях Windows работает и т.п. (напоминаю, что к информации о версиях в этой справке нужно относиться очень критично). Overview — это обзор какой-то большой темы. Например, для любой функции, работающей с растровыми изображениями, обзор будет объяснять, зачем в принципе нужны эти самые растровые изображения и как они устроены. Страница, на которую ведет ссылка Overview обычно содержит весьма лаконичные сведения, но, нажав кнопку >>, расположенную в верхней части окна, можно получить продолжение обзора. И, наконец, Group. Эта ссылка приводит к списку всех функций, родственных данной. Например, для функции

    CreateRectRgn
    группу будут составлять все функции, имеющие отношение к регионам. Если теперь нажимать на кнопку <<, то будут появляться страницы с кратким описанием возможных применений объектов, с которыми работают функции (в приведенном примере — описание возможностей регионов). Чтобы читать их в нормальной последовательности, лучше всего нажать на кнопку << столько раз, сколько возможно, а затем пойти в противоположном направлении с помощью кнопки >>.

    MSDN (а также справка BDS 2006 и выше) предоставляет еще больше полезной информации. В нижней части описания каждой функции есть раздел Requirements, в котором написано, какая библиотека и какая версия Windows требуется для ее использования. В самом низу описания функции расположены ссылки See also. Первая ссылка — обзор соответствующей темы (например, для уже упоминавшейся функции 

    CreateRectRgn
    — она называется Regions Overview). Вторая список родственных функций (Region Functions в данном случае). Она ведет на страницу, где перечислены все функции, родственные выбранной. После этих двух обязательных ссылок идут ссылки на описание функций и типов, которые обычно используются совместно с данной функцией.

    Основные типы, константы и функции Windows API объявлены в модулях

    Windows
    и
    Messages
    . Но многие функции объявлены в других модулях, которые не подключаются к программе по умолчанию, программист должен сам выяснить, в каком модуле находится требуемый ему идентификатор, и подключить этот модуль. Ни справка, поставляемая с Delphi, ни MSDN, разумеется, не могут дать необходимую информацию. Чтобы выяснить, в каком модуле объявлен нужный идентификатор, можно воспользоваться поиском по всем файлам с расширением pas, находящимся в папке с исходными кодами стандартных модулей. Этим методом можно, например, выяснить, что весьма популярная функция
    ShellExecute
    находится в модуле
    ShellAPI
    ,
    CoCreateInstance
    — в модуле
    ActiveX
    (а также в модуле
    Ole2
    , оставленном для совместимости со старыми версиями Delphi).

    Еще несколько слов о числовых константах. В справке можно встретить числа вида, например,

    0xC56F
    или
    0x3341
    . Префикс
    в C/C++ означает шестнадцатеричное число. В Delphi его следует заменить на
    $
    , т.е. эти числа должны быть записаны как
    $C56F
    и
    $3341
    соответственно.

    1.1.3. Дескрипторы вместо классов

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

    TButton
    , контекст устройства — классом
    TCanvas
    . Но когда создавались первые версии Windows, объектно-ориентированный метод программирования еще не был общепризнанным, поэтому он не был реализован. Современные версии Windows частично унаследовали этот недостаток, поэтому в большинстве случаев приходится работать "по старинке", тем более что DLL могут экспортировать только функции, но не классы. Когда мы будем говорить об объектах, создаваемых через Windows API, будем подразумевать не объекты в терминах ООП, а некоторую сущность, внутренняя структура которой скрыта от нас, поэтому с этой сущностью мы можем оперировать только как с единым и неделимым (атомарным) объектом.

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

    Таким образом, главное различие между методами класса и функциями Windows API заключается в том. что первые связаны с тем экземпляром класса, через который они вызываются, и поэтому не требуют явного указания на объект. Вторым необходимо указание объекта через его дескриптор, т.к. они сами по себе никак не связаны ни с одним объектом. Компоненты VCL нередко являются оболочками над объектами Delphi. В этом случае они имеют свойство (которое обычно называется

    Handle
    ), содержащее дескриптор соответствующего объекта. Иногда класс Delphi инкапсулирует несколько объектов Windows. Например, класс
    TBitmap
    включает в себя
    HBITMAP
    и
    HPALETTE
    — картинку и палитру к ней. Соответственно, он хранит два дескриптора: в свойствах
    Handle
    и
    Palettе
    .

    Следует учитывать, что внутренние механизмы VCL не могут включиться, если изменение объекта происходит через Windows API. Например, если спрятать окно не с помощью метода

    Hide
    , а путем вызова функции Windows API
    ShowWindow(Handle, SW_HIDE)
    , не возникнет событие
    OnHide
    , потому что оно запускается теми самыми внутренними механизмами VCL. Но такие недоразумения случаются обычно только тогда, когда функциями Windows API дублируется то, что можно сделать и с помощью VCL.

    Все экземпляры классов, созданные в Delphi, должны удаляться. В некоторых случаях это происходит автоматически, а иногда программист должен сам позаботиться о "выносе мусора". Аналогичная ситуация и с объектами, создаваемыми в Windows API. Если посмотреть справку по функции, создающей какой-то объект, то там обязательно будет информация о том. какой функцией можно удалить объект и нужно ли это делать вручную, или система сделает это автоматически. Во многих случаях совершенно разные объекты могут удаляться одной и той же функцией. Так, функция

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

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

    1.1.4. Формы VCL и окна Windows

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

    TForm
    . Однако это понятие существенно шире. В общем случае окном называется любой объект, который имеет экранные координаты и может реагировать на мышь и клавиатуру. Например, кнопка, которую можно создать с помощью класса
    TButton
    , — это тоже окно. VCL вносит некоторую путаницу в это понятие. Некоторые визуальные компоненты VCL не являются окнами, а только имитируют их, как, например,
    TImage
    . Это позволяет экономить ресурсы системы и повысить быстродействие программы. Механизм этой имитации мы рассмотрим позже, а пока следует запомнить, что окнами являются только те визуальные компоненты которые имеют в числе предков класс
    TWinControl
    . Разработчики VCL постарались, чтобы разница между оконными и неоконными визуальными компонентами была минимальной. Действительно, на первый взгляд неоконный
    TLabel
    и оконный
    TStaticText
    кажутся практически близнецами. Разница становится заметной тогда, когда используется Windows API. С неоконными компонентами можно работать только средствами VCL, они даже не имеют свойства
    Handle
    , в то время как оконными компонентами можно управлять с помощью Windows API.

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

    TLabel
    , размещенный на форме, не может закрывать собой часть кнопки
    TButton
    , потому что
    TLabel
    рисуется на поверхности формы, а кнопка — это независимый объект, лежащий на форме и имеющий свою поверхность. A
    TStaticText
    может оказаться над кнопкой, потому что он тоже находится над формой.

    Примечание

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

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

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

    RegisterClassEx
    ). В качестве параметра эта функция принимает запись типа
    TWndClassEx
    , поля которой содержат параметры класса. 

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

    Примечание

    Здесь следует отметить некоторую путаницу в терминах. В англоязычной справке есть слово module, служащее для обозначения файла, отображенного в адресное пространство процесса, т.е., в первую очередь, exe-файла, породившего процесс, и загруженных им DLL. И есть слово unit, которое обозначает модуль в Delphi и которое также переводится как модуль. Ранее мы говорили о модулях как об отображаемых в адресное пространство файлах — это они имеют дескрипторы. Модули Delphi не являются системными объектами и дескрипторов не имеют.

    Дескриптор модуля, загруженного в память, можно получить с помощью функции

    GetModuleHandle
    . Функция
    LoadLibrary
    в случае успешного завершения также возвращает дескриптор загруженной DLL. Кроме того, Delphi предоставляет две переменные:
    MainInstance
    из модуля
    System
    и
    HInstance
    из модуля
    SysInit
    (оба этих модуля подключаются к программе автоматически, без явного указания в списке
    uses
    ).
    MainInstance
    содержит дескриптор exe-файла, породившего процесс,
    HInstance
    — текущего модуля. В исполняемом файле
    MainInstance
    и
    HInstance
    равны между собой, в DLL
    HInstance
    содержит дескриптор самой библиотеки, а
    MainIstance
    — загрузившего ее главного модуля.

    Каждое окно в Windows привязывается к какому-либо модулю (в Windows 9х/МЕ необходимо явно указать дескриптор этого модуля. NT 2000 ХР определяет модуль, из которого вызвана функция создания окна, автоматически). Соответственно, оконные классы делятся на локальные и глобальные: окна локальных классов может создавать только тот модуль, в котором находится оконная процедура класса, глобальных — любой модуль данного приложения. Будет ли класс локальным или глобальным, зависит от значений полей

    TWndClassEx
    при регистрации класса.

    Оконный класс, к которому принадлежит окно, указывается при его

    создании
    . Это может быть зарегистрированный ранее класс или один из системных классов. Системные классы — это
    'BUTTON'
    ,
    'COMBOBOX'
    ,
    'EDIT'
    ,
    'LISTBOX'
    ,
    'MDICLIENT'
    ,
    'SCROLLBAR'
    и
    'STATIC'
    . Назначение этих классов понятно из их названий (класс
    'STATIC'
    реализует статические текстовые или графические элементы, т.е. не реагирующие на мышь и клавиатуру, но имеющие дескриптор). Кроме этих классов существуют также классы из библиотеки ComCtl32.dll, они тоже доступны всем приложениям без предварительной регистрации (подробнее об этих классах можно узнать в MSDN в разделе Common Controls Reference).

    Для окон в обычном понимании этого слова готовых классов не существует, их приходится регистрировать самостоятельно. В частности, VCL для форм регистрирует оконные классы, имена которых совпадают с именами соответствующих классов VCL.

    Кроме имени, класс включает в себя другие параметры, такие как стиль, кисть и т.д. Они подробно перечислены в справке.

    Для создания окна служат функции

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

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

    MDIChild
    , то родительским для него будет
    MDIForm
    (если быть до конца точным, то не сама форма
    MDIForm
    , а специальное окно класса
    MDICLIENT
    , которое является дочерним по отношению к
    MDIForm
    ; дескриптор этого окна хранится в свойстве
    ClientHandle
    главной формы). Другими словами, отношения "родительское — дочернее окно" отражают принадлежность одного окна другому, визуальную связь между ними. Окна, родитель которых не задан (т.е. в качестве дескриптора родителя передан ноль), располагаются непосредственно на рабочем столе. Если при создании окна задан стиль
    WS_CHILD
    , то его координаты отсчитываются от левого верхнего угла клиентской области родительского окна, и при перемещении родительского окна все дочерние окна будут перемещаться вместе с ним. Окно, имеющее стиль
    WS_CHILD
    , не может располагаться ни рабочем столе, попытка создать такое окно окончится неудачей. Визуальные компоненты VCL имеют два свойства, которые иногда путают: Owner и Parent. Свойство Parent указывает на объект, реализующий окно, являющееся родительским для данного визуального компонента (компоненты, не являющиеся наследником TWinControl, также имеют это свойство — VCL для них имитирует эту взаимосвязь, однако сами они не могут быть родителями других визуальных компонентов). Свойство Owner указывает на владельца компонента. Отношения "владелец-принадлежащий" реализуются полностью внутри VCL. Свойство
    Owner
    есть у любого наследника 
    TComponent
    , в том числе и у невизуальных компонентов, и владельцем других компонентов также может быть невизуальный компонент (например,
    TDataModule
    ). При уничтожении компонента он автоматически уничтожает все компоненты, владельцем которых он является (здесь, впрочем, есть некоторое дублирование функций, т.к. оконный компонент также при уничтожении уничтожает все визуальные компоненты, родителем которых он является). Еще владелец отвечает за загрузку всех установленных во время разработки свойств принадлежащих ему компонентов.

    Свойство

    Owner
    доступно только для чтения. Владелец компонента задается один раз при вызове конструктора и остается неизменным на протяжении всего жизненного цикла компонента (за исключением достаточно редких случаев явного вызова методов
    InsertComponent
    и
    RemoveComponent
    ). Свойство
    Parent
    задается отдельно и может быть впоследствии изменено (визуально это будет выглядеть как "перепрыгивание" компонента из одного окна в другое).

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

    Parent
    не задано. Например, невозможно отобразить на экране компонент
    TButton
    , у которого не установлено свойство
    Parent
    . Это связано с тем, что большинство оконных компонентов имеет стиль
    WS_CHILD
    , который, напомним. не позволяет разместить окно на рабочем столе. Окнами без родителя могут быть только наследники
    TCustomForm
    .

    Впрочем, сделать кнопку, не имеющую родителя, можно средствами Windows API. Например, такой командой (листинг 1.2).

    Листинг 1.2. Создание кнопки, не имеющей родительского окна

    CreateWindow('BUTTON', 'Test', WS_VISIBLE or BS_PUSHBUTTON or WS_POPUP, 10, 10, 100, 50, 0, 0, HInstance, nil);

    Рекомендуем в этом примере убрать стиль

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

    Кроме обычного конструктора

    Create
    , у класса
    TWinControl
    есть конструктор
    CreateParented
    , позволяющий создавать оконные компоненты, родителями которых являются окна, созданные без использования VCL. В качестве параметра этому конструктору передается дескриптор родительского окна. У компонентов, созданных таким образом, не нужно устанавливать свойство
    Parent
    .

    Примечание

    Путаницу между понятием родителя и владельца усиливает то, что в MSDN по отношению к окнам тоже используются термины owner и owned (принадлежащий), однако это не имеет никакого отношения к владельцу в понимании VCL. Если окно имеет стиль

    WS_CHILD
    , то оно обязано иметь родителя, но не может иметь владельца. Если такого стиля у окна нет, оно не может иметь родителя, но может (хотя и не обязано) иметь владельца. Владельцем в этом случае становится то окно, чей дескриптор передан в качестве родительского, т.е. родитель и владелец в терминах системы — это один и тот же параметр, который по-разному интерпретируется в зависимости от стиля самого окна. Окно, имеющее владельца, уничтожается при уничтожении владельца, прячется при его минимизации и всегда находится над владельцем. Окно, имеющее стиль
    WS_CHILD
    , может быть родителем, но не может быть владельцем другого окна; если передать дескриптор такого окна в качестве владельца, то реальным владельцем станет родитель дочернего окна. Чтобы не путать владельца в терминах VCL и в терминах системы, мы в дальнейшем всегда будем оговаривать, в каком смысле будет упомянуто слово "владелец".

    Создание окон через Windows API требует кропотливой работы. VCL справляется с этой задачей замечательно, поэтому создавать окна самостоятельно приходится только тогда, когда использование VCL нежелательно, например, если необходимо написать как можно более компактное приложение. Во всех остальных случаях приходится только слегка подправлять работу VCL. Например, с помощью Windows API можно изменить форму окна или убрать из нею заголовок, оставив рамку. Подобные действия не требуют от программиста создания нового окна, можно воспользоваться тем, что уже создано VCL.

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

    1.1.5. Функции обратного вызова

    Прежде чем двигаться дальше, необходимо разобраться с тем, что такое функции обратного вызова (callback functions: этот термин иногда также переводят "функции косвенного вызова"). Эти функции в программе описываются, но обычно не вызываются напрямую, хотя ничто не запрещает сделать это. В этом они похожи на те методы класса, которые связаны с событиями.

    Ничто не мешает вызывать напрямую, например, метод

    FormCreate
    , но делать это приходится крайне редко. С другой стороны, даже если этот метод не вызывается явно, он все равно выполняется, потому что VCL автоматически вызывает его без прямого указания программиста. Еще одно общее свойство — конкретное имя метода при косвенном вызове не важно. Можно изменить его, но если этот метод по-прежнему будет связан с событием
    OnCreate
    , он так же будет успешно вызываться. Разница заключается только в том, что такие методы вызываются внутренними механизмами VCL, а функции обратного вызова — самой системой Windows. Соответственно, на эти функции налагаются следующие требования: во-первых, они должны быть именно функциями, а не методами класса; во-вторых, они должны быть написаны в соответствии с моделью вызова
    stdcall
    (MSDN предлагает использовать модель
    callback
    , которая в имеющихся версиях Windows является синонимом
    stdcall
    ). Что же касается того, как программист сообщает системе о том, что он написал функцию обратного вызова, то это в каждом случае будет по-своему.

    В качестве примера рассмотрим перечисление окон с помощью функции

    EnumWindows
    . В справке она описана так:

    BOOL EnumWindows(WNDENUMPROC lpEnumFunc, LPARAM lParam);

    Соответственно, в Windows.pas она имеет вид

    function EnumWindows(lpEnumFunc: TFNWndEnumProc; lParam: LPARAM): BOOL; stdcall;

    Параметр

    lpEnumFunc
    должен содержать указатель на функцию обратного вызова. Прототип этой функции описан так:

    BOOL CALLBACK EnumWindowsProc(HWND hwnd, LPARAM lParam);

    Функции с таким именем в Windows API не существует. Это так называемый прототип функции, согласно которому следует описывать функцию обратного вызова. На самом деле этот прототип предоставляет большую свободу, чем это может показаться на первый взгляд. Во-первых, имя может быть любым. Во-вторых, система не накладывает строгих ограничений на имена и типы параметров — они могут быть любыми, при условии, что новые типы совпадают по размерам с теми, которые указываются (тип

    TFNWndEnumProc
    , описанный в модуле
    Windows 
    — это не процедурный тип, а просто нетипизированный указатель, поэтому компилятор Delphi не будет контролировать соответствие передаваемой функции обратного вызова ее прототипу). Что касается типа функции и типа первого параметра, то они имеют определенный смысл, и изменение их типа вряд ли может быть полезным. Но второй параметр предназначен специально для передачи значения, которое программист волен использовать но своему усмотрению, система просто передает через него в функцию обратного вызова то значение, которое имел параметр
    lParam
    при вызове функции
    EnumWindows
    . А программисту может показаться удобнее работать не с типом
    lParam
    (т.е.
    LongInt
    ), а, например, с указателем или же с массивом из четырех байтов. Лишь бы были именно четыре байта, а не восемь, шестнадцать или еще какое-то число. Можно даже превратить этот параметр в параметр-переменную, т.к. при этом функции будут передаваться все те же четыре байта — адрес переменной. Впрочем, тем, кто не очень хорошо разбирается с тем, как используется стек для передачи параметров при различных моделях вызова, лучше не экспериментировать с изменением типа параметра, а строго следовать заявленному прототипу, при необходимости выполняя требуемые преобразования внутри функции обратного вызова.

    Функция

    EnumWindows
    работает так: после вызова она начинает по очереди перебирать все имеющиеся в данный момент окна верхнего уровня, т.е. те, у которых нет родителя. Для каждого такого окна вызывается заданная функция обратного вызова, в качестве первого параметра ей передается дескриптор данного окна (каждый раз, естественно, новый), в качестве второго — то, что было передано самой функции
    EnumWindows
    в качестве второго параметра (каждый раз одно и то же). Получая по очереди дескрипторы всех окон верхнего уровня, функция обратного вызова может выполнить с каждым из них определенное действие (закрыть, минимизировать и т.п.). Или можно проверять все эти окна на соответствие какому-то условию, пытаясь найти нужное. А значение, возвращаемое функцией обратного вызова, влияет на работу
    EnumWindows
    . Если она возвращает
    False
    , значит, все, что нужно, уже сделано, можно не перебирать остальные окна.

    Окончательный код для того случая, когда второй параметр имеет тип

    Pointer
    , иллюстрирует листинг 1.3.

    Листинг 1.3. Вызов функции
    EnumWindows
    с функцией обратного вызова

    function MyCallbackFunction(Wnd: HWND; Р: Pointer): BOOL; stdcall;

    begin

     { что-то делаем}

    end;

    ...............

    var

     MyPointer: Pointer;

     ...............

    EnumWindows(@MyCallbackFunction, LongInt(MyPointer));

    Что бы мы ни делали с типом второго параметра функции обратного вызова, тип соответствующего параметра

    EnumWindows
    не меняется. Поэтому необходимо явное приведение передаваемого параметра к типу
    LongInt
    . Обратное преобразование типов при вызове
    MyCallbackFunction
    , осуществляется автоматически.

    Использование

    EnumWindows
    и функций обратного вызова демонстрируется примером
    EnumWnd
    .

    Отметим, что функции обратного вызова будут вызываться до того, как завершит работу функция

    EnumWindows
    . Однако это не является распараллеливанием работы. Чтобы проиллюстрировать это, рассмотрим ситуацию, когда программа вызывает некоторую функцию А, которая, в свою очередь, вызывает функцию В. Функция В, очевидно, начнет свою работу до того, как завершит работу функция А. То же самое произойдет и с функцией обратного вызова, переданной в
    EnumWindows
    : она будет вызываться из кода
    EnumWindows
    так же, как и функция В из кода функции А. Поэтому код функции обратного вызова получит управление (и не один раз, т.к.
    EnumWindows
    будет вызывать эту функцию в цикле) до завершения работы
    EnumWindows
    .

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

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

    MakeProcInstance
    , удалялся после завершения с помощью
    FreeProcInstance
    . Таким образом, вызов
    EnumWindows
    должен был бы выглядеть так. как показано в листинге 1.4.

    Листинг 1.4. Вызов функции
    EnumWindows
    в 16-разрядных версиях Windows

    var

     MyProcInstanсe: TFarProc;

    ...............

    MyProcInstance := MakeProcInstance(@MyCallBackFunction, HInstance);

    EnumWindows(MyProcInstance, LongInt(MyPointer));

    FreeProcInstance(MyProcInstance);

    В Delphi этот код будет работоспособным, т.к. для совместимости

    MakeProcInstance
    и
    FreeProcInstance
    оставлены. Но они ничего не делают (в чем легко убедиться, просмотрев исходный файл Windows.pas), поэтому можно обойтись и без них. Тем не менее эти функции иногда до сих пор используются, видимо, просто в силу привычки. Другой способ, с помощью которого и 16-разрядных версиях можно сделать пролог — описать функцию с директивой
    export
    . Эта директива сохранена для совместимости и в Delphi, но в 32-разрядных версиях она также ничего не делает (несмотря на то, что справка, например, по Delphi 3 утверждает обратное; в справке по Delphi 4 этой ошибки уже нет).

    1.1.6. Сообщения Windows

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

    OnCreate
    ,
    OnClick
    ,
    OnCloseQuery
    ). Причем событием называется не только событие в обычном смысле этого слова, т.е. когда происходит что-то внешнее, но и ситуация, когда событие используется просто для передачи управления коду, написанному разработчиком программы, в тех случаях, когда VCL не может сама справиться с какой-то задачей. Пример такого события —
    TListBox.OnDrawItem
    . Устанавливая стиль списка в
    lbOwnerDrawFixed
    или
    lbOwnerDrawVariable
    , программист указывает, что ему требуется нестандартный вид элементов списка, поэтому их рисование он берет на себя. И каждый раз, когда возникает необходимость в рисовании элемента, VCL передает управление специально написанному коду. На самом деле разница между двумя типами событий весьма условна. Можно сказать, что когда пользователь нажимает клавишу, VCL не "знает", что делать, и поэтому передает управление обработчику
    OnKeyPress
    .

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

    В Delphi для реакции на каждое событие обычно создается свой метод. В Windows одна процедура, называемая оконной, обрабатывает все сообщения, адресованные конкретному окну. (В C/C++ нет понятия "процедура", там термин "оконная процедура" не вызывает путаницы, а вот в Delphi четко определено, что такое процедура. И здесь можно запутаться: то, что в системе называется оконной процедурой, с точки зрения Delphi будет не процедурой, а функцией. Тем не менее мы будем употреблять общепринятый термин "оконная процедура".) Каждое сообщение имеет свой уникальный номер, а оконная процедура обычно целиком состоит из оператора case, и каждому сообщению соответствует своя альтернатива этого оператора. Номера сообщений знать не обязательно, потому что можно использовать константы, описанные в модуле

    Messages
    . Эти константы начинаются с префикса, указывающего на принадлежность сообщения к какой-то группе. Например, сообщения общего назначения начинаются с
    WM_
    :
    WM_PAINT
    ,
    WM_GETTEXTLENTH
    . Сообщения, специфичные, например, для кнопок, начинаются с префикса
    BM_
    . Остальные группы сообщений также связаны либо с теми или иными элементами управления, либо со специальными действиями, например, с динамическим обменом данными (Dynamic Data Exchange, DDE). Обычной программе приходится обрабатывать довольно много сообщений, поэтому оконная процедура бывает, как правило, очень длинной и громоздкой. Оконная процедура описывается программистом как функция обратного вызова и указывается при создании оконного класса. Таким образом, все окна данного класса имеют одну и ту же оконную процедуру. Впрочем, существует возможность породить так называемый подкласс, т.е. новый класс, наследующий все свойства существующего, за исключением оконной процедуры. Несколько подробнее об этом будет сказано далее.

    Кроме номера, каждое сообщение содержит два параметра: wParam и lParam. Префиксы w и l означают "Word" и "Long", т.е. первый параметр 16-разрядный, а второй — 32-разрядный. Однако так было только в старых, 16-разрядных версиях Windows. В 32-разрядных версиях оба параметра 32-разрядные, несмотря на их названия. Конкретный смысл каждого параметра зависит от сообщения. В некоторых сообщениях один или оба параметра могут вообще не использоваться, в других — наоборот, двух параметров даже не хватает. В этом случае один из параметров (обычно

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

    LRESULT CALLBACK WindowProc(

     HWND hwnd, // дескриптор окна

     UINT uMsg, // номер сообщения

     WPARAM wParam, // первый параметр соообщения

     LPARAM lParam // второй параметр сообщения

    );
     

    В Delphi оконная процедура объявляется следующим образом:

    function WindowProc(hWnd: HWND; Msg: UINT; wParam: WPARAM; lParam: LPARAM): LRESULT; stdcall;

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

    DefWindowProc
    . Разработчик приложения в своей оконной процедуре должен предусмотреть только специфическую для данного окна обработку сообщений, а обработку всех остальных сообщений передать этой функции. Существуют также аналоги функции
    DefWindowProc
    для специализированных окон:
    DefDlgProc
    для диалоговых окон,
    DefFrameProc
    для родительских MDI окон,
    DefChildMDIProc
    для дочерних MDI-окон.

    Сообщение окну можно либо послать (post), либо отправить (send). Каждая нить, вызвавшая хоть одну функцию из библиотеки user32.dll или gdi32.dll, имеет свою очередь сообщений, в которую помещаются все сообщения, посланные окнам, созданным данной нитью (послать сообщение окну можно например, с помощью функции

    PostMessage
    ). Соответственно, кто-то должен извлекать эти сообщения из очереди и передавать их окнам-адресатам. Это делается с помощью специального цикла, который называется петлей сообщений (message loop). В этом непрерывном цикле, который должен реализовать разработчик приложения, сообщения извлекаются из очереди с помощью функции
    GetMessage
    (реже —
    PeekMessage
    ) и передаются в функцию
    DispatchMessage
    . Эта функция определяет, какому окну предназначено сообщение, и вызывает его оконную процедуру. Таким образом, простейший цикл обработки сообщений выглядит так, как показано в листинге 1.5.

    Листинг 1.5. Простейшая петля сообщений

    var

     Msg: TMsg;

     ...

    while GetMessage(Msg, 0, 0, 0) do

    begin

     TranslateMessage(Msg);

     DispatchMessage(Msg);

    end;

    Блок-схема петли сообщений показана на рис. 1.4.

    Рис 1.4. Блок-схема петли сообщений


    Функция

    GetMessage
    возвращает
    True
    до тех пор, пока не будет получено сообщение
    WM_QUIT
    , указывающее на необходимость завершения программы. Обычная программа для Windows, выполнив предварительные действия (регистрация класса и создание окна), входит в петлю сообщений, которую выполняет до конца своей работы. Все остальные действия выполняются в оконной процедуре при реакции на соответствующие сообщения.

    Примечание

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

    TTimer
    и
    TClientSocket
    . Эти компоненты создают невидимые окна для получения сообщений, которые необходимы им для работы. Если нить, создавшая эти объекты, не будет иметь петли сообщений, они будут неработоспособными

    Сообщение, извлеченное из очереди,

    GetMessage
    помещает в первый параметр-переменную типа
    TMsg
    . Последние три параметра служат для фильтрации сообщений, позволяя извлекать из очереди только те сообщения, которые соответствуют определенным критериям. Если эти параметры равны нулю, как это обычно бывает, фильтрация при извлечении сообщений не производится.

    Функция

    TranslateMessage
    , которая обычно вызывается в петле сообщений, служит для трансляции клавиатурных сообщении (если петля сообщений реализуется только для обработки сообщении невидимым окнам, которые использует, например, COM/DCOM, или по каким-то другим причинам ввод с клавиатуры не обрабатывается или обрабатывается нестандартным образом, вызов
    TranslateMessage
    можно опустить). Когда пользователь нажимает какую-либо клавишу на клавиатуре, система посылает окну, находящему в фокусе, сообщение
    WM_KEYDOWN
    . Через параметры этого сообщения передаётся виртуальный код нажатой клавиши — двухбайтное число, которое определяется только положением нажатой клавиши на клавиатуре и не зависит от текущей раскладки, состояния клавиш <CapsLock> и т.п. Функция
    TranslateMessage
    . обнаружив такое сообщение, добавляет в очередь (причем не в конец, а в начало) сообщение
    WM_CHAR
    , в параметрах которого передается код символа, соответствующего нажатой клавише, с учетом раскладки, состояния клавиш <CapsLock>, <Shift> и т. п. Именно функция
    TranslateMessage
    по виртуальному коду клавиши определяет код символа. При этом нажатие любой клавиши приводит к генерации
    WM_KEYDOWN
    , а вот
    WM_CHAR
    генерируется не для всех клавиш, а только для тех, которые соответствуют какому-то символу (например, не генерирует
    WM_CHAR
    нажатие таких клавиш, как <Shift> <Ctrl>, <Insert>, функциональных клавиш).

    Примечание

    У многих компонентов VCL есть события

    OnKeyDown
    и
    OnKeyPress
    . Первое возникает при получении компонентом сообщения
    WM_KEYDOWN
    , второе — сообщения
    WM_CHAR
    .

    Если очередь сообщений пуста, функция

    GetMessage
    ожидает, пока там не появится хотя бы одно сообщение, и только после этого завершает работу. Во время этого ожидания нить не загружает процессор.

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

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

    PeekMessage
    , которая позволяет проверить, есть ли в очереди сообщения. Если сообщения обнаружены, нужно вызвать
    DispatchMessage
    для передачи их требуемому окну. В этом случае сообщения будут извлекаться из очереди и обрабатываться до завершения работы обработчика. Блок-схема программы, содержащей локальную петлю сообщений, показана на рис. 1.5 (для краткости в главной петле сообщений показаны только две самых важных функции:
    GetMessage
    и
    DispatchMessage
    , хотя и в этом случае главная петля целиком выглядит так же, как на рис. 1.4).

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

    Enabled := False
    ), и вновь разрешить только после окончания обработки, тогда пользователь не сможет нажать кнопку во время работы локальной петли сообщений. В очередь можно поставить сообщение, не привязанное ни к какому окну. Это делается с помощью функции
    PostThreadMessage
    . Такие сообщения необходимо самостоятельно обрабатывать в петле сообщений, потому что функция
    DispatchMessage
    их просто игнорирует.

    Рис. 1.6. Блок-схема программы с локальной петлей сообщений


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

    PostMessage
    , указав в качестве адресата не дескриптор конкретного окна, а константу
    HWND_BROADCAST
    . Такое сообщение получат все окна, расположенные непосредственно на рабочем столе и не имеющие при этом владельцев (в терминах системы). Существует также специальная функция
    BroadcastSystemMessage
    (начиная с Windows ХР — ее расширенный вариант
    BroadcastSystemMessageEx
    ), которая позволяет уточнить, каким конкретно окнам будет отправлено широковещательное сообщение.

    Кроме параметров

    wParam
    и
    lParam
    , каждому
    сообщению
    приписывается время отправки и координаты курсора в момент возникновения. Соответствующие поля есть в структуре TMsg, которую используют функции
    GetMessage
    и DispatchMessage, но у оконной процедуры не предусмотрены параметры для их передачи. Получить время отправки сообщения и координаты курсора при обработке сообщения можно с помощью функций
    GetMessageTime
    и
    GetMessagePos
    соответственно.

    Существует также ряд функций, которые могут обрабатывать сообщения без участия

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

    □ 

    TranslateAccelerator
    — на основе загруженной из ресурсов таблицы распознает нажатие "горячих" клавиш меню и вызывает оконную процедуру, передавая ей сообщение
    WM_COMMAND
    или
    WM_SYSCOMMAND
    , аналогичное тому, которое посылается при выборе соответствующего пункта меню пользователем;

    □ 

    TranslateMDISysAccel
    — аналог предыдущей функции за исключением того, что распознает "горячие" клавиши системного меню MDI-окон;

    □ 

    IsDialogMessage
    — распознает сообщения, имеющие особый смысл для диалоговых окон (например, нажатие клавиши <Tab> для перехода между элементами управления). Используется для немодальных диалоговых окон и окон, не являющихся диалоговыми (т.е. созданными без помощи функций
    CreateDialogXXXX
    ), но требующими аналогичной функциональности.

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

    TranslateAccelerator
    для родительской MDI-формы и
    TranslateMDISysAccel
    для дочерней.

    Листинг 1.6. Петля сообщении с обработкой "горячих" клавиш главного меню и системного меню MDI-окон

    while GetMessage(Msg, 0, 0, 0) do

     if not TranslateMDISysAccel(ActiveMDIChildHandle, Msg)

      and not TranslateAccelerator(MDIFormHandle, AccHandle, Msg) then

     begin

      TranslateMessage(Msg);

      DispatchMessage(Msg);

     end;

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

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

    Примечание

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

    GetMessage
    или
    PeekMessage
    , то эти сообщения не попадают в функции
    TranslateMDISysAccel
    ,
    TranslateAccelerator
    и
    TranslateMessage
    . Это необходимо учитывать при передаче окну сообщений, эмулирующих нажатие клавиш на клавиатуре. Такие сообщения окну нужно посылать, а не отправлять, чтобы они прошли полный цикл обработки и окно правильно на них отреагировало. Для эмуляции сообщений от клавиатуры можно также воспользоваться функцией
    keybd_event
    , но она посылает сообщение не указанному окну, а активному, что не всегда удобно.

    Диалоговые окна обрабатывают сообщения по-особому. Эти окна делятся на модальные (создаются и показываются с помощью функций

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

    Все диалоговые окна имеют так называемую диалоговую процедуру — функцию, указатель на которую передается в качестве одного из параметров функциям

    DialogВохХХХХ
    и
    CreateDialogXXXX
    . Прототипы диалоговой и оконной процедур совпадают. Функция
    DefDlgProc
    начинаем свою работу с того, что вызывает диалоговую процедуру. Если та не обработала переданное ей сообщение (о чем сигнализирует возвращаемое нулевое значение), функция
    DefDlgProc
    обрабатывает его сама. Таким образом, с помощью одного оконного класса и одной оконной процедуры можно реализовывать различные диалоговые окна, используя разные диалоговые процедуры.

    Функции

    DialogВохХХХХ
    создают диалоговое окно и сразу же показывают его в модальном режиме. Данные функции завершают свое выполнение только тогда, когда модальное окно будет закрыто. Внутри модальных функций организуется собственная петля сообщений. Все прочие окна на время показа модального диалога запрещаются (как если бы для них была вызвана функция
    EnableWindow
    с параметром
    FALSE
    ), т.е. перестают реагировать на сообщения от мыши и клавиатуры. При этом они сохраняют способность реагировать на другие сообщения, благодаря чему могут, например, обновлять свое содержимое по таймеру (в справке написано, что ничто не мешает программисту вставить в диалоговую процедуру вызов функций, разрешающих запрещенные системой окна, но при этом теряется смысл модальных диалогов). Если в очереди нет сообщений, модальная петля посылает родительскому окну диалога сообщение
    WM_ENTERIDLE
    , обработка которого позволяет этому окну выполнять фоновые действия. Разумеется, что обработчик
    WM_ENTERIDLE
    не должен выполняться слишком долго, иначе модальное окно зависнет. Обычно окно использует оконную процедуру, которая задана при создании соответствующего оконного класса. Однако допускается создание так называемых подклассов — переопределение оконной процедуры после того, как окно создано. Это переопределение касается только заданного окна и не оказывает влияния на остальные окна, принадлежащие данному оконному классу. Осуществляется оно с помощью функции
    SetWindowLong
    с параметром
    GWL_WNDPROC
    (другие значения этого параметра позволяют менять другие свойства окна, такие как стиль и расширенный сталь). Изменять оконную процедуру можно только у окон, созданных самим процессом.

    Новая оконная процедура, которая устанавливается при создании подкласса, все необработанные сообщения должна передавать не функции

    DefWindowProc
    , а той оконной процедуре, которая была установлена ранее.
    SetWindowLong
    при изменении оконной процедуры возвращает дескриптор старой процедуры (этот же дескриптор можно получить, заранее вызвав функцию
    GetWindowLong
    с аргументом
    GWL_WINDOWPROC
    ). Обычно значение дескриптора численно совпадает с адресом старой оконной процедуры, поэтому в некоторых источниках можно встретить рекомендации использовать этот дескриптор непосредственно как указатель процедурного типа. И это даже будет работать для оконных классов, созданных самой программой. Но безопаснее все же вызов старой оконной процедуры реализовать с помощью системной функции
    CallWindowProc
    , предоставив ей "разбираться", является ли дескриптор указателем.

    В качестве примера рассмотрим создание подкласса для некоторого окна, дескриптор которого содержится в переменной

    Wnd
    . Пусть нам потребовалось для этого окна нестандартным образом обрабатывать сообщение
    WM_KILLFOCUS
    .

    Тогда код новой оконной процедуры и код ее установки будет выглядеть так, как показано в листинге 1.7.

    Листинг 1.7. Создание подкласса для особой обработки сообщения
    WM_KILLPFOCUS

    var

     OldWndProc: TFNWndProc;

    function NewWindowProc(hWnd: HWND; Msg: UINT; wParam: WPARAM; lParam: LPARAM) : LRESULT; stdcall;

    begin

     if Msg = WM_KILLFOCUS then

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

     else

      Result := CallWindowProc(OldWndProc, hWnd, Msg, wParam, lParam);

    end;

    ...

    // Установка новой оконной процедуры окну Wnd

    OldWndProc := TFNWndProc(SetWindowLong(Wnd, GWL_WNDPROC, Longint(@NewWindowProc)));

    ...

    Примечание

    MSDN называет функции

    GetWindowLong
    и
    SetWindowLong
    устаревшими и рекомендует использовать вместо них
    GetWindowLongPtr
    и
    SetWindowLongPtr
    , совместимые с 64-разрядными версиями Windows. Однако до 2007-й версии Delphi включительно эти функции отсутствуют в модуле Windows, и при необходимости их следует импортировать самостоятельно.

    Переопределять оконную процедуру с помощью

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

    1.1.7. Создание окон средствами VCL

    Теперь поговорим о том, как в VCL создаются окна. Речь здесь будет идти не о написании кода для создания окна с помощью VCL (предполагается, что читатель это и так знает), а о том, какие функции API и в какой момент вызывает VCL при создании окна.

    Если смотреть код методов класса

    TWinControl
    , которые вызываются при создании и отображении окна, то найти там то место, когда окно создается, удается не сразу. На первый взгляд все выглядит так, будто этот код вообще не имеет отношения к созданию окна, как будто оно создается где-то совсем в другом месте, а
    TWinControl
    получает уже готовый дескриптор. На самом деле окно создает, конечно же, сам
    TWinControl
    , а спрятано его создание в свойстве
    Handle
    . Метод
    GetHandle
    , который возвращает значение свойства
    Handle
    , выглядит следующим образом (листинг 1.8).

    Листинг 1.8. Реализация метода
    TWinControl.GetHandle

    procedure TWinControl.HandleNeeded;

    begin

     if FHandle = 0 then

     begin

      if Parent <> nil then Parent.HandleNeeded;

      CreateHandle;

     end;

    end;


    function TWinControl.GetHandle: HWnd;

    begin

     HandleNeeded;

     Result := FHandle;

    end;

    При каждом обращении к свойству

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

    Метод

    CreateHandle
    , который вызывается из
    HandleNeeded
    , выполняет непосредственно лишь несколько вспомогательных операций, а для создания окна вызывает еще один метод —
    CreateWnd
    (листинг 1.9).

    Листинг 1.9. Реализация метода
    CreateWnd

    procedure TWndControl.CreateWnd;

    var

     Params: TCreateParams;

     TempClass: TWndClass;

     ClassRegistered: Boolean;

    begin

     CreateParams(Params);

     with Params do

     begin

      if (WndParent = 0) end (Style and WS_CHILD <> 0) then

       if (Owner <> nil) end (csReading in Owner.ComponentState) and (Owner is TWinControl) then

        WndParent TWinControl(Owner).Handle

       else

        raise EInvalidOperation.CreateFmt(SParentRequired, [Name]);

      FDefWndProc := WindowClass.lpfnWndProc;

      ClassRegistered := GetClassInfo(WindowClass.hInstance, WinClassName, TempClass);

      if not ClassRegistered or (TempClass.lpfnWndProc <> @InitWndProc) then

      begin

       if (ClassRegistered then

        Windows.UnregisterClass(WinClassName, WindowClass.hInstance);

       WindowClass.lpfnWndProc := InitWndProc;

       WindowClass.lpszClassName := WinClassName;

       if Windows.RegisterClass(WindowClass) = 0 then RaiseLastOSError;

      end;

      CreationControl := Self;

      CreateWindowHandle(Params);

      if FHandle = 0 then RaiseLastOSError;

      if (GetWindowLong(FHandle, GWL_STYLE) and WS_CHILD <> 0) and (GetWindowLong(FHandle, GWL_ID) = 0) then

       SetWindowLong(FHandle, GWL_ID, FHandle);

      end;

      StrDispose(FText);

      FText := nil;

      UpdateBounds;

     Perform(WM_SETFONT, FFont.Handle, 1);

     if AutoSize then AdjustSize;

    end;

    Собственно создание окна опять происходит не здесь, а в методе

    CreateWindowHandle
    , который очень прост: он состоит из одного только вызова API-функции
    CreateWindowEx
    с параметрами, значения которых берутся из полей записи
    Params
    типа
    TCreateParams
    (листинг 1.10)

    Листинг 1.10. Запись
    TCreateParams

    TCreateParams = record

     Caption: PChar;

     Style: WORD;

     ExStyle: DWORD;

     X, Y: Integer;

     Width, Height: Integer;

     WndParent: HWnd;

     Param: Pointer;

     WindowClass: TWndClass;

     WinClassName: array[0..63] of Char;

    end;

    В записи

    Params
    хранятся параметры как окна, передаваемые в функцию
    WindowCreateEx
    , так и оконного класса (поля
    WindowClass
    и
    WndClassName
    ). Все поля инициализируются методом
    CreateParams
    на основе значений свойств оконного компонента. Данный метод виртуальный и может быть перекрыт в наследниках, что бывает полезно, когда необходимо изменить стиль создаваемого окна. Например, добавив расширенный стиль
    WS_EX_CLIENTEDGE
    (или, как вариант,
    WS_EX_STATICEDGE
    ), можно получить окно с необычной рамкой (листинг 1.11).

    Листинг 1.11. Перекрытие метода
    CreateParams

    procedure TForm1.CreateParams(var Params: TCreateParams);

    begin

     // Вызов унаследованного метода заполнения всех полей

     // записи Params

     inherited CreateParams(Params);

     // Добавляем флаг WS_EX_CLIENTEEDGE к расширенному стилю окна

     Params.ExStyle := Params.ExStyle or WS_EX_CLIENTEDGE;

    end;

    Примечание

    В разд. 1.1.4 мы говорили, что имя оконного класса, который VCL создает для оконного компонента, совпадает с именем класса этого компонента. Здесь мы видим, что на самом деле имя оконного класса можно сделать и другим, для этого достаточно изменить значение поля

    Params.WinClassName
    .

    Обратите внимание, что всем без исключения классам метод

    CreateWnd
    назначает одну и ту же оконную процедуру —
    InitWndProc
    . Это является основой в обработке сообщений с помощью VCL, именно поэтому оконная процедура назначается не в методе
    CreateParams
    , а в методе
    CreateWnd
    , чтобы в наследниках нельзя было изменить это поведение (метод
    CreateWnd
    тоже виртуальный, но при его переопределении имеет смысл только добавлять какие-то действия, а не изменять поведение унаследованного метода).

    Чтобы понять, как работает процедура

    InitWndProc
    , обратите внимание на еще одну особенность метода
    CreateWnd
    : перед вызовом
    CreateWindowHandle 
    (т.е. непосредственно перед созданием окна) он записывает ссылку на текущий объект в глобальную переменную
    СreationСontrol
    . Эта переменная затем используется процедурой
    InitWndProc
    (листинг 1.12).

    Листинг 1.12. Оконная процедура
    InitWndProc

    function InitWndProc(HWindow: HWnd; Message, WParam, LParam: LongInt): LongInt;

    begin

     CreationControl.FHandle := HWindow;

     SetWindowLong (HWindow, GWL_WNDPROC, LongInt(CreationControl.FObjectInstance));

     if (GetWindowLong(HWindow, GWL_STYLE) and WS_CHILD <> 0) and (GetWindowLong(HWindow, GWL_ID) = 0) then

      SetWindowLong(HWindow, GWL_ID, HWindow);

     SetProp(HWindow, MakeIntAtom(ControlAtom), THandle(CreationControl));

     SetProp(HWindow, MakeIntAtom(WindowAtom), THandle(CreationControl));

     asm

      PUSH LParam

      PUSH WParam

      PUSH Message

      PUSH HWindow

      MOV EAX, CreationControl

      MOV CreationControl, 0

      CALL [EAX].TWinControl.FObjectInstance

      MOV Result, EAX

     end;

    end;

    Примечание

    Код функции

    InitWndProc
    в листинге 1.12 взят из Delphi 7. В более поздних версиях код включает в себя поддержку окон, работающих с кодировкой Unicode, поэтому там предусмотрен выбор между ANSI- и Unicode-вариантами функций API (подробнее об ANSI- и Unicode-вариантах см разд. 1.1.12). Такой код сложнее понять из-за этих дополнений. Кроме того, из листинга 1.12 убрано все, что относится к компиляции под LINUX, чтобы не засорять листинг.

    Из листинга 1.12 видно, что оконная процедура

    InitWndProc
    не обрабатывает сама никаких сообщений, а просто переназначает оконную процедуру у окна. Таким образом,
    InitWndProc
    для каждого окна вызывается только один раз, чтобы переназначить оконную процедуру. Обработка того сообщения, которое привело к вызову
    InitWndProc
    , тоже передается в эту новую процедуру (ассемблерная вставка в конце
    InitWndProc
    делает именно это). При просмотре этого кода возникают два вопроса. Первый — зачем писать такую оконную процедуру, почему бы не назначить нужную процедуру обычным образом? Здесь все дело в том. что стандартными средствами оконная процедура назначается одна на весь оконный класс, в то время как по внутренней логике VCL каждый экземпляр компонента должен иметь свою собственную оконную процедуру. Добиться этого можно только порождением подкласса уже после создания окна. Указатель на свою уникальную оконную процедуру (откуда эта процедура берется и почему она должна быть уникальной, мы поговорим в следующем разделе) каждый экземпляр хранит в поле
    FObjectInstance
    . Значение глобальной переменной
    CreationControl
    присваивается, как мы помним, непосредственно перед созданием окна, а первое свое сообщение окно получает буквально в момент создания. Так как VCL — принципиально однонитевая библиотека, ситуация, когда другой код вклинивается между присваиванием значения переменной
    CreationControl
    и вызовом
    InitWndProc
    , невозможна, так что в
    InitWndProc
    попадает правильная ссылка на создаваемый объект.

    Второй вопрос — зачем так сложно? Почему в методе

    CreateWnd
    сразу после создания окна нельзя было вызвать
    SetWindowLong
    и установить нужную оконную процедуру там, вместо того чтобы поручать это процедуре
    InitWndProc
    ? Здесь ответ такой: это сделано потому, что свои первые несколько сообщений (например, сообщения
    WM_CREATE
    и
    WM_NCCREATE
    ) окно получает до того, как функция
    CreateWindowEx
    завершит свою работу. Чтобы завершить создание окна,
    CreateWindowEx
    отправляет несколько сообщений окну, и только после того как окно обработает их должным образом, процесс создания окна считается завершенным. Так что назначать уникальную оконную процедуру после завершения
    CreateWindowEx
    — это слишком поздно. Именно поэтому уникальная оконная процедура назначается таким неочевидным и несколько неуклюжим способом.

    1.1.8. Обработка сообщений с помощью VCL

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

    Кроме сообщений, предусмотренных в системе, компоненты VCL обмениваются сообщениями, созданными авторами этой библиотеки. Эти сообщения имеют префиксы

    CM_
    и
    CN_
    . Они нигде не документированы, разобраться с ними можно только по исходным кодам VCL. При разработке собственных компонентов приходится обрабатывать эти сообщения, которые мы здесь не будем полностью описывать, но некоторые из них будут упоминаться в описании работы VCL с событиями.

    В Windows API нет понятия главного окна — все окна, не имеющие родителя (или владельца в терминах системы), равноценны, и приложение может продолжать работу после закрытия любых окон. Но в VCL введено понятие главной формы: форма, которая создается первой, становится главной, и ее закрытие означает закрытие всего приложения.

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

    WS_EX_APPWINDOW
    ). Обычно в приложении одно окно главного уровня, и оно играет роль главного окна этого приложения, хотя система не запрещает приложению создавать несколько окон верхнего уровня (примеры — Internet Explorer, Microsoft Word). Разработчики VCL пошли по другому пути: окно верхнего уровня, ответственное за появление кнопки на панели задач, создается объектом
    Application
    . Дескриптор этого окна хранится в свойстве
    Application.Handle
    , а само оно невидимо, т.к. имеет нулевые размеры. Как и любое другое, это окно имеет оконную процедуру и может обрабатывать сообщения. Главная форма — это отдельное окно, не имеющее, с формальной точки зрения, никакого отношения к кнопке на панели задач. Видимость связи между этой кнопкой и главной формой обеспечивается взаимодействием объекта
    Application
    и объекта главной формы внутри VCL. Таким образом, даже простейшее VCL-приложение создает два окна: невидимое окно объекта Application и окно главной формы. Окно, создаваемое объектом
    Application
    , мы будем называть невидимым окном приложения. Невидимое окно приложения по умолчанию становится владельцем (в терминах системы) всех форм, у которых явно не установлено свойство
    Parent
    , в том числе и главной формы.

    При обработке сообщений VCL решает две задачи: выборка сообщений из очереди и передача сообщения конкретному компоненту. Рассмотрим сначала первую задачу.

    Выборкой сообщений из очереди занимается объект

    Application
    , непосредственно за извлечение и диспетчеризацию сообщения отвечает его метод
    ProcessMessage
    (листинг 1.13).

    Листинг 1.13. Метод

    TApplication.ProcessMessage

    function TApplication.ProcessMessage(var Msg: TMsg): Boolean;

    var

     Unicode: Boolean;

     Handled: Boolean;

     MsgExists: Boolean;

    begin

     Result := False;

     if PeekMessage(Msg, 0, 0, 0, PM_NOREMOVE) then

     begin

      Unicode := (Msg.hwnd <> 0) and IsWindowUnicode(Msg.hwnd);

      if Unicode then MsgExists := PeekMessageW(Msg, 0, 0, 0, PM_REMOVE)

      else MsgExists := PeekMessage(Msg, 0, 0, 0, PM_REMOVE);

      if not MsgExists then Exit;

      Result := True;

      if Msg.Message <> WM_QUIT then

      begin

       Handled := False;

       if Assigned(FOnMessage) then FOnMessage(Msg, Handled);

       if not IsPreProcessMessage(Msg) and not IsHintMsg(Msg) and not Handled and

        not IsMDIMsg(Msg) and not IsKeyMsg(Msg) and not IsDlgMsg(Msg) then

       begin

        TranslateMessage(Msg);

        if Unicode then DispatchMessageW(Msg);

        else DispatchMessage(Msg);

       end;

      end else FTerminate := True;

     end;

    end;

    В этом коде отдельного комментария требует то, как используется функция

    PeekMessage
    . Сначала эта функция вызывается с параметром
    PM_NOREMOVE
    , — так выполняется проверка условия, что в очереди присутствует сообщение, а также выясняется, для какого окна предназначено первое сообщение в очереди. Само сообщение при этом остается в очереди. С помощью функции
    IsWindowUnicode
    производится проверка, использует ли окно-адресат кодировку ANSI или Unicode, и затем, в зависимости от этого, сообщение извлекается либо функцией
    PeekMessage
    , либо ее Unicode-аналогом
    PeekMessageW
    (о Unicode-аналогах функций см. разд. 1.1.12). При диспетчеризации сообщения также вызывается либо функция
    DispatchMessage
    , либо ее Unicode-аналог
    DispatchMessageW
    .

    Если метод

    ProcessMessage
    с помощью
    PeekMessage
    извлекает из очереди сообщение
    WM_QUIT
    , то он устанавливает в
    True
    поле
    FTerminate
    и завершает свою работу. Обработка всех остальных сообщений, извлеченных из очереди состоит из следующих основных этапов (см. рис. 1.6):

    1. Если назначен обработчик

    Application.OnMessage
    , сообщение передается ему. В этом обработчике можно установить параметр-переменную
    Handle
    в
    True
    , что означает, что сообщение не нуждается в дополнительной обработке.

    2. Второй шаг —это предварительная обработка сообщения (вызов метода

    IsPreProcessMessage
    ). Этот шаг появился только начиная с BDS 2006, в более ранних версиях его не было. Обычно предварительную обработку осуществляет то окно, которому предназначено это сообщение, но если окно-адресат не является VCL-окном, производится поиск VCL-окна по цепочке родителей. Кроме того, если какое-либо окно захватит ввод мыши, предварительную обработку сообщений будет осуществлять именно оно. Если оконный компонент, удовлетворяющий этим требованиям, найден, вызывается его метод
    PreProcessMessage
    , который возвращает результат логического типа. Если компонент вернул
    True
    , то на этом обработка сообщения заканчивается. Отметим, что ни один из стандартных компонентов VCL не использует эту возможность перехвата сообщений, она реализована для сторонних компонентов.

    3. Затем, если на экране присутствует всплывающая подсказка (hint), проверяется, должно ли пришедшее сообщение прятать эту подсказку, и если да, то она убирается с экрана (метод

    IsHintMessage
    ). Список сообщений, которые должны прятать окно подсказки, зависит от класса этого окна (здесь имеется в виду класс VCL, а не оконный класс) и определяется виртуальным методом
    THintWindow.IsHintMsg
    . Стандартная реализации этого метода рассматривает как "прячущие" все сообщения от мыши, клавиатуры, сообщения об активации и деактивации программы и о действиях пользователя с меню или визуальными компонентами. Если метод
    IsHintMessage
    возвращает
    False
    , то сообщение дальше не обрабатывается, но стандартная реализация этого метода всегда возвращает
    True
    .

    4. Далее проверяется значение параметра

    Handled
    , установленное в обработчике
    OnMessage
    (если он назначен). Если это значение равно
    True
    , метод
    ProcessMessage
    завершает свою работу, и обработка сообщения на этом заканчивается. Таким образом, обработка сообщения по событию
    OnMessage
    не может отменить предварительную обработку сообщения и исчезновение всплывающей подсказки.

    Рис. 1.6. Одна итерация петли сообщений VCL (блок-схема метода 

    Application.ProcessMessage
    )


    5. Если главная форма приложения имеет стиль MDIForm, и одно из его дочерних MDI-окон в данный момент активно, сообщение передается функции

    TranslateMDISysAccel
    . Если эта функция вернет
    True
    , то обработка сообщения на этом завершается (все эти действия выполняются в методе
    IsMDIMsg
    ).

    6. Затем, если получено клавиатурное сообщение, оно отправляется на предварительную обработку тому же окну, что и в пункте 2 (метод

    IsKeyMsg
    ). Предварительная обработка клавиатурного сообщения начинается с попытки найти полученную комбинацию клавиш среди "горячих" клавиш контекстно-зависимого меню и выполнить соответствующую команду. Если контекстно-зависимое меню не распознало сообщение как свою "горячую" клавишу, то вызывается обработчик события
    OnShortCut
    окна, осуществляющего предварительную обработку (если это окно не является формой и не имеет этого события, то вызывается
    OnShortCut
    его родительской формы). Если обработчик
    OnShortCut
    не установил свой
    параметр
    Handled в True, полученная комбинация клавиш ищется среди "горячих" клавиш сначала главного меню, а потом — среди компонентов
    TActionList
    . Если и здесь искомая комбинация не находится, возникает событие
    Application.OnShortCut
    , которое также имеет параметр
    Handled
    , позволяющий указать, что сообщение в дополнительной обработке не нуждается. Если обработчик не установил этот параметр, то сообщение передается главной форме приложения, которое пытается найти нажатую комбинацию среди "горячих" клавиш своего контекстного меню, передает его обработчику
    OnShortCut
    , ищет среди "горячих" клавиш главного меню и компонентов
    TActionList
    . Если нажатая клавиша не является "горячей", но относится к клавишам, использующимся для управления диалоговыми окнами (<Tab>, стрелки, <Esc> и т.п.), форме передается сообщение об этом, и при необходимости сообщение обрабатывается. Таким образом, на данном этапе средствами VCL эмулируются функции
    TranslateAccelerator
    и
    IsDialogMessage
    .

    7. Если на экране присутствует один из стандартных диалогов (в VCL они реализуются классами

    TOpenDialog
    ,
    TSaveDialog
    и т.п.), то вызывается функция
    IsDialogMessage
    , чтобы эти диалоги могли нормально функционировать (метод
    IsDlgMsg
    ).

    8. Если ни на одном из предыдущих этапов сообщение не было обработано, то вызываются функции

    TranslateMessage
    и
    DispatchMessage
    , которые завершают обработку сообщения путем направления его соответствующей оконной функции.

    Примечание

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

    OnShortCut
    активной формы, потом —
    Application.OnShortCut
    , затем —
    OnShortCut
    главной формы. Если в момент получения сообщения главная форма активна, то она дважды будет проверять соответствие клавиши "горячим" клавишам своих меню и событие
    OnShortCut
    тоже возникнет дважды (первый раз поле
    Msg.Msg
    равно
    CN_KEYDOWN
    , второй —
    CM_APPKEYDOWN
    ). Эта проверка осуществляется дважды только в том случае, если комбинация клавиш не распознается как "горячая" клавиша — в противном случае цепочка проверок обрывается при первой проверке.

    Метод

    ProcessMessage
    возвращает
    True
    , если сообщение извлечено и обработано, и
    False
    , если очередь была пуста. Этим пользуется метод
    HandleMessage
    , который вызывает
    ProcessMessage
    и, если тот вернет
    False
    , вызывает метод
    Application.Idle
    для низкоприоритетных действий, которые должны выполняться только при отсутствии сообщений в очереди. Метод
    Idle
    , во-первых, проверяет, над каким компонентом находится курсор мыши, и сохраняет ссылку на него в поле
    FMouseControl
    , которое используется при последующей проверке, нужно ли прятать всплывающую подсказку. Затем, при необходимости, прячется старая всплывающая подсказка и показывается новая. После этого вызывается обработчик
    Application.OnIdle
    , если он назначен. Этот обработчик имеет параметр
    Done
    , по умолчанию равный
    True
    . Если в коде обработчика он не меняется на
    False
    , метод
    Idle
    инициирует события
    OnUpdate
    у всех объектов
    TAction
    , у которых они назначены (если
    Done
    после вызова принял значение
    False
    ,
    HandleMessage
    не тратит время на инициацию событий
    OnUpdate
    ).

    Примечание

    В BDS 2006 появилось свойство

    Application.ActionUpdateDelay
    , позволяющее снизить нагрузку на процессор,  откладывая на некоторое время обновление объектов
    TAction
    . Если значение этого свойства не равно нулю, в методе
    Idle
    вместо вызова запускается таймер и
    OnUpdate
    вызывается по его сигналу.

    Затем, независимо от значения

    Done
    , с помощью процедуры
    CheckSynchronize
    проверяется, есть ли записи в списке методов, ожидающих синхронизации (эти методы помещаются в указанный список при вызове
    TThread.Synchronize
    ). Если список не пуст, выполняется первый из этих методов (при этом он, разумеется, удаляется из списка). Затем, если остался равным
    True
    , а список методов для синхронизации был пуст (т. е. никаких дополнительных действий выполнять не нужно),
    HandleMessage
    вызывает функцию Windows API
    WaitMessage
    . Эта функция приостанавливает выполнение нити до тех пор, пока в ее очереди не появятся сообщения.

    Примечание

    Вызов

    Synchronize
    приводит к тому, что соответствующий метод будет выполнен основной нитью приложения, а нить, вызвавшая
    Synchronize
    , будет приостановлена до тех пор, пока главная нить не сделает это. Отсюда видно, насколько бредовыми являются советы (заполонившие Интернет, а также встречающиеся в некоторых книгах, например, у Архангельского) помещать весь код нити в
    Synchronize
    . В этом случае дополнительная нить вообще не будет ничего делать, все будет выполняться основной нитью, и выигрыша от создания дополнительной нити просто не будет. Поэтому в
    Synchronize
    нужно помещать только те действия, которые не могут быть выполнены неосновной нитью (например, обращения к свойствам и методам VCL-компонентов).

    Главная петля сообщений в VCL реализуется методом

    Application.Run
    , вызов которого автоматически вставляется в dpr-файл VCL-проекта.
    Application.Run
    вызывает в цикле метод
    HandleMessage
    , пока поле
    FTerminate
    не окажется равным
    True
    (напомним, что значение
    True
    присваивается этому полю, когда
    ProcessMessage
    извлекает из очереди сообщение
    WM_QUIT
    , а также при обработке сообщения
    WM_ENDSESSION
    и при закрытии главной формы).

    Для организации локальной петли сообщений существует метод

    Application.ProcessMessages
    . Он вызывает
    ProcessMessage
    до тех пор, пока очередь не окажется пустой. Вызов этого метода рекомендуется вставлять в обработчики событий, которые работают долго, чтобы в это время программа не теряла способности реагировать на действия пользователя.

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

    Idle
    . На самом деле это не так. Модуль
    Classes
    содержит переменную
    WakeMainThread
    , хранящую указатель на метод, который вызывается при помещении нового метода в список синхронизации. В конструкторе
    TApplication
    этой переменной присваивается указатель на метод
    TApplication.WakeMainThread
    , который посылает сообщение
    WM_NULL
    невидимому окну приложения. Сообщение
    WM_NULL
    — это "пустое" сообщение, на которое окно не должно реагировать (оно используется, например, при перехвате сообщений ловушкой: ловушка не может запретить передачу окну сообщения, но может изменить его на
    WM_NULL
    , чтобы окно проигнорировало сообщение). Невидимое окно приложения, тем не менее, не игнорирует это сообщение, а вызывает при его получении
    CheckSynchronize
    . Таким образом, синхронное выполнение метода не откладывается до вызова
    Idle
    , а выполняется достаточно быстро, в том числе и в локальной петле сообщений. Более того, если главная нить перешла в режим ожидания получения сообщения (через вызов
    WaitMessage
    ), то вызов
    Synchronize
    в другой нити прервет это ожидание, т.к. в очередь будет поставлено сообщение
    WM_NULL
    .

    Процедура

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

    Примечание

    Описанный здесь способ синхронизации работы нитей появился, начиная с шестой версии Delphi. В более ранних версиях списка методов для синхронизации не было. Вместо этого в главной нити создавалось специальное невидимое окно, а метод

    TThread.Synchronize
    с помощью
    SendMessage
    посылал этому окну сообщение
    CM_EXECPROC
    с адресом объекта, метод которого нуждался в синхронизации. Метод выполнялся в оконной процедуре данного окна при обработке этого сообщения. Такой механизм также позволял осуществить синхронизацию в приложениях без VCL. но требовал обязательного наличия петли сообщений в главной нити и не давал возможности выполнять синхронизацию, пока главная нить находилась в локальной петле сообщений. Из-за смены механизма синхронизации могут возникнуть проблемы при переносе в новые версии старых приложений: если раньше для обеспечения работы синхронизации было достаточно организовать петлю сообщений, то теперь необходимо найти место для вызова 
    CheckSynchronize
    . Разумеется, при переносе полноценных VCL-приложений эти проблемы не возникают, т.к. все, что нужно, содержится в методах класса
    TApplication
    .

    Принятый в Delphi 6 способ синхронизации получил дальнейшее развитие в BDS 2006. В классе TThread появился метод

    Queue
    для передачи в код главной нити вызов метода для асинхронного выполнения, т.е. такого, когда нить вызвавшая
    Queue
    , после этого продолжает работать, не дожидаясь, пока главная нить выполнит требуемый код. Главная нить выполняет этот код параллельно тогда, когда для этого предоставляется случай (информация получена из анализа исходных кодов модулей VCL, т.к. справка Delphi, к сожалению не описывает данный метод: в справке BDS 2006 он вообще не упомянут, в справке Delphi 2007 упомянут, но все описание состоит из одной фразы "This is Queue, а member of class TThread"). Метод
    Queue
    использует тот же список методов синхронизации, что и
    Synchronize
    , только элементы этого списка пополнились признаком асинхронного выполнения и процедура
    CheckSynchronize
    не уведомляет нить, поместившую метод в список, о его выполнении, если метод помещен в список синхронизации методом 
    Queue
    . А метод
    TThread.RemoveQueuedEvents
    позволяет удалять из списка методов синхронизации асинхронные вызовы, если нужда в их выполнении отпала.

    При показе VCL-формы в модальном режиме выборка сообщений из очереди осуществляется особым образом. Модальные окна в VCL — это не то же самое, что модальные диалоги с точки зрения API. Диалог может быть создан только на основе шаблона, и его модальность обеспечивается самой операционной системой, a VCL допускает модальность для любой формы, позволяя разработчику не быть ограниченным возможностями предусмотренного системой шаблона. Достигается это следующим образом: при вызове метода

    ShowModal
    все окна запрещаются средствами VCL, затем окно показывается обычным образом, как немодальное, но из-за того, что все остальные окна запрещены, создается эффект модальности.

    Внутри

    ShowModal
    создается своя петля сообщений. В этой петле в цикле вызывается метод
    Application.HandleMessage
    до тех пор, пока не будет установлено свойство
    ModalResult
    или не придет сообщение
    WM_QUIT
    . После завершения этой петли вновь разрешаются все окна, которые были разрешены до вызова
    ShowModal
    , а "модальная" форма закрывается. В отличие от системных модальных диалогов модальная форма VCL во время своей активности не посылает родительскому окну сообщение
    WM_ENTERIDLE
    , но благодаря тому, что "модальная" петля сообщений использует
    HandleMessage
    , будет вызываться
    Idle
    , а значит, будет возникать событие
    Application.OnIdle
    , которое позволит выполнять фоновые действия.

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

    Classes
    содержит недокументированную функцию
    MakeObjectInstance
    , описанную так:

    type TWndMethod = procedure(var Message: TMessage) of object;

    function MakeObjectInstance(Method: TWndMethod): Pointer;

    Тип

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

    Функция

    MakeObjectInstance
    динамически формирует новую оконную процедуру и возвращает указатель на нее (следовательно, любое VCL-приложение содержит самомодифицирующийся код). Задача этой динамически созданной процедуры — передать управление тому методу, который был указан при вызове
    MakeObjectInstance
    (таким образом, различные оконные процедуры, сформированные этой функцией, отличаются только тем, метод
    MainWndProc
    какого экземпляра класса они вызывают).

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

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

    MainWndProc
    — это невиртуальный метод, обеспечивающий решение технических вопросов: удаление "мусора", оставшегося при обработке сообщения и обработку исключений. Собственно обработку сообщения он передает методу, на который указывает свойство
    WindowProc
    . Это свойство имеет тип
    TWndMethod
    и по умолчанию указывает на виртуальный метод
    WndProc
    . Таким образом, если разработчик не изменял значения свойства
    WindowProc
    , обработкой сообщения занимается
    WndProc
    .

    Метод

    WndProc
    обрабатывает только те сообщения, которые должны быть обработаны специальным образом, чтобы поддержать функциональность VCL. Особым образом метод
    WndProc
    обрабатывает сообщения от мыши: он следит, в границы какого визуального компонента попадают координаты "мышиных" сообщений, и если этот компонент отличается от того, в чью область попало предыдущее сообщение, компоненту из предыдущего сообщения дается команда обработать сообщение
    CM_MOUSELEAVE
    , а новому — сообщение
    CM_MOUSENTER
    . Это обеспечивает реакцию визуальных компонентов на приход и уход мыши (в частности, генерирование событий
    OnMouseEnter
    и
    OnMouseExit
    ). Необходимость реализации такого способа отслеживания прихода и ухода мыши вместо использования системных сообщений
    WM_MOUSEHOVER
    и
    WM_MOUSELEAVE
    связана с тем, что системные сообщения пригодны только для работы с окнами, а VCL отслеживает приход и уход мыши и на неоконные визуальные компоненты. Впрочем,
    WM_MOUSELEAVE
    в
    WndProc
    тоже служит дополнительным средством проверки ухода мыши.

    Примечание

    Описанный здесь способ отслеживание ухода и прихода мыши реализован, начиная с BDS 2006. В более ранних версиях Delphi за это отвечал метод

    Application.Idle
    , который, как мы помним, вызывается только тогда когда в очереди нет сообщений. Из-за этого иногда (например, при быстром движении мышью) события ухода и прихода мыши пропускались, нарушая логику работы программы. Поэтому в BDS 2006 способ контроля прихода и ухода мыши был изменен, и ответственность за это возложена на метод
    TWinControl.WndProc
    . Это позволило избавиться от одного недостатка — потери событий, но породило другой: теперь перехват и самостоятельная обработка "мышиных" сообщений до того, как это сделает метод
    WndProc
    , может привести к потере возможности отслеживания прихода и ухода мыши. Впрочем, эта проблема проявляется только при выполнении программистом определенных осмысленных действий по внедрению кода в оконную процедуру, поэтому она гораздо менее серьезна, чем та от которой удалось избавиться.

    События мыши метод

    WndProc
    диспетчеризует самостоятельно, без помощи функции
    DispatchMessage
    . Это связано с тем, что
    DispatchMessage
    передаёт сообщение тому оконному компоненту, которому оно предназначено с точки зрения системы. Однако с точки зрения VCL этот компонент может являться родителем для неоконных визуальных компонентов, и если сообщение от мыши связано с их областью, то оно должно обрабатываться соответствующим неоконным компонентом, а не его оконным родителем.
    DispatchMessage
    ничего о неоконных компонентах не "знает" и не может передать им сообщения, поэтому разработчикам VCL пришлось реализовывать свой способ. Те сообщения, которые метод
    WndProc
    не обрабатывает самостоятельно (а их — подавляющее большинство), он передает в метод Dispatch, который объявлен и реализован в классе
    TObject
    . На первый взгляд может показаться странным, что в самом базовом классе реализована функциональность, использующаяся только в визуальных компонентах. Эта странность объясняется тем, что разработчики Delphi встроили поддержку обработки сообщений непосредственно в язык. Методы класса, описанные с директивой message, служат специально для обработки сообщений. Синтаксис описания такого метода следующий:

    procedure <Name>(var Message: <TMsgType>); message <MsgNumber>;

    <MsgNumber>
    — это номер сообщения, для обработки которого предназначен метод. Имя метода может быть любым, но традиционно оно совпадает с именем константы сообщения за исключением того, что в нем выбран более удобный регистр символов и отсутствует символ "_" (например, метод для обработки
    WM_SIZE
    будет называться
    WMSize
    ).

    В качестве типа параметра

    <TMsgType>
    компилятор разрешает любой тип, но на практике имеет смысл только использование типа
    TMessage
    или "совместимого" с ним. Тип
    TMessage
    описан в листинге 1.14.

    Листинг 1.14. Описание типа
    TMessage

    TMessage = packed record

     Msg: Cardinal;

     case Integer of

     0: (

      WParam: LongInt;

      LParam: LongInt;

      Result: LongInt);

     1: (

      WParamLo: Word;

      WParamHi: Word;

      LParamLo: Word;

      LParamHi: Word;

      ResultLo: Word;

      ResultHi: Word);

    end;

    Поле Msg содержит номер сообщения, поля

    WParam
    и
    LParam
    — значение одноименных параметров сообщения. Поле
    Result
    — выходное: метод, осуществляющий окончательную обработку сообщения, заносит в него то значение, которое должна вернуть оконная процедура. Поля с суффиксами
    Lo
    и
    Hi
    позволяют обращаться отдельно к младшему и старшему словам соответствующих полей, что может быть очень полезно, когда эти параметры содержат пару 16-разрядных значений. Например, у сообщения
    WM_MOUSEREMOVE
    младшее слово параметра
    LParam
    содержит X-координату мыши, старшее — Y-координату. В случае обработки этого сообщения поле
    LParamLo
    будет содержать X-координату,
    LParamHi
    — Y-координату.

    "Совместимыми" с

    TMessage
    можно назвать структуры, которые имеют такой же размер, а также параметр
    Msg
    , задающий сообщение. Эти структуры учитывают специфику конкретного сообщения. Их имена образуются из имени сообщения путем отбрасывания символа и добавления префикса
    T
    . Для уже упоминавшегося сообщения
    WM_MOUSEMOVE
    соответствующий тип выглядит, как показано в листинге 1.15.

    Листинг 1.15. Тип
    TWMNCMouseMove

    TWMNCMouseMove = packed record

     Msg: Cardinal;

     HitTest: LongInt;

     XCursor: SmallInt;

     YCursor: SmallInt;

     Result: LongInt;

    end;

    Параметр

    WParam
    переименован в
    HitTest
    , что лучше отражает его смысл в данном случае, а параметр
    LParam
    разбит на две 16-разрядных части:
    XCursor
    и
    YCursor
    .

    Параметр метода для обработки сообщения имеет тип, соответствующий обрабатываемому сообщению (при необходимости можно описать свой тип), или тип

    TMessage
    . Таким образом, обработчик сообщения
    WM_MOUSEMOVE
    будет выглядеть так, как показано в листинге 1.16.

    Листинг 1.16. Объявление и реализация метода для обработки сообщения
    WM_MOUSEMOVE

    type

     TSomeForm = class(TForm)

     ...............

     procedure WMNCMouseMove(var Message: TWMNCMouseMove); message WM_NCMOUSEMOVE;

     ................

    end;


    procedure TSomeForm.WMNCMouseMove(var Message: TWMNCMouseMove);

    begin

     ...............

     inherited; // Возможно, этот вызов не будет нужен

    end;

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

    inherited
    позволяет вызвать унаследованный обработчик для данного сообщения. Таким образом, может образовываться целая цепочка вызовов унаследованных обработчиков одного и того же сообщения, каждый из которых выполняет свою часть обработки. Если у предков класса нет обработчика данного сообщения, директива
    inherited
    передает управление методу
    TObject.DetaultHandler
    . Вернемся к методу
    Dispatch
    . Он ищет среди обработчиков сообщения класса (собственных или унаследованных) метод для обработки сообщения, заданного полем
    Msg
    параметра
    Message
    и, если находит, передает управление ему. Если ни сам класс, ни его предки не содержат обработчика данного сообщения, то обработка передаётся методу
    DefaultHandler
    .

    Метод

    DefaultHandler
    виртуальный, в классе
    TObject
    он не выполняет никаких действий, но наследники его переопределяют. Впервые он переопределяется в классе
    TControl
    для обработки сообщений, связанных с получением и установкой заголовка окна —
    WM_GETTEXT
    ,
    WM_GETTEXTLENGTH
    и
    WM_SETTEXT
    . Напомним, что класс TControl является предком для всех визуальных компонентов, а не только оконных, и появление обработчика системных сообщений в этом классе — часть той имитации обработки сообщений неоконными компонентами, о которой мы уже говорили.

    В классе

    TWinControl
    метод
    DefaultHandler
    также переопределен. Помимо передачи некоторых сообщений дочерним окнам (об этом мы будем подробнее говорить чуть позже) и обработки некоторых внутренних сообщений он вызывает оконную процедуру, адрес которой хранится в свойстве
    DefWndProc
    . Это свойство содержит адрес, который был присвоен полю
    WindowClass.lpfnWndProc
    структуры
    TCreateParams
    в методе
    CreateParams
    . По умолчанию это поле содержит адрес стандартной оконной процедуры
    DefWindowProc
    . Как было сказано ранее, обработка сообщений при использовании API обычно завершается вызовом этой процедуры. В классе
    TCustomForm
    метод
    DefaultHandler
    также переопределен, если форма является MDI-формой, сообщения, присланные ей, передаются в процедуру
    DefFrameProc
    (за исключением
    WM_SIZE
    , которое передается в
    DefWindowProc
    ) независимо от того, какое значение имеет свойство
    DefWindowProc
    . Для всех остальных типов форм вызывается унаследованный от
    TWinControl DefaultHandler
    .

    Повторим еще раз всю цепочку обработки сообщений оконными компонентами VCL (рис. 1.7). Для каждого компонента создается уникальная оконная процедура, которая передает управление методу

    MainWndProc
    .
    MainWndProc
    передает управление методу, указатель на который хранится в свойстве
    WindowProc
    . По умолчанию это метод компонента
    WndProc
    . Он осуществляет обработку некоторых сообщений, но в большинстве случаев передает управление методу
    Dispatch
    , который ищет среди методов компонента или его предков обработчик данного сообщения. Если обработчик не найден, управление получает метод
    DefaultHandler
    (он может также получить управление и в том случае, если обработчик найден, но он вызывает
    inherited
    ).
    DefaultHandler
    самостоятельно обрабатывает некоторые сообщения, но большинство из них передаётся оконной процедуре, адрес хранится в свойстве
    DefWndProc
    (по умолчанию это стандартная функция Windows API
    DefWindowProc
    ).

    Рис. 1.7. Блок-схема оконной процедуры оконных компонентов VCL


    Класс

    TControl
    имеет метод
    Perform
    , с помощи которого можно заставить визуальный компонент выполнить обработку конкретного сообщения в обход оконной процедуры и системного механизма передачи сообщений.
    Perform
    приводит к непосредственному вызову метода, указатель на который хранится в свойстве
    WindowProc
    . Дальше цепочка обработки сообщений такая же, как и при получении сообщения через оконную процедуру. Для оконных компонентов вызов
    Perform
    по своим последствиям практически эквивалентен передаче сообщения с помощью
    SendMessage
    с двумя исключениями. Во-первых, при использовании
    SendMessage
    система обеспечивает переключение между нитями, и сообщение будет выполнено в той нити, которая создала окно, a
    Perform
    никакого переключения не производит, и обработка сообщения будет выполнена той нитью, которая вызвала
    Perform
    . Поэтому
    Perform
    , в отличие от
    SendMessage
    , можно использовать только в главной нити (напомним, что VCL — принципиально однонитевая библиотека, и создание форм вне главной нити с ее помощью недопустимо). Во-вторых,
    Perform
    выполняется чуть быстрее, т.к. оконная процедура и метод
    MainWndProc
    исключаются из цепочки обработки сообщения.

    Но основное преимущество

    Perform
    перед
    SendMessage
    заключается в том, что
    Perform
    пригоден для работы со всеми визуальными компонентами, а не только с оконными. Неоконные визуальные компоненты не могут иметь оконной процедуры, но цепочка обработки сообщений у них есть. В ней отсутствует оконная процедура и метол
    MainWndProc
    , a
    DefaultHandler
    не вызывает никаких стандартных оконных процедур, но во всем остальном эта цепочка полностью эквивалентна цепочке оконных компонентов. Таким образом, цепочка обработки сообщений оконных компонентов имеет две точки входа: оконную процедуру и метод
    Perform
    , а цепочка неоконных компонентов — только метод
    Perform
    . Следовательно, метод
    Perform
    универсален: он одинаково хорошо подходит как для оконных, так и для неоконных компонентов. Он широко применяется в VCL, т.к. позволяет единообразно работать с любыми визуальными компонентами.

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

    TWinControl
    включает в себя, не попадают ли координаты курсора в область какого-либо из дочерних неоконных компонентов. И если попадает, оконный компонент не обрабатывает это сообщение самостоятельно, а транслирует его соответствующему неоконному компоненту с помощью 
    Perform
    . Эта трансляция и обеспечивает получение сообщений неоконными компонентами.

    Сообщения в VCL транслируются не только неоконным, но и оконным компонентам. В Windows все сообщения, информирующие об изменении состояния стандартных элементов управления, получает их родительское окно, а не сам элемент. Например, при нажатии на кнопку уведомительное сообщение об этом получает не сама кнопка, а окно, ее содержащее. Сама кнопка получает и обрабатывает только те сообщения, которые обычно разработчику неинтересны. Это упрощает работу программиста, т.к. не требуется для каждого элемента управления писать свою оконную процедуру, все значимые сообщения получает оконная процедура родительского окна. Рассмотрим, что происходит при нажатии кнопки на форме. Окно, содержащее эту кнопку, получает сообщение

    WM_COMMAND
    , уведомляющее о возникновении события среди оконных компонентов. Параметры сообщения позволяют определить, какое именно событие и с каким элементом управления произошло (в данном случае событие будет
    BN_CLICKED
    ). Обработчик
    WM_COMMAND
    класса
    TWinControl
    находит компонент, вызвавший сообщение, и посылает ему сообщение
    CN_COMMAND
    (как видно из префикса, это внутреннее сообщение VCL) с теми же параметрами. В нашем примере это будет экземпляр класса
    TButton
    , реализующий кнопку, которую нажал пользователь. Получив
    CN_COMMAND
    , компонент начинает обработку произошедшего с ним события (в частности,
    TButton
    инициирует событие
    OnСlick
    ).

    Примечание

    К переопределению обработчика

    WM_COMMAND
    нужно относиться осторожно, чтобы не нарушить механизм трансляции сообщений. Примером неправильного переопределения может служить класс
    TCustomGrid
    . В форумах нередко встречаются вопросы, почему элементы управления, родителем которых является
    TDrawGrid
    или
    TStringGrid
    , некорректно ведут себя: кнопки при нажатии не генерируют событие
    OnClick
    , выпадающие списки остаются пустыми и т.д. Это связано с тем, что обработчик
    WM_COMMAND
    в
    TCustomGrid
    учитывает возможность существования только одного дочернего компонента — внутреннего редактора, возникающего при включенной опции
    goEditing
    . Остальным дочерним компонентам
    WM_COMMAND
    не транслируются, и они лишены возможности корректно реагировать на происходящие с ними события. Выходом из ситуации может стать либо создание наследника от
    TDrawGrid
    или
    TStringGrid
    , который правильно транслирует
    WM_COMMAND
    , либо назначение родительским окном компонента, вставляемого в сетку, формы, панели или иного оконного компонента, который правильно транслирует это сообщение.

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

    1. Как и у всякого окна, у оконного компонента VCL можно изменить оконную процедуру с помощью функции

    SetWindowLong
    . Этот способ лучше не применять, поскольку код VCL не будет ничего "знать" об этом переопределении, и сообщения, получаемые компонентом не через оконную процедуру, а с помощью
    Perform
    , не будут перехвачены. Другой недостаток данного способа — то, что изменение некоторых свойств компонента (например,
    FormStyle
    и
    BorderStyle
    у формы) невозможно без уничтожения окна и создания нового. Для программиста это пересоздание окна выглядит прозрачно, но новое окно получит новую оконную процедуру, и нужно будет выполнять перехват заново. Отследить момент пересоздания окна можно с помощью сообщения
    CM_RECREATEWND
    , обработчик которого уничтожает старое окно, а создание нового окна откладывается до момента первого обращения к свойству
    Handle
    . Если перехватить по сообщение, то, в принципе, после выполнения стандартного обработчика можно зaново установить перехват с помощью SetWindowLong, но т.к. этот способ не дает никаких преимуществ перед другими, более простыми, им все равно лучше не пользоваться.

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

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

    3. При написании нового компонента можно перекрыть виртуальный метод

    WndProc
    и реализовать обработку нужных сообщений в нем. Это позволяет компоненту перехватывать сообщения в самом начале цепочки (за исключением внешних обработчиков, установленных с помощью свойства
    WindowProc
    — здесь разработчик компонента не властен).

    4. Наиболее удобный способ самостоятельной обработки событий — написание их методов-обработчиков. Этот способ встречается чаще всего. Его недостатком является то, что номера обрабатываемых сообщений должны быть известны на этапе компиляции. Для системных сообщений и внутренних сообщений VCL это условие выполняется, но далее мы будем говорить об определяемых пользователем сообщениях, номера которых в некоторых случаях на этапе компиляции неизвестны. Обрабатывать такие сообщения с помощью методов с директивой невозможно.

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

    6. И наконец, можно написать оконную процедуру и поместить указатель на нее в свойство

    DefWndProc
    . Этот способ по своим возможностям практически эквивалентен предыдущему, но менее удобен. Однако предыдущий способ пригоден только для создания собственного компонента, в то время как
    DefWndProc
    можно изменять у экземпляров существующих классов. Напомним, что этот способ не подходит для форм, у которых
    FormStyle = fsMDIForm
    , т.к. такие формы игнорируют значение свойства
    DefWndProc
    .

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

    Метод

    WndProc
    оконного компонента транслирует сообщения от мыши неоконным визуальным компонентам, родителем которых он является. Например. если положить на форму компонент
    TImage
    и переопределить у этой формы метод для обработки сообщения
    WM_LBUTTONDOWN
    , то нажатие кнопки мыши над
    TImage
    не приведет к вызову этого метода, т.к.
    WndProc
    передаст это сообщение в
    TImage
    , и
    Dispatch
    не будет вызван. Но если переопределить
    WndProc
    или изменить значение свойства
    WindowProc
    (т.е. использовать второй или третий метод перехвата), то можно получать и обрабатывать и те "мышиные" сообщения, которые должны транслироваться неоконным дочерним компонентам. Это общее правило: чем раньше встраивается собственный код в цепочку обработки сообщений, тем больше у него возможностей. Как мы уже говорили, начиная с BDS 2006 появился еще один способ перехвата сообщений — перекрытие метода
    PreProcessMessage
    . Этот способ нельзя ставить в один ряд с перечисленными ранее шестью способами, т.к. он имеет два существенных отличия от них. Во-первых, с помощью этого способа перехватываются все сообщения, попавшие в петлю сообщений, а не только те, которые посланы конкретному компоненту, из-за чего может понадобиться дополнительная фильтрация сообщений. Во-вторых, метод
    PreProcessMessage
    перехватывает сообщения, попавшие в петлю сообщений, а не в оконную процедуру компонента. С одной стороны, это даёт возможность перехватывать те сообщения, которые метод
    Аррlication.ProcessMessage
    не считает нужным передавать в оконную процедуру, но с другой стороны, не позволяет перехватывать те сообщения, которые окно получает, минуя петлю сообщений (например, те, которые отправлены с помощью
    SendMessage
    или
    Perform
    ). По этим причинам область применения данного способа совсем другая, чем у способов, связанных с внедрением кода в оконную процедур. Перекрытие
    PreProcessMessage
    сопоставимо, скорее, с использованием события
    Application.OnMessage
    .

    Различные способы перехвата сообщений иллюстрируются рядом примеров на прилагающемся к книге компакт-диске: использование свойства

    WindowProc
    показано в примерах
    Line
    ,
    CoordLabel
    и
    PanelMsg
    , перекрытие метода
    WndProc
    — в примере
    NumBroadcast
    , создание метода для обработки сообщения — в примере
    ButtonDel
    .

    1.1.9. Сообщения, определяемые пользователем

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

    □ сообщения оконного класса;

    □ сообщения приложения;

    □ глобальные (строковые) сообщения.

    Для каждого из них выделен отдельный диапазон номеров. Номера стандартных сообщений лежат в диапазоне от 0 до

    WM_USER-1
    (
    WM_USER
    — константа, для 32-разрядных версий Windows равная 1024).

    Сообщения оконного класса имеют номера в диапазоне от

    WM_USER
    до
    WM_APP-1
    (
    WM_APP
    имеет значение 32 768). Программист может выбирать произвольные номера для своих сообщений в этом диапазоне. Каждое сообщение должно иметь смысл только для конкретного оконного класса. Для различных оконных классов можно определять сообщения, имеющие одинаковые номера. Система никак не следит за тем, чтобы сообщения, определенные для какого-либо оконного класса, посылались только окнам этого класса — программист должен сам об этом заботиться. В этом же диапазоне лежат сообщения, специфические для стандартных оконных классов
    'BUTTON'
    ,
    'EDIT'
    ,
    'LISTBOX'
    ,
    'COMBOBOX'
    и т.п.

    Использование сообщений из этого диапазона иллюстрируется примером ButtonDel.

    Диапазон от

    WM_APP
    до 49 151 (для этого значения константа не предусмотрена) предназначен для сообщений приложения. Номера этих сообщений также выбираются программистом произвольно. Система гарантирует, что ни один из стандартных оконных классов не задействует сообщения из этого диапазона. Это позволяет выполнять их широковещательную в пределах приложения рассылку. Ни один из стандартных классов не откликнется на такое сообщение и не выполнит нежелательных действий.

    Упоминавшиеся ранее внутренние сообщения VCL с префиксами

    CM_
    и
    CN_
    имеют номера в диапазоне от 45 056 до 49 151, т.е. используют часть диапазона сообщений приложения. Таким образом, при использовании VCL диапазон сообщений приложения сокращается до
    WM_APP..45055
    . Сообщения оконного класса и приложения пригодны и для взаимодействия с другими приложениями, но при этом отправитель должен быть уверен, что адресат правильно его поймет. Широковещательная рассылка при этом исключена — реакция других приложений, которые также получат это сообщение, может быть непредсказуемой. Если все же необходимо рассылать широковещательные сообщения между приложениями, то следует воспользоваться глобальными сообщениями, для которых зарезервирован диапазон номеров от 49 152 до 65 535.

    Глобальное сообщение обязано иметь имя (именно поэтому такие сообщения называются также строковыми), под которым оно регистрируется в системе с помощью функции в 

    RegisterWindowMessage
    . Эта функция возвращает уникальный номер регистрируемого сообщения. Если сообщение с таким именем регистрируется впервые, номер выбирается из числа ещё не занятых. Если же сообщение с таким именем уже было зарегистрировано, то возвращается тот же самый номер, который был присвоен ему при первой регистрации. Таким образом, разные программы, регистрирующие сообщения с одинаковыми именами, получат одинаковые номера и смогут понимать друг друга. Для прочих же окон это сообщение не будет иметь никакого смысла. Создание и использование оконных сообщений демонстрируется примером NumBroadcast, содержащимся на прилагаемом компакт-диске. Разумеется, существует вероятность, что два разных приложения выберут для своих глобальных сообщений одинаковые имена, и это приведет к проблемам при широковещательной рассылке этих сообщений. Но, если давать своим сообщениям осмысленные имена, а не что-то вроде
    WM_MYMESSAGE1
    , вероятность такого совпадения будет очень мала. В особо критических ситуациях можно в качестве имени сообщения использовать GUID, уникальность которого гарантируется.

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

    WndProc
    или
    DefaultHandler
    .

    1.1.10. Особые сообщения

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

    Сообщение

    WM_COPYDATA
    служит для передачи блока данных от одного процесса к другому. В 32-разрядных версиях Windows память, выделенная некоторому процессу, недоступна для всех остальных процессов. Поэтому просто передать указатель другому процессу нельзя, поскольку он не сможет получить доступ к этой области памяти. При передаче сообщения
    WM_COPYDATA
    система копирует указанный блок из адресного пространства отправителя в адресное пространство получателя, передает получателю указатель на этот блок, и при завершении обработки сообщения освобождает блок. Все это требует определенной синхронности действий, которой невозможно достичь при посылке сообщения, поэтому с помощью
    WM_COPYDATA
    можно только отправлять, но не посылать (т.е. можно использовать
    SendMessage
    , но не
    PostMessage
    ).

    Сообщение

    WM_PAINT
    предназначено для перерисовки клиентской облаcти окна. Если изображение сложное, этот процесс занимает много времени, поэтому в Windows предусмотрены механизмы, минимизирующие количество перерисовок. Перерисовывать свое содержимое окно должно при получении сообщения
    WM_PAINT
    . С каждым таким сообщением связан регион, нуждающийся в обновлении. Этот регион может совпадать с клиентской областью окна или быть ее частью. В последнем случае программа может ускорить перерисовку, рисуя не все окно, а только нуждающуюся в этом часть (VCL игнорирует возможность перерисовки только части окна, поэтому при работе с этой библиотекой окно всегда перерисовывается полностью). Послать сообщение
    WM_PAINT
    с помощью
    PostMessage
    окну нельзя, т.к. оно не ставится в очередь. Вместо этого можно пометить регион как нуждающийся в обновлении с помощью функций
    InvalidateRect
    и
    InvalidateRgn
    . Если на момент вызова этих функций регион, который необходимо обновить, не был пуст, новый регион объединяется со старым. Функции
    GetMessage
    и
    PeekMessage
    , если очередь сообщений пуста, а регион, требующий обновления, не пуст, возвращают сообщение
    WM_PAINT
    . Таким образом, перерисовка окна откладывается до того момента, когда все остальные сообщения будут обработаны. Отправить
    WM_PAINT
    с помощью
    SendMessage
    тоже нельзя. Если требуется немедленная перерисовка окна, следует вызвать функции
    UpdateWindow
    или
    RedrawWindow
    , которые не только отправляют сообщение окну, но и выполняют сопутствующие действия, связанные с регионом обновления. Обработка сообщения
    WM_PAINT
    также имеет некоторые особенности. Обработчик должен получить контекст устройства окна (см. разд. 1.1.11 данной главы) с помощью функции
    BeginPaint
    и по окончании работы освободить его с помощью
    EndPaint
    . Эти функции должны вызываться только один раз при обработке сообщения. Соответственно, если сообщение обрабатывается поэтапно несколькими обработчиками, как это бывает при перехвате сообщений, получать и освобождать контекст устройства должен только первый из них, а остальные должны пользоваться тем контекстом, который он получил. Система не накладывает обязательных требований, которые могли бы решить проблему, но предлагает решение, которое используют все предопределенные системные классы. Когда сообщение
    WM_PAINT
    извлекается из очереди, его параметр
    wParam
    равен нулю. Если же обработчик получает сообщение с
    wParam <> 0
    , то он рассматривает значение этого параметра как дескриптор контекста устройства и использует его, вместо того чтобы получать дескриптор через
    BeginPaint
    . Первый в цепочке обработчиков должен передать вниз по цепочке сообщение с измененным параметром
    wParam
    . Компоненты VCL также пользуются этим решением. При перехвате сообщения
    WM_PAINT
    это нужно учитывать.

    Примеры PanelMsg и Line, имеющиеся на прилагаемом компакт-диске, демонстрируют, как правильно перехватывать сообщение

    WM_PAINT
    .

    Простые таймеры, создаваемые системой с помощью функции

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

    Примечание

    Класс

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

    Некоторую специфику имеют и сообщения от клавиатуры. При обработке таких сообщений можно использовать функцию

    GetKeуState
    , которая возвращает состояние любой клавиши (нажата-отпущена) в момент возникновения данного события. Именно в момент возникновения, а не в момент вызова функции. Если функцию
    GetKeyState
    использовать при обработке не клавиатурного сообщения, оно вернет состояние клавиши на момент последнего извлеченного из очереди клавиатурного сообщения.

    1.1.11. Графика в Windows API

    Та часть Windows API, которая служит для работы с графикой, обычно называется GDI (Graphic Device Interface). Ключевое понятие в GDI — контекст устройства (Device Context, DC). Контекст устройства — это специфический объект, хранящий информацию о возможностях устройства, о способе работы с ним и о разрешенной для изменения области. В Delphi контекст устройства представлен классом

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

    Большинство методов класса

    TCanvas
    являются "калькой" с соответствующих (в большинстве случаев одноименных) функций GDI. Но в некоторых случаях (прежде всего в методах вывода текста и рисования многоугольников) параметры методов
    TCanvas
    имеют более удобный тип, чем функции GDI. Например, метод
    TCanvas.Polygon
    требует в качестве параметра открытый массив элементов типа
    TPoint
    , а соответствующая функция GDI — указатель на область памяти, содержащую координаты точек, и число точек. Это означает, что до вызова функции следует выделить память, а потом — освободить ее. Еще нужен код, который заполнит эту область памяти требуемыми значениями. И ни в коем случае нельзя ошибаться в количестве элементов массива. Если зарезервировать память для одного числа точек, а при вызове функции указать другое, программа будет работать неправильно. Но для простых функций работа через GDI ничуть не сложнее, чем через
    TCanvas
    . Для получения дескриптора контекста устройства существует много функций. Только для того, чтобы получить дескриптор контекста обычного окна, существуют четыре функции:
    BeginPaint
    ,
    GetDC
    ,
    GetWindowDC
    и
    GetDCEx
    . Первая из них возвращает контекст клиентской области окна при обработке сообщения
    WM_PAINT
    . Вторая дает контекст клиентской области окна, который можно использовать в любой момент времени, а не только при обработке
    WM_PAINT
    . Третья позволяет получить контекст всего окна, вместе с неклиентской частью. Последняя же дает возможность получить контекст определенной области клиентской части окна.

    После того как дескриптор контекста получен, можно воспользоваться преимуществами класса

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

    Листинг 1.17. Использование класса
    TCanvas
    для работы с произвольным контекстом устройства

    var

     DC: HDC;

     Canvas: TCanvas;

    begin

     DC := GetDC(...); // Здесь возможны другие способы получения DC

     Canvas := TCanvas.Create;

     try

      Canvas.Handle := DC; // Здесь рисуем, используя Canvas

     finally

      Canvas.Free;

     end;

     // Освобождение объекта Canvas не означает освобождения контекста DC

     // DC необходимо удалить вручную

     ReleaseDC(DC);

    end;

    Использование класса

    TCanvas
    для рисования на контексте устройства, для которого имеется дескриптор, показано в примере PanelMsg на прилагающемся компакт-диске.

    Разумеется, можно вызывать функции GDI при работе через

    TCanvas
    . Для этого им просто нужно передать в качестве дескриптора контекста значение свойства
    Canvas.Handle
    . Коротко перечислим те возможности GDI, которые разработчики VCL почему-то не сочли нужным включать в
    TCanvas
    : работа с регионами и траекториями; выравнивание текста по любому углу или по центру; установка собственной координатной системы; получение детальной информации об устройстве; использование геометрических перьев; вывод текста под углом к горизонтали; расширенные возможности вывода текста; ряд возможностей по рисованию нескольких кривых и многоугольников одной функцией; поддержка режимов заливки. Доступ ко всем этим возможностям может быть осуществлен только через API. Отметим также, что Windows NT/2000/XP поддерживает больше графических функций, чем 9x/МЕ. Функции, которые не поддерживаются в 9x/ME, также не имеют аналогов среди методов TCanvas, иначе программы, написанные с использованием данного класса, нельзя было бы запустить в этих версиях Windows.

    GDI предоставляет очень интересные возможности по преобразованию координат, но только в Windows NT/2000/XP; в Windows 9x/ME они не поддерживаются. С помощью функции

    SetWorldTransform
    можно задать произвольную матрицу преобразования координат, и все дальнейшие графические операции будут работать в новой координатной системе. Матрица позволяет описать такие преобразования координат, как поворот, сдвиг начала координат и масштабирование, т.е. возможности открываются очень широкие. Также существует менее гибкая, но тоже полезная функция преобразования координат —
    SetMapMode
    , которая поддерживается во всех версиях Windows. С ее помощью можно установить такую систему координат, чтобы во всех функциях задавать координаты, например, в миллиметрах, а не пикселах. Это позволяет использовать один и тот же код для вывода на устройства с разными разрешениями.

    Некоторые возможности GDI, которым нет аналогов в

    TCanvas
    , демонстрируются примером GDI Draw.

    Для задания цвета в GDI предусмотрен тип

    COLORREF
    (в модуле Windows определен также его синоним для Delphi —
    TColorRef
    ). Это 4-байтное беззнаковое целое, старший байт которого определяет формат представления цвета. Если этот байт равен нулю (будем называть этот формат нулевым), первый, второй и третий байты представляют собой интенсивности красного, зеленого и синего цветов соответственно. Если старший байт равен 1, два младших байта хранят индекс цвета в текущей палитре устройства, третий байт не используется и должен быть равен нулю. Если старший байт равен 2, остальные байты, как и в нулевом формате, показывают интенсивность цветовых составляющих.

    Тип

    TColorRef
    позволяет менять глубину каждого цветового канала от 0 до 255, обеспечивая кодирование 16 777 216 различных оттенков (это соответствует режиму
    TrueColor
    ). Если цветовое разрешение устройства невелико, GDI подбирает ближайший возможный цвет из палитры. Если старший байт
    TColorRef
    равен нулю, цвет выбирается из текущей системной палитры (по умолчанию эта палитра содержит всего 20 цветов, поэтому результаты получаются далекими от совершенства). Если же старший байт равен 2, то GDI выбирает ближайший цвет из палитры устройства. В этом случае результаты получаются более приемлемыми. Если устройство имеет большую цветовую глубину и не задействует палитру, разницы между нулевым и вторым форматом
    COLORREF
    нет.

    Примечание

    Хотя режимы HighColor (32 768 или 65 536 цветов) не обладают достаточной цветовой глубиной, чтобы передать все возможные значения

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

    В Windows API определены макросы (а в модуле

    Windows
    , соответственно, одноименные функции)
    RGB
    ,
    PaletteIndex
    и
    PaletteRGB
    .
    RGB
    принимает три параметра — интенсивности красного, зеленого и синего компонентов и строит из них значение типа
    TColorRef
    нулевого формата.
    PaletteIndex
    принимает в качестве параметра номер цвета в палитре и на его основе конструирует значение первого формата. Макрос
    PaletteRGB
    эквивалентен
    RGB
    , за исключением того, что устанавливает старший байт возвращаемого значения равным двум. Для извлечения интенсивностей отдельных цветовых компонентов из значения типа
    TColorRef
    можно воспользоваться функциями
    GetRValue
    ,
    GetGValue
    и
    GetBValue
    .

    В системе определены два специальных значения цвета:

    CLR_NONE
    (
    $1FFFFFFF
    ) и
    CLR_DEFAULT
    (
    $20000000
    ). Они используются только в списках рисунков (image lists) для задания фонового и накладываемого цветов при выводе рисунка.
    CLR_NONE
    задаёт отсутствие фонового или накладываемого цвета (в этом случае соответствующий визуальный эффект не применяется).
    CLR_DEFAULT
    — установка цвета, заданного для всего списка.

    В VCL для передачи цвета предусмотрен тип

    TColor
    , определенный в модуле
    Graphics
    . Это 4-байтное число, множество значений которого является множеством значений типа
    TColorRef
    . К системным форматам 0, 1 и 2 добавлен формат 255. Если старший байт значения типа
    TColor
    равен 255, то младший байт интерпретируется как индекс системного цвета (второй и третий байт при этом не учитываются). Системные цвета — это цвета, используемые системой для рисования различных элементов интерфейса пользователя. Конкретные RGB-значения этих цветов зависят от версии Windows и от текущей цветовой схемы. RGB-значение системного цвета можно получить с помощью функции
    GetSysColor
    . 255-й формат TColor освобождает от необходимости явного вызова данной функции.

    Для типа TColor определен ряд констант, облегчающих его использование. Некоторые из них соответствуют определенному RGB-цвету (

    clWhite
    ,
    clBlack
    ,
    clRed
    и т.п.), другие — определенному системному цвету (
    clWindow
    ,
    clHighlight
    ,
    clBtnFace
    и т.п.). Значения RGB-цветов определены в нулевом формате. Это не приведет к потере точности цветопередачи в режимах с палитрой, т.к. константы определены только для 16-ти основных цветов, которые обязательно присутствуют в системной палитре. Значениям
    CLR_NONE
    и
    CLR_DEFAULT
    соответствуют константы
    clNone
    и
    clDefault
    . Они служат (помимо списков рисунков) для задания прозрачного цвета в растровом изображении. Если этот цвет равен
    clNone
    , изображение считается непрозрачным, если
    clDefault
    , в качестве прозрачного цвета берется цвет левого нижнего пиксела.

    Везде, где требуется значение типа TColor, можно подставлять

    TColorRef
    , т.е. всем свойствам и параметрам методов класса
    TCanvas
    , имеющим тип
    TColor
    можно присваивать те значения
    TColorRef
    , которые сформированы функциями API. Обратное неверно: API-функции не умеют обращаться с 255-м форматом
    TColor
    . Преобразование из
    TColor
    в
    TColorRef
    осуществляется с помощью функции
    ColorToRGB
    . Значения нулевого, первого и второго формата, а также
    clNone
    и
    clDefault
    она оставляет без изменения, а значения 255-го формата приводит к нулевому с помощью функции
    GetSysColor
    . Эту функцию следует использовать при передаче значении типа
    TColor
    в функции GDI.

    Применение кистей, перьев и шрифтов в GDI принципиально отличается от того, как это делается в VCL. Класс

    TCanvas
    имеет свойства
    Pen
    ,
    Brush
    , и
    Font
    , изменение свойств которых приводит к выбору того или иного пера, кисти, шрифта. В GDI эти объекты самостоятельны, должны создаваться, получать свой дескриптор, "выбираться" в нужный контекст устройства с помощью функции
    SelectObject
    и уничтожаться после использования. Причем удалять можно только те объекты, которые не выбраны ни в одном контексте. Есть также несколько стандартных объектов, которые не нужно ни создавать, ни удалять. Их дескрипторы можно получить с помощью функции
    GetStockObject
    . Для примера рассмотрим фрагмент программы, рисующей на контексте с дескриптором DC две линии: синюю и красную (листинг 1.18). В этом фрагменте используется то, что функция
    SelectObject
    возвращает дескриптор объекта, родственного выбираемому, который был выбран ранее. Так, при выборе нового пера она вернет дескриптор того пера, которое было выбрано до этого.

    Листинг 1.18. Рисование разными перьями с использованием GDI

    SelectObject(DC, CreatePen(PS_SOLID, 1, RGB(255, 0, 0)));

    MoveToEx(DC, 100, 100, nil);

    LineTo(DC, 200, 200);

    DeleteObject(SelectObject(DC, CreatePen(PS_SOLID, 1, RGB(0, 0, 255))));

    MoveToEx(DC, 200, 100, nil);

    LineTo(DC, 100, 200);

    DeleteObject(SelectObject(DC, SetStockObject(BLACK_PEN)));

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

    Для хранения растровых изображений в Windows существуют три формата: DDB, DIB и DIB-секция. DDB — это Device Dependent Format, формат, определяемый графическим устройством, на которое идет вывод. DIB — это Device Independent Bitmap, формат, единый для всех устройств. Формат DIB — это устаревший формат, который не позволяет использовать графические функции GDI для модификации картинки, модифицировать изображение можно, только одним способом: вручную изменяя цвета отдельных пикселов. В 32-разрядных версиях появился еще один формат — DIB-секция. По сути дела это тот же самый DIB, но дополненный возможностями рисовать на нем с помощью GDI-функций. Все различия между этими тремя форматами можно прочитать в замечательной книге [1]; мы же здесь ограничимся только кратким их обзором.

    Формат DDB поддерживается самой видеокартой (или другим устройством вывода), поэтому при операциях с таким изображением задействуется аппаратный ускоритель графики. DDB-изображение хранится в выгружаемом системном пуле памяти (Windows NT/2000/XP) или в куче GDI (Windows 9x/ME). При этом размер DDB-растра не может превышать 16 Мбайт в Windows 9x/ME и 48 Мбайт в Windows NT/2000/XP. Формат DDB не переносим с одного устройства на другое, он должен использоваться только в рамках одного устройства. Прямой доступ к изображению и его модификация вручную невозможны, т.к. формат хранения изображения конкретным устройством непредсказуем. Модифицировать DDB можно только с помощью функций GDI. Цветовая глубина DDB-изображений определяется устройством.

    DIB-секция может храниться в любой области памяти, ее размер ограничивается только размером доступной приложению памяти, функции GDI для рисования на таком изображении используют чисто программные алгоритмы, никак не задействуя аппаратный ускоритель. DIB-секция поддерживает различную цветовую глубину и прямой доступ к области памяти, в которой хранится изображение. DIB-секция переносима с одного устройства на другое. BMP-файлы хранят изображение как DIB.

    Скорость работы с изображением в формате DIB-секции зависит только от производительности процессора, памяти и качества реализации графических алгоритмов системой (а они, надо сказать, реализованы в Windows очень неплохо). Скорость работы с изображением в формате DDB зависит еще и от драйвера и аппаратного ускорителя видеокарты. Во-первых, аппаратный ускоритель и драйвер могут поддерживать или не поддерживать рисование графических примитивов (в последнем случае эти примитивы рисует система: то, какие операции поддерживает драйвер, можно узнать с помощью функции

    GetDeviceCaps
    ). До недавнего времени была характерной ситуация, когда рисование картинки на DDB-растре и вывод такого растра на экран были заметно (иногда — в два-три раза) быстрее, чем аналогичные операции с DIB-секцией. Однако сейчас разница стала существенно меньше, производительность системы в целом выросла сильнее, чем производительность двумерных аппаратных ускорителей (видимо, разработчики видеокарт больше не считают двумерную графику узким местом и поэтому сосредоточили свои усилия на развитии аппаратных ускорителей 3D-графики). На некоторых мощных компьютерах можно даже столкнуться с ситуацией, когда DDB-изображение отстает по скорости от DIB.

    Класс

    TBitmap
    может хранить изображение как в виде DDB, так и в виде DIB- секции — это определяется значением свойства
    PixelFormat
    . Значение
    pfDevice
    означает использование DDB, остальные значения — DIB-секции с различной цветовой глубиной. По умолчанию
    TBitmap
    создает изображение с форматом
    pfDevice
    , но программист может изменить формат в любой момент. При этом создается новое изображение требуемого формата, старое копируется в него и уничтожается.

    Со свойством

    PixelFormat
    тесно связано свойство
    HandleType
    , которое может принимать значения
    bmDIB
    и
    bmDDB
    . Изменение свойства
    PixelFormat
    приводит к изменению свойства
    HandleType
    , и наоборот.

    Примечание

    Если вы собираетесь распечатывать изображение, содержащееся в

    TBitmap
    , то вы должны установкой свойств
    PixelFormat
    или
    HandleType
    обеспечить, чтобы изображение хранилось в формате DIB. Попытка вывести DDB-изображение на принтер приводит к непредсказуемым результатам (чаще всего просто ничего не выводится) из-за того, что драйвер принтера не понимает формат, совместимый с видеокартой.

    При загрузке изображения из файла, ресурса или потока класс

    TBitmap
    обычно создает изображение в формате DIB-секции, соответствующее источнику по цветовой глубине. Исключение составляют сжатые файлы (формат BMP поддерживает сжатие только для 16- и 256-цветных изображений) — в этом случае создается DDB. В файле
    Graphics
    определена глобальная переменная
    DDBsOnly
    , которая по умолчанию равна
    False
    . Если изменить ее значение на
    True
    , загружаемое изображение всегда будет иметь формат DDB.

    Примечание

    В справке сказано, что когда

    DDBsOnly = False
    , вновь создаваемые изображения по умолчанию хранятся в виде DIB-секций. На самом деле из-за ошибки в модуле
    Graphics
    (как минимум до 2007-й версии Delphi включительно) вновь созданное изображение всегда хранится как DDB независимо от значения
    DDBsOnly
    .

    Класс

    TBitmap
    имеет свойство
    ScanLine
    , через которое можно получить прямой доступ к массиву пикселов, составляющих изображение. В справке написано, что это свойство можно использовать только с DIB-изображениями. Но на самом деле DDB-изображения тоже позволяют использовать это свойство, хотя и с существенными ограничениями. Если изображение хранится в DDB- формате, при обращении к 
    ScanLine
    создастся его DIB-копия, и
    ScanLine
    возвращает указатель на массив этой копии. Поэтому, во-первых,
    ScanLine
    работает с DDB-изображениями очень медленно, а во-вторых, работает не с изображением, а с его копией, откуда вытекают следующие ограничения:

    1. Копия создаётся на момент обращения к

    ScanLine
    , поэтому изменения, сделанные на изображении с помощью GDI-функций после этого, будут недоступными.

    2. Каждое обращение к

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

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

    ScanLine
    дает возможность прочитать, но не изменить изображение.

    Следует отметить, что

    TBitmap
    иногда создает DIB-секции, даже если свойства
    HandleType
    и
    PixelFormat
    явно указывают на использование DDB. Особенно часто это наблюдается для изображений большого размера. По всей видимости, это происходит, когда в системном пуле нет места для хранения DDB-изображения такого размера, и разработчики TBitmap решили, что в таком случае лучше создать DIB-изображение, чем не создавать никакого. Пример
    BitmapSpeed
    на прилагаемом компакт-диске позволяет сравнить скорость выполнения различных операций с DDB- и DIB-изображениями.

    1.1.12. ANSI и Unicode

    Windows поддерживает две кодировки: ANSI и Unicode. В кодировке ANSI (American National Standard Institute) каждый символ кодируется однобайтным кодом. Коды от 0 до 127 совпадают с кодами ASCII, коды от 128 до 255 могут означать разные символы различных языков в зависимости от выбранной кодовой страницы. Кодовые страницы позволяют уместить многочисленные символы различных языков в однобайтный код, но при этом можно работать только с одной кодовой страницей, т.е. с одним языком. Неверно выбранная кодовая страница приводит к появлению непонятных символов (в Интернете их обычно называют "кракозябрами") вместо осмысленного текста.

    В кодировке Unicode используется 2 байта на символ, что даёт возможность закодировать 65 536 символов. Этого хватает для символов латиницы и кириллицы, греческого алфавита, китайских иероглифов, арабских и еврейских букв, а также многочисленных дополнительных (финансовых, математических и т. п.) символов. Кодовых страниц в Unicode нет.

    Примечание

    Кодовая страница русского языка в ANSI имеет номер 1251. Кодировка символов в ней отличается от принятой в DOS так называемой альтернативной кодировки. В целях совместимости для DOS-программ, а также для консольных приложений Windows использует альтернативную кодировку. Именно поэтому при выводе русского текста в консольных приложениях получаются те самые "кракозябры". Чтобы избежать этого, следует перекодировать символы из кодировки ANSI в DOS при выводе, и наоборот — при вводе. Это можно сделать с помощью функций

    CharToOem
    и
    OemToChar
    .

    Windows NT/2000/XP поддерживает ANSI и Unicode в полном объеме. Это значит, что любая функция, работающая со строками, представлена в двух вариантах: для ANSI и для Unicode. Windows 9x/МЕ в полном объеме поддерживает только ANSI. Unicode-варианты в этих системах есть у относительно небольшого числа функций. Каждая страница MSDN, посвященная функции, работающей со строками (или со структурами, содержащими строки), в нижней части содержит надпись, показывающую, реализован ли Unicode-вариант этой функции только для NT/2000/XP или для всех платформ.

    Примечание

    В качестве примера рассмотрим функции вывода текста на экран. Unicode-версию на всех платформах имеют только две из них

    TextOut
    и
    ExtTextOut
    . Функции
    DrawText
    и
    DrawTextEx
    имеют Unicode-варианты только в Windows NT/2000/XP. Если же смотреть функции для работы с окнами, то среди них нет ни одной, которая имела бы Unicode-вариант в Windows 9х/МЕ. Следует отметить, что с относительно недавнего времени Microsoft предоставляет расширение для Windows 9x/МЕ которое позволяет добавить полную поддержку Unicode в эти системы. Это расширение называется MSLU (Microsoft Layer for Unicode), его можно скачать с официального сайта Microsoft.

    Рассмотрим, как сосуществуют два варианта на примере функции

    RegisterWindowMessage
    . Согласно справке, она экспортируется библиотекой user32.dll. Однако если посмотреть список функций, экспортируемых этой библиотекой (это можно сделать, например, при помощи утилиты TDump.exe, входящей в состав Delphi), то там этой функции не будет, зато будут функции
    RegisterWindowMessageA
    и
    RegisterWindowMessageW
    . Первая из них — это ANSI-вариант функции, вторая — Unicode-вариант (буква W означает Wide — широкий; символы кодировки Unicode часто называются широкими из-за того, что на один символ приходится не один, а два байта).

    Сначала разберемся с тем, как используются два варианта одной функции в Microsoft Visual C++. В стандартных заголовочных файлах учитывается наличие макроопределения

    UNICODE
    . Есть два символьных типа —
    CHAR
    для ANSI и
    WCHAR
    для Unicode. Если макрос
    UNICODE
    определен, тип
    TCHAR
    соответствует типу
    WCHAR
    , если не определен — типу
    CHAR
    (после этого производные от
    TCHAR
    типы, такие как
    LPCTSTR
    автоматически начинают соответствовать кодировке, определяемой наличием или отсутствием определения
    UNICODE
    ). В заголовочных файлах импортируются оба варианта функции, а также определяется макрос
    RegisterWindowMessage
    . Его смысл также зависит от макроса
    UNICODE
    : если он определен,
    RegisterWindowMessage
    эквивалентен
    RegisterWindowMessageW
    , если не определен —
    RegisterWindowMessageA
    . Все функции, поддерживающие два варианта кодировки, импортируются точно так же. Таким образом, вставляя или убирая макроопределение
    UNICODE
    , можно, не меняя ни единого символа в программе, компилировать ее ANSI- или Unicode-версию.

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

    TCHAR
    .

    Рассмотрим, как та же функция

    RegisterWindowMessage
    импортируется модулем Windows (листинг 1.19).

    Листинг 1.19. Импорт функции
    RegisterWindowMessage

    interface

    ...

    function RegisterWindowMessage(lpString: PChar): UINT; stdcall;

    function RegisterWindowMessageA(lpString: PAnsiChar): UINT;

    stdcall; function RegisterWindowMessageW(lpString: PWideChar): UINT; stdcall;

    ...

    implementation

    ...

    function RegisterWindowMessage;

     external user32 name 'RegisterWindowMessageA';

    function RegisterWindowMessageA;

     external user32 name 'RegisterWindowMessageA';

    function RegisterWindowMessageW;

     external user32 name 'RegisterWindowMessageW';

    Видно, что функция

    RegisterWindowMessageA
    импортируется дважды: один раз под своим настоящим именем, а второй раз — под именем
    RegisterWindowMessage
    . Любое из этих имен подходит для вызова ANSI-варианта этой функции (напоминаю, что типы
    PChar
    и
    PAnsiChar
    эквивалентны). Чтобы вызвать Unicode-вариант функции, потребуется функция
    RegisterWindowMessageW
    .

    Структуры, содержащие строковые данные, также имеют ANSI- и Unicode-вариант. Например, структура

    WNDCLASS
    в модуле Windows представлена типами
    TWndClassA
    (с синонимами
    WNDCLASSA
    и
    tagWNDCLASSA
    ) и
    TWndClassW
    (с синонимами
    WNDCLASSW
    и
    tagWHDCLASSW
    ). Тип
    TWndClass
    (и его синонимы
    WNDCLASS
    и
    tagWNDCLASS
    ) эквивалентен типу
    TWndClassA
    . Соответственно, при вызове функций
    RegisterClassA
    и
    RegisterClassExA
    используется тип
    TWndClassA
    , при вызове
    RegisterClassW
    и
    RegisterClassExW
    — тип
    TWndClassW
    .

    1.1.13. Строки в Windows API

    Unicode в Delphi встречается редко, т.к. программы, использующие эту кодировку, не работают в Windows 9x/МЕ. Библиотека VCL также игнорирует возможность работы с Unicode, ограничиваясь ANSI. Поэтому далее мы будем говорить только об ANSI. С кодировкой Unicode можно работать аналогично, заменив

    PChar
    на
    PWideChar
    и
    string
    на
    WideString
    .

    Для работы со строками в Delphi наиболее распространен тип

    AnsiString
    , обычно называемый просто
    string
    (более детально отношения между этими типами рассмотрены в главе 3). Переменная типа
    string
    является указателем на строку, хранящуюся в динамической памяти. Этот указатель указывает на первый символ строки. По отрицательному смещению хранится число символов в строке и счетчик ссылок, который позволяет избежать ненужных копирований строки, реализуя так называемое "копирование при необходимости". Если присвоить одной строковой переменной значение другой строковой переменной, то строка не копируется, а просто обе переменные начинают указывать на одну и ту же строку. Счетчик ссылок при этом увеличивается на единицу. Когда строка модифицируется, проверяется счетчик ссылок: если он не равен единице, то строка копируется, счетчик ссылок старой копии уменьшается на единицу, у новой копии счетчик ссылок будет равен единице, и переменная, которая меняется, будет указывать на новую копию. Таким образом, строка копируется только тогда, когда одна из ссылающихся на нее переменных начинает изменять эту строку, чтобы изменения не коснулись остальных переменных. При любых модификациях строки в ее конец автоматически добавляется нулевой символ (при подсчете длины строки с помощью функции
    Length
    он игнорируется). Но если присвоить строковой переменной пустую строку, то эта переменная станет нулевым указателем (
    nil
    ), память для хранения одного символа #0 выделена не будет. При выходе строковой переменной из области видимости (т. е., например, при завершении процедуры, в которой она является локальной переменной, или при уничтожении объекта, полем которого она является) она автоматически финализируется, т.е. счетчик ссылок уменьшается на единицу и, если он оказывается равен нулю, память, выделенная для строки, освобождается. (О внутреннем устройстве
    AnsiString
    см. также разд. 3.3.)

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

    Примечание

    В отличие от

    string
    , тип
    WideString
    не имеет счетчика ссылок, и любое присваивание переменных этого типа приводит к копированию строки. Это сделано в целях совместимости с системным типом
    BSTR
    , использующимся в COM/DCOM и OLE. 

    Функции Windows API не поддерживают тип

    string
    . Они работают со строками, оканчивающимися на
    #0
    (нуль-терминированные строки, null-terminated strings). Это означает, что строкой называется указатель на цепочку символов. Признаком конца такой цепочки является символ с кодом 0. Раньше для таких строк существовал термин ASCIIZ. ASCII — название кодировки, Z — zero. Сейчас кодировка ASCII в чистом виде не встречается, поэтому этот термин больше не применяется, хотя это те же самые по своей сути строки. Как уже говорилось, в Delphi ко всем строкам типа
    string
    неявно добавляется нулевой символ, не учитывающийся при подсчете числа символов. Это сделано для совместимости с нуль-терминированными строками. Однако эта совместимость ограничена.

    Для работы с нуль-терминированными строками в Delphi обычно служит тип

    PChar
    . Формально это указатель на один символ типа
    Char
    , но подразумевается, что это только первый символ строки, и за ним следуют остальные символы. Где будут эти символы размещены и какими средствами для них будет выделена память, программист должен решить самостоятельно. Он же должен позаботиться о том, чтобы в конце цепочки символов стоял
    #0
    .

    Строку, на которую указывает

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

    Если посмотреть описание функций API, имеющих строковые параметры, в справке, можно заметить, что в некоторых случаях строковые параметры имеют тип

    LPCTSTR
    (как, например, у функции
    SetWindowText
    ), а в некоторых —
    LPTSTR
    (
    GetWindowText
    ). Ранее мы говорили, что появление префикса
    C
    после
    LP
    указывает на то, что это указатель на константу, т.е. то, на что указывает такой указатель, не может быть изменено. Тип
    LPCTSTR
    имеют те строковые параметры, содержимое которых функция только читает, но не модифицирует. С такими параметрами работать проще всего. Рассмотрим на примере функции
    SetWindowText
    , как можно работать с такими параметрами (листинг 1.20).

    Листинг 1.20. Вызов функции с параметром типа
    LPCTSTR

    { Вариант 1 }

    SetWindowText(Handle, 'Строка');


    { Вариант 2

     S -переменная типа string }

    SetWindowText(PChar(S));


    { Вариант 3

     X - переменная типа Integer }

     SetWindowText(PChar('Выполнено ' + IntToStr(X) + '%'));

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

    Во втором варианте функции передается указатель, хранящийся в переменной

    S
    . Такое приведение
    string
    к
    PChar
    безопасно, т.к. строка, на которую ссылается переменная
    S
    , не будет модифицироваться. Но здесь существует одна тонкость: конструкция
    PChar(S)
    — это не просто приведение типов, при ее использовании неявно вызывается функция
    _LStrToPChar
    . Как мы уже говорили, когда
    string
    хранит пустую строку, указатель просто имеет
    значение
    nil. Функция
    _LStrToPChar
    проверяет, пустая ли строка хранится в переменной, и, если не пустая, возвращает этот указатель, а если пустая, то возвращает не
    nil
    , а указатель на символ
    #0
    , который специально для этого размещен в сегменте кода. Поэтому даже если содержит пустую строку, в функцию будет передан ненулевой указатель.

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

    string
    . Но его можно привести к
    PChar
    . Память для хранения результата выражения выделяется динамически, как и для обычных переменных типа string. Чтобы передать указатель на но выражение в функцию, следует привести его к
    PChar
    . В эпилог процедуры, вызывающей функцию
    SetWindowText
    или иную функцию с подобным аргументом, добавляется код, который освобождает динамически сформированную строку, поэтому утечек памяти не происходит. Разумеется, существуют и другие способы формирования параметра типа
    LPCTSTR
    , кроме предложенных здесь. Можно, например, выделить память для нуль-терминированной строки с помощью
    StrNew
    или родственной ей функции из модуля
    SysUtils
    . Можно использовать массив типа
    Char
    . Можно выделять память какими-либо другими способами. Но предложенные здесь три варианта в большинстве случаев наиболее удобны.

    Параметры типа

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

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

    GetWindowText
    размер этого заголовка можно узнать, вызвав предварительно
    GetWindowTextLength
    . Функции типа
    GetCurrentDirectory
    возвращают длину строки. Если при первом вызове этой функции памяти выделено недостаточно, можно увеличить буфер и вызвать функцию еще раз. И наконец, есть функции типа
    SHGetSpecialFolderPath
    , в описании которых написано, каков минимальный размер буфера, необходимый для гарантированной передачи полной строки этой функцией (это, разумеется, возможно только в том случае, когда размер возвращаемой строки имеет какое-то естественное ограничение). Следует также отметить, что большинство API-функций, возвращающих строки, в качестве одного из параметров принимают размер буфера, чтобы не скопировать больше байтов, чем буфер может принять.

    Выделять буфер для получения строки можно многими способами. На практике удобнее всего статические массивы, тип

    string
    или динамическое выделение памяти для нуль-терминированных строк.

    Статические массивы могут использоваться, если размер буфера известен на этапе компиляции. Массивы типа

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

    Строки типа

    string
    также могут служить буфером для получения строковых значений от системы. Для этого нужно предварительно установить требуемую длину строки с помощью
    SetLength
    , а затем передать указатель на начало строки в функцию API. Здесь следует соблюдать осторожность: если длина строки окажется равной нулю, переменная типа
    string
    будет иметь значение
    nil
    , а система попытается записать по этому указателю пустую строку, состоящую из единственного символа
    #0
    . Это приведет к ошибке Access violation.

    Третий способ — выделение памяти для буфера с помощью

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

    Все три способа получения строковых данных от функций Windows API показаны в примере

    EnumWnd
    , находящемся на прилагаемом компакт-диске.

    1.2. Примеры использования Windows API

    В этом разделе разобраны простые примеры, находящиеся на компакт-диске. Все эти примеры уже упоминались ранее, и каждый из них иллюстрирует какую-то отдельно взятую возможность API. Более сложным обобщающим примерам, которые задействуют сразу несколько возможностей API и VCL, посвящен следующий, третий раздел данной главы.

    1.2.1. Пример EnumWnd

    Программа EnumWnd представляет собой простой пример использования функций

    EnumWindows
    и
    EnumChildWindows
    , а также функций обратного вызова, которые необходимы для работы этих двух функций. Программа ищет все окна, созданные на данный момент в системе, и отображает их в виде дерева: каждый узел дерева соответствует одному окну, дочерние узлы соответствуют дочерним окнам данного окна (рис. 1.8).

    Программа EnumWnd является также примером того, как можно работать с параметрами типа LPTSTR, через которые функции Windows API возвращают программе строковые значения. В разд. 1.1.13 были перечислены три способа создания буфера для работы с такими параметрами: выделение памяти в стеке в виде массива элементов типа

    Char
    , использование строк типа
    string
    и строк типа
    PChar
    . Все три способа реализованы в примере
    EnumWnd
    . На главной и единственной форме программы
    EnumWnd
    размещены два компонента:
    TreeWindow
    типа
    TTreeView
    и кнопка
    BtnBuild
    . Обработчик нажатия кнопки выглядит очень лаконично (листинг 1.21).

    Листинг 1.21. Обработчик нажатия кнопки
    BtnBuild

    procedure TFomWindows.BtnBuildClick(Sender: TObject);

    begin

     Screen.Cursor := crHourGlass;

     try

      TreeWindows.Items.Clear;

      EnumWindows(@EnumWindowsProc, 0);

     finally

      Screen.Cursor := crDefault;

     end;

    end;

    Рис. 1.8. Окно программы EnumWnd


    Все, что делает этот обработчик, — это очищает компонент

    TreeWindows
    и вызывает
    EnumWindows
    , передавая ей функцию обратного вызова
    EnumWindowsProc
    , в которой и выполняется основная работа. Сразу отметим, что в этом примере мы будем использовать одну и ту же функцию обратного вызова как для
    EnumWindows
    , так и для
    EnumWindowsProc
    . Сама функция обратного вызова выглядит следующим образом (листинг 1.22).

    Листинг 1.22. Функция обратного вызова
    EnumWindowsProc
    (первый вариант)

    // Это функция обратного вызова, которая будет

    // использоваться при вызове EnumWindows и EnumChildWindows.

    // Тип второго параметра не совпадает с типом, который

    // указан MSDN. Однако TTreeNode, как и любой класс,

    // является указателем, поэтому может использоваться везде,

    // где требуется нетипизированный указатель - на двоичном

    // уровне между ними нет разницы. Указатель на функцию

    // обратного вызова в EnumWindows и EnumChildWindows в

    // модуле Windows.dcu объявлен как нетипизированный

    // указатель, поэтому компилятор не контролирует

    // соответствие реального прототипа заявленному.

    function EnumWindowsProc(Wnd: HWND; ParentNode: TTreeNode): Bool; stdcall;

     // Система не предусматривает возможности узнать, какова

     // длина имени класса, поэтому при получении этого имени

     // приходится выделять буфер большой длины в надежде, что

     // имя класса не окажется еще длиннее. В данном примере

     // размер этого буфера определяется константой ClassNameLen.

     // Крайне маловероятно, что имя класса скажется длиннее,

     // чем 511 символов (512-й зарезервирован для завершающего

     // нулевого символа).

    const

     ClassNameLen = 512;


    var

     // Здесь будет храниться заголовок окна

     Text: string;

     TextLen: Integer;

     // Это - буфер для имени класса

     ClassName: array[0..ClassNameLen - 1] of Char;

     Node: TTreeNode;

     NodeName: string;

    begin

     Result := True;

     // Функция EnumChildWindows  перечисляет не только

     // непосредственно дочерние окна данного окна, но и

     // дочерние окна его дочерних окон и т.п. Но при

     // построении дерева на каждом шаге нам нужны только

     // прямые потомки, поэтому все окна, не являющиеся прямыми

     // потомками, мы здесь игнорируем.

     if Assigned(ParentNode) and (GetParent(Wnd) <> HWND(ParentNode.Data)) then Exit;

     // Получаем длину заголовка окна. Вместо функций

     // GetWindowText и GetWindowTextLength мы здесь

     // используем сообщения WM_GETTEXT и WM_GETTEXTLENGTH,

     // потому что функции, в отличие от сообщений, не

     // умеют работать с элементами управления,

     // принадлежащими окнам чужих процессов.

     TextLen := SendMessage(Wnd, WM_GETTEXTLENGTH, 0, 0);

     // Устанавливаем длину строковой переменной, которая

     // будет служить буфером для заголовка окна.

     // Использование SetLength гарантирует, что будет

     // выделена специальная область памяти, на которую не

     // будет других ссылок.

     SetLength(Text, TextLen);

     // Если заголовок окна - пустая строка, TextLen будет

     // иметь значение 0, и указатель Text при выполнении

     // Set Length получит значение nil. Но при обработке

     // сообщения WM_GETTEXT оконная процедура в любом случае

     // попытается записать строку по переданному адресу,

     // даже если заголовок окна пустой - в этом случае в

     // переданный буфер будет записан один символ -

     // завершающий ноль. Но если будет передан nil, то

     // попытка записать что-то в такой буфер приведет к

     // Access violation, поэтому отправлять окну WM_GETTEXT

     // можно только в том случае, если TextLen > 0.

     if TextLen > 0 then

      SendMessage(Wnd, WM_GETTEXT, TextLen + 1, LParam (Text));

     // Заголовок окна может быть очень длинным - например, в

     // Memo заголовком считается весь текст, который там

     // есть. Практика показывает, что существуют проблемы

     // при добавлении в TTreeView узлов с очень длинным

     // названиями: при попытке открыть такой узел программа,

     // запущенная из Delphi, вылетает в отладчик (при

     // запуске вне среды Delphi проблем не замечено). Чтобы

     // этого не происходило, слишком длинные строки

     // обрезаются.

     if TextLen > 100 then

      Text := Copy(Text, 1, 100) + '...';

     GetClassName(Wnd, ClassName, ClassNameLen);

     ClassName[ClassNameLen - 1] := #0;

     if Text = '' then NodeName := 'Без названия (' + ClassName + ') '

     else NodeName := Text + ' (' + ClassName + ')';

     Node := FormWindows.TreeWindows.Items.AddChild(ParentNode, NodeName);

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

     // ему окна, чтобы иметь возможность отбросить непрямые

     // потомки.

     Node.Data := Pointer(Wnd);

     // Вызываем EnumChildWindows, передавая функцию

     // EnumWindowsProc в качестве параметра, а указатель на

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

     // При этом EnumWindowsProc будет вызываться из

     // EnumChildWindows, т.е. получается рекурсия.

     EnumChildWindows(Wnd, @EnumWindowsProc, LParam(Mode));

    end;

    Как мы помним, первый параметр функции обратного вызова для

    EnumWindows
    содержит дескриптор найденного окна, а второй параметр может быть произвольным 4-байтным значением, которое система игнорирует, просто копируя сюда то значение, которое было передано при вызове
    EnumWindows
    или
    EnumChildWindows
    . Мы задействуем этот параметр для передачи ссылки на узел дерева, соответствующий родительскому окну. Также договоримся, что в свойство Data каждого узла будем записывать дескриптор связанного с ним окна. Для окон верхнего уровня ссылка будет иметь значение
    nil
    — это обеспечивается тем, что при вызове EnumWindows второй параметр равен нулю (см. листинг 1.21).

    Работа функции начинается с проверки того, что родительским окном для данного окна действительно является то окно, чей дескриптор связан с узлом родительского окна. Эта проверка нужна потому, что функция

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

    Следующий шаг — получение заготовка окна. Для этого мы используем сообщение

    WM_GETTEXT
    (разница между этим сообщением и функцией
    GetWindowText
    обсуждается в разд. 1.3.1). Буфером является переменная
    Text
    типа
    string
    . Сначала с помощью сообщения
    WM_GETTEXTLENGTH
    мы узнаем длину заголовка окна, а затем выделяем под строку
    Text
    требуемое количество памяти с помощью
    SetLength
    . После этого можно получить строку с помощью сообщения
    WM_GETTEXT
    . Второй параметр этого сообщения — адрес буфера, в который будет помещена строка. Так как переменная типа
    string
    и есть указатель на буфер строки (это детально обсуждается в разд. 3.3), достаточно просто привести переменную
    Text
    к типу
    LParam
    и передать получившееся значение.

    Примечание

    Строго говоря, у нас здесь нигде нет параметра типа

    LPTSTR
    , однако при работе с параметрами этого типа можно действовать точно так же: выделить для строки типа string нужное количество памяти и передать эту переменную, приведенную к типу
    LPTSTR
    , в качестве параметра.

    Далее получаем название класса окна. Для этого мы используем статический массив

    ClassName
    , т.е. размер буфера определяется на этапе компиляции. С одной стороны, это неправильно, потому что ограничений на длину имени класса не существует (по крайней мере, в документации они не упомянуты), а мы уже говорили, что такой метод следует применять только тогда, когда существует известное на этапе компиляции ограничение длины. По с другой стороны, когда речь идет об имени класса, не существует ничего подобного сообщению
    WM_SETTEXTLENGTH
    , т.е. API не дает возможности получить длину имени класса, что делает бессмысленными все манипуляции с размером буфера во время работы программы. Поэтому мы определяем размер буфера еще на этапе компиляции, исходя из того, что слишком уж длинные имена классов встречаются редко. При вызове функции с параметром типа
    LPTSTR
    можно просто передавать массив без приведения типа, т.к.
    LPTSTR
    — это
    PChar
    , а массивы символов
    Char
    , индексирующиеся с нуля, компилятор полагает совместимыми с этим типом и все необходимые преобразования делает неявно.

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

    #0
    не попадет в буфер, и при попытке дальше работать с этой строкой какая-нибудь другая функция может, не найдя конца строки в пределах буфера, попытаться поискать этот конец за его пределами, что приведет к непредсказуемым результатам. Поэтому на всякий случай записываем
    #0
    в последний символ буфера. Если имя класса оказалось длиннее буфера, это обрежет строку по границе буфера, а если короче, то это ничему не повредит, т.к. признак конца строки будет в буфере где-то раньше, а все символы после него все равно игнорируются. После этого остается только создать новый элемент в дереве, а чтобы заполнить его дочерние элементы — вызвать
    EnumChildWindows
    для получения списка дочерних окон. Так как в
    EnumChildWindows
    передается та же функция обратного вызова, получается рекурсия, которая останавливается тогда, когда функция доходит до окна, не имеющего дочерних окон. Ранее мы говорили, что программа
    EnumWnd
    демонстрирует три метода получения строки через параметр типа
    LPTSTR
    , но пока мы увидели только два (действительно, трудно показать три различных метода на примере получения двух строк). Чтобы показать третий вариант — организацию буфера через строки типа
    PChar
    — перепишем функцию
    EnumWindowsProc
    (листинг 1.23). В исходном коде программы
    EnumWnd
    этот вариант присутствует в виде комментария. Можно убрать этот комментарий, а закомментировать, наоборот, первый вариант, чтобы попробовать, как работает получение строки с помощью
    PChar
    .

    Листинг 1.23. Функция обратного вызова
    EnumWindowsProc
    (второй вариант)

    // Ниже приведен другой вариант функции

    // EnumWindowsРrос, который отличается от предыдущего тем,

    // что буфер для получения заголовка окна организуется

    // вручную с помощью переменной типа PChar, а не string. По

    // своим функциональным возможностям оба варианта равноценны.

    function EnumWindowsProc(Wnd: HWND; ParentNode: TTreeNode): Bool; stdcall;

    const

     ClassNameLen = 512;

    var

     TextLen: Integer;

     Text: PChar;

     ClassName: array[0..ClassNameLen - 1] of Char;

     Node: TTreeNode;

     NodeName: string;

    begin

     Result := True;

     if Assigned(ParentNode) and (GetParent(Wnd) <> HWND(ParentNode.Data)) then Exit;

     // Здесь, в отличие от предыдущего варианта к длине,

     // получаемой через WM_GETTEXTLENGTH, добавляется

     // единица, потому что нужно вручную учесть добавочный

     // байт для завершающего нуля.

     TextLen := SendMessage(Wnd, WM_GETTEXTLENGTH, 0, 0) + 1;

     // Выделяем требуемое количество памяти. Так как

     // компилятор не освободит эту памяти автоматически,

     // необходимо использовать блок try/finally, иначе будут

     // утечки памяти при исключениях.

     Text := StrAlloc(TextLen);

     try

      // Так как для буфера даже при пустом заголовке будет

      // выделен хотя бы один байт, здесь можно отправлять

      // WM_GETTEXT, не проверяя длину строки, как это было

      // в предыдущем варианте - буфер всегда будет

      // корректным.

      SendMessage(Wnd, WM_GETTEXT, TextLen, LParam(Text));

      // Обрезаем слишком длинною строку. Модифицировать

      // PChar сложнее, чем string. Вставка нуля в середину

      // строки приводит к тому, что все API-функции будут

      // игнорировать "хвост", но на работу StrDispose это не

      // повлияет, т.к. функция StrAlloc (а также прочие

      // функции выделения памяти для нуль-терминированных

      // строк модуля SysUtils) сохраняет размер выделенной

      // памяти рядом с самой строкой, и StrDispose

      // ориентируется именно на этот размер, а не на

      // завершающий ноль.

      if TextLen > 104 then

      begin

       (Text + 104)^ := #0;

       (Text + 103)^ := '.';

       (Text + 102)^ := '.';

       (Text + 101)^ := '.';

       (Text + 100)^ := ' ';

      end;

      GetClassName(Wnd, ClassName, ClassNameLen);

      if Text^ = #0 then NodeName := 'Без названия (' + ClassName + ') '

      else NodeName := Text + ' (' + ClassName + ');

      Node := FormWindows.TreeWindows.Items.AddChild(ParentNode, NodeName);

      Node.Data := Pointer(Wnd);

      EnumChildWindows(Wnd, @EnumWindowsProc, LParam(Node));

     finally

      // Вручную освобождаем память, выделенную для буфера

      StrDispose(Text);

     end;

    end;

    Второй вариант функции

    EnumWindowsProc
    отличается от первого только тем что для организации буфера для получения имени окна вместо переменной типа
    string
    используется переменная типа
    PChar
    . Соответственно, все манипуляции с динамической памятью теперь выполняются вручную, а просто отсечь конец слишком длинной строки и прибавить к результату другую строку (многоточие) мы не можем, приходится модифицировать строку посимвольно. Тем не менее видно, что и с помощью типа
    PChar
    задача создания буфера для строки, возвращаемой API-функцией, достаточно легко решается.

    1.2.2. Пример Line

    Пример Line представляет собой невизуальный компонент

    TLine
    , который перехватывает оконные сообщения своего владельца (владельца в терминах VCL, разумеется, раз речь идет о неоконном компоненте). Компонент
    TLine
    рисует на своем владельце линию из точки (
    StartX
    ,
    StartY
    ) в точку (
    EndX
    ,
    EndY
    ) цветом
    Color
    . Пользователь может перемещать концы линии мышью. Достаточно разместить компонент
    TLine
    на форме, и на ней появится линия, которую пользователь может перемещать как во время проектирования формы, так и во время выполнения программы. Можно также разместить на форме, например, панель, и сделать ее владельцем компонента
    TLine
    — тогда линия будет рисоваться на панели. Но это можно сделать только во время исполнения программы, потому что владельцем всех компонентов, созданных во время проектирования формы, становится сама форма. Чтобы установить компонент, нужно выполнить следующие действия:

    1. Переписать с компакт-диска файлы Line.pas и Line.dcr в папку, где вы храните компоненты. Если такой папки еще нет, самое время создать ее. Где именно она будет расположена, значения не имеет, выбирайте любое удобное для вас место. Главное — это прописать эту папку в путях, где Delphi ищет компоненты. Чтобы сделать это в Delphi 7 и более ранних версиях, откройте меню Tools\Environment Options, в появившемся диалоговом окне выберите закладку Library и добавьте свою папку в поле Library path. В BDS 2006 и выше откройте меню Tools\Options, в появившемся диалоговом окне в дереве в левой части выберите пункт Environment Options\Delphi Options\Library — Win32 и добавьте папку в поле Library path.

    2. Создайте новый пакет (меню File\New\Other, в открывшемся окне выбрать Package). После этого в Delphi 7 и более ранних версиях откроется небольшое окно пакета. В BDS 2006 и более поздних версиях окно не откроется, но пакет появится в группе проектов (по умолчанию это окно Project Manager в правом верхнем углу главного окна). Сохраните пакет в ту же папку, где находится Line.pas, под любым именем, кроме Line (иначе будет конфликт имен).

    3. Добавьте в пакет файл Line.pas. В BDS 2006 для этого необходимо с помощью правой кнопки мыши вызвать контекстное меню пакета в окне Project Manager и выбрать там пункт Add. В Delphi 7 и более ранних версиях в окне пакета нужно нажать кнопку Add.

    4. Установите компонент. В BDS 2006 и выше для этого следует выбрать пункт Install в контекстном меню проекта, а в Delphi 7 и более ранних версиях — нажать кнопку Install в окне пакета. После этого в палитре компонентов у вас появится вкладка Delphi Kingdom Samples, a в ней — компонент TLine.

    Если вы не хотите помещать компонент

    TLine
    в палитру компонентов (или у вас Turbo Delphi Explorer, и вы просто не имеете такой возможности), можно воспользоваться проектом LineSample, который во время выполнения создаёт два экземпляра
    TLine
    , владельцем одного из которых является форма, другого — панель.

    Перехват сообщения владельца осуществляется путем изменения его свойства

    WindowProc
    — записи в него указателя на свой обработчик сообщений. Здесь можно применить один хитрый прием. Компонент
    TLine
    не имеет своей оконной процедуры, т.к., будучи прямым наследником класса
    TComponent
    , окном не является. Но метод
    Dispatch
    у него есть, поскольку он объявлен в классе
    TObject
    . В классе
    TComponent
    и в его предках метод
    Dispatch
    никогда не вызывается. Если мы напишем обработчик сообщений таким образом, что он будет передавать сообщения методу
    Dispatch
    , то сможем в нашем компоненте создавать свои методы для обработки сообщений, в которые метод
    Dispatch
    при необходимости будет передавать сообщения для обработки. Необработанные сообщения при этом будут передаваться в метод
    DefaultHandler
    , который у класса
    TComponent
    ничего не делает. Если мы перекроем
    DefaultHandler
    так, чтобы он вызывал оригинальный обработчик сообщений родителя, то все необработанные сообщения пойдут туда. Более того, вызов
    inherited
    из методов-обработчиков сообщений тоже будет приводить к вызову оригинального обработчика родителя, т.к. в данном случае
    inherited
    при отсутствии унаследованного обработчика приводит к вызову
    DefaultHandler
    . В листинге 1.24 показано объявление класса
    TLine
    и код его методов, относящихся к перехвату сообщений.

    Листинг 1.24. Базовая часть класса
    TLine

    type

     TLine = class(TComponent)

     private

      // FCoords хранит координаты линии. Начало линии

      // находится в точке (FCoords[0], FCoords[1]),

      // конец - в (FCoords[2], FCoords[3]).

      FCoords:array[0..3] of Integer;

      // Конструктор класса написан так, что владельцем TLine

      // может стать только TWinControl или его наследник.

      // Но свойство Owner имеет тип TComponent, поэтому при

      // использовании свойств и методов класса TWinControl

      // Owner придется каждый раз приводить к типу

      // TWinControl. Чтобы избежать приведений типа,

      // используется поле FWinOwner. Оно указывает на тот же

      // объект, что и Owner, но имеет тип TWinControl.

      FWinOwner: TWinControl;

      // Здесь хранится адрес обработчика сообщений, бывший до

      // перехвата.

      FOldProc: TWndMethod;

      // Цвет линии

      FColor: TColor;

      // Состояние линии. Если FStartMoving = True, в данный

      // момент пользователь перемещает начало линии, если

      // FEndMoving = True - ее конец.

      FStartMoving, FEndMoving: Boolean;

      // Если FDrawLine = False, линия не рисуется. Это

      // используется, когда нужно стереть линию.

      FDrawLine: Boolean;

      procedure WMPaint(var Msg: TWMPaint); message WM_PAINT;

      procedure WMLButtonDown(var Msg: TWMLButtonDown); message WM_LBUTTONDOWN;

      procedure WMLButtonUp(var Msg: TWMButtonUp); message WM_LBUTTONUP;

      procedure WMMouseMove(var Msg: TWMMouseMove); message WM_MOUSEMOVE;

      procedure SetColor(Value: TColor);

      procedure SetCoord(Index, Value: Integer);

     protected

      // Этот метод будет новым обработчиком сообщений

      // владельца

      procedure HookOwnerMessage(var Msg: Message);

     public

      constructor Create(AOwner: TComponent); override;

      destructor Destroy; override;

      procedure DefaultHandler(var Msg); override;

     published

      property Color: TColor read FColor write SetColor default clWindowText;

      property StartX: Integer index 0 read FCoords[0] write SetCoord default 10;

      property StartY: Integer index 1 read FCoords[1] write SetCoord default 10;

      property EndX: Integer index 2 reed FCoords[2] write SetCoord default 50;

      property EndY: Integer index 3 read FCoords[3] write SetCoord default 50;

     end;

    ...


    constructor TLine.Create(AOwner: TComponent);

    begin

     if not Assigned(AOwner) then raise EWrongOwner.Create(

      'Должен быть назначен владелец компонента TLine');

     if not (AOwner is TWinControl) then raise EWrongOwner.Create(

      'Владелец компонента TLine должен быть наследником TWinControl');

     FWinOwner := AOwner as TWinControl;

     inherited;

     FCoords[0] := 10;

     FCoords[1] := 10;

     FCoords[2] := 50;

     FCoords[3] := 50;

     FColor := clWindowText;

     FStartMoving := False;

     FEndMoving := False;

     FDrawLine := True;

     // Запоминаем старый обработчик сообщений владельца и

     // назначаем новый.

     FOldProc := FWinOwner.WindowProc;

     FWinOwner.WindowProc := HookOwnerMessage;

     FWinOwner.Refresh;

    end;


    destructor TLine.Destroy;

    begin

     // Восстанавливаем старый обработчик сообщений владельца.

     FWinOwner.WindowProc := FOldProc;

     FWinOwner.Refresh;

     inherited;

    end;


    procedure TLine.HookOwnerMessage(var Msg: TMessage);

    begin

     // Единственное, что делает перехватчик сообщений -

     // передает их методу Dispatch. Было бы оптимальнее

     // назначить обработчиком сообщений сам метод Dispatch,

     // но формально он имеет прототип, несовместимый с

     // типом TWndMethod, поэтому компилятор не разрешает

     // подобное присваивание. Фактически же Dispatch

     // совместим с TWndMethod, поэтому, используя хакерские

     // методы, можно было бы назначить обработчиком его и

     // обойтись без метода HookOwnerMessage. Но хакерские

     // методы - вещь небезопасная, они допустимы только

     // тогда, когда других средств решения задачи нет.

     Dispatch(Msg);

    end;


    procedure TLine.DefaultHandler(var Msg);

    begin

     FOldProc(TMessage(Msg));

    end;

    Собственно рисование линии на поверхности владельца обеспечивает метод

    WMPaint
    (листинг 1.25).

    Листинг 1.25. Метод
    WMPaint

    procedure TLine.WMPaint(var Msg: TWMPaint);

    var

     NeedDC: Boolean;

     PS: TPaintStruct;

     Pen: HPEN;

    begin

     if FDrawLine then

     begin

      // Проверка, был ли DC получен предыдущим обработчиком

      NeedDC := Msg.DC = 0;

      if NeedDC then Msg.DC := BeginPaint(FWinOwner.Handle, PS);

      inherited;

      Pen := CreatePen(PS_SOLID, 1, ColorToRGB(FColor));

      SelectObject(Msg.DC, Pen);

      MoveToEx(Msg.DC, FCoords[0], FCoords[1], nil);

      LineTo(Msg.DC, FCoords[2], FCoords[3]);

      SelectObject(Msg.DC, GetStockObject(BLACK_PEN));

      DeleteObject(Pen);

      if NeedDC then EndPaint(FWinOwner.Handle, PS);

     end

     else inherited;

    end;

    Поскольку рисуется простая линия, мы не будем здесь создавать экземпляр

    TCanvas
    и привязывать его к контексту устройства, обойдемся вызовом функций GDI. Особенности работы с контекстом устройства при перехвате сообщения
    WM_PAINT
    описаны в разд. 1.2.4.

    Чтобы пользователь мог перемещать концы линии, нужно перехватывать и обрабатывать сообщения, связанные с перемещением мыши и нажатием и отпусканием ее левой кнопки (листинг 1.26).

    Листинг 1.26. Обработка сообщений мыши

    procedure TLine.WMLButtonDown(var Msg: TWMLButtonDown);

    var

     DC: HDC;

     OldMode: Integer;

    begin

     if PTInRect(Rect(FCoords[0] - 3, FCoords[1] - 3, FCoords[0] + 4, FCoords[1] + 4), Point(Msg.XPos, Msg.YPos)) then

     begin

      FStartMoving := True;

      FDrawLine := False;

      FWinOwner.Refresh;

      FDrawLine := True;

      DC := GetDC(FWinOwner.Handle);

      OldMode := SetROP2(DC, R2_NOT);

      SelectObject(DC, GetStockObject(BLACK_PEN));

      MoveToEx(DC, FCoords[0], FCoords[1], nil);

      LineTo(DC, FCoords[2], FCoords[3]);

      SetROP2(DC, OldMode);

      ReleaseDC(FWinOwner.Handle, DC);

      SetCapture(FWinOwner.Handle);

      Msg.Result := 0;

     end

     else

      if PTInRect(Rect(FCoords[2] - 3, FCoords[3] - 3, FCoords[2] + 4, FCoords[3] + 4), Point(Msg.XPos, Msg.YPos)) then

      begin

       FEndMoving := True;

       FDrawLine := False;

       FWinOwner.Refresh;

       FDrawLine := True;

       DC := GetDC(FWinOwner.Handle);

       OldMode := SetROP2(DC, R2_NOT);

       SelectObject(DC, GetStockObject(BLACK_PEN));

       MoveToEx(DC, FCoords[0], FCoords[1], nil);

       LineTo(DC, FCoords[2], FCoords[3]);

       SetROP2(DC, OldMode);

       ReleaseDC(FWinOwner.Handle, DC);

       SetCapture(FWinOwner.Handle);

       Msg.Result := 0;

      end

    else inherited;

    end;


    procedure TLine.WMLButtonUp(var Msg: TWMLButtonUp);

    begin

     if FStartMoving then

     begin

      FStartMoving := False;

      ReleaseCapture;

      FWinOwner.Refresh;

      Msg.Result := 0;

     end

     else if FEndMoving then

     begin

      FEndMoving := False;

      ReleaseCapture;

      FWinOwner.Refresh;

      Msg.Result := 0;

     end

     else inherited;

    end;


    procedure TLine.WMMouseMove(var Мsg: TWMMouseMove);

    var

     DC: HDC;

     OldMode: Integer;

    begin

     if FStartMoving then

     begin

      DC := GetDC(FWinOwner.Handle);

      OldMode := SetROP2(DC, R2_NOT);

      SelectObject(DC, GetStockObject(BLACK_PEN));

      MoveToEx(DC, FCoords[0], FCoords[1], nil);

      LineTo(DC, FCoords[2], FCoords[3]);

      FCoords[0] := Msg.XPos;

      FCoords[1] := Msg.YPos;

      MoveToEx(DC, FCoords[0], FCoords[1], nil);

      LineTo(DC, FCoords[2], FCoords[3]));

      SetROP2(DC, OldMode);

      ReleaseDC(FWinOwner.Handle, DC);

      Msg.Result := 0;

     end

     else if FEndMoving then

     begin

      DC := GetDC(FWinOwner.Handle);

      OldMode := SetROP2(DC, R2_NOT);

      SelectObject(DC, GetStockObject(BLACK_PEN));

      MoveToEx(DC, FCoords[0], FCoords[1], nil);

      LineTo(DC, FCoords[2], FCoords[3]);

      FCoords[2] := Msg.XPos;

      FCoords[3] := Msg.YPos;

      MoveToEx(DC, FCoords[0], FCoords[1], nil);

      LineTo(DC, FCoords[2], FCoords[3]);

      SetROP2(DC, OldMode);

      ReleaseDC(FWinOwner.Handle, DC);

      Msg.Result := 0;

     end

     else inherited;

    end;

    Здесь реализован инверсный способ создания "резиновой" линии, когда при рисовании линии все составляющие ее пикселы инвертируются, а при стирании инвертируются еще раз. Этот способ подробно описан в разд. 1.3.4.2. Перехват сообщений родителя — дело относительно простое, гораздо хуже обстоят дела с удалением компонента, перехватившего сообщения родителя. Пока такой компонент один, проблем не возникает, но когда их несколько приходится обращаться с ними очень аккуратно. Рассмотрим, например, такой код (листинг 1.27).

    Листинг 1.27. Пример кода, вызывающего ошибку

    Line1 := TLine.Create(Form1);

    Line2 := TLine.Create(Form2);

    ...

    Line1.Free;

    ...

    Line2.Free;

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

    Form1.WindowProc
    ссылается на
    Form1.WndProc
    , т.е. на собственный обработчик сообщений формы. При создании объекта
    Line1
    он перехватывает обработчик, и
    Form1.WindowProc
    начинает ссылаться на
    Line1.HookOwnerMessage
    , а ссылка на
    Form1.WndProc
    сохраняется в
    Line1.FOldProc
    . Объект
    Line2
    также перехватывает обработчик сообщений, и после его создания
    Form1.WindowProc
    будет ссылаться на
    Line2.HookOwnerMessage
    , a
    Line2.FOldProc
    — на
    Line1.HookOwnerMessage
    .

    Теперь удалим

    Line1
    . При удалении объект восстановит ссылку на тот обработчик сообщений, который был установлен на момент его создания, т.е.
    Form1.WindowProc
    вновь станет указывать на
    Form1.WndProc
    . Соответственно, компонент
    Line2
    потеряет способность реагировать на сообщения владельца. Поле
    Line2.FOldProc
    при этом останется без изменений. Но самое неприятное начнется при удалении объекта
    Line2
    . Он тоже восстановит ссылку на обработчик, который был назначен на момент его создания, т.е. запишет в свойство
    Form1.WindowProc
    ссылку на
    Line1.HookOwnerMessage
    . Но поскольку объекта
    Line1
    уже не существует, это будет ссылка в никуда, и обработка первого же сообщения, пришедшего форме, даст ошибку Access violation.

    Примечание

    Аналогичная проблема возникнет и в режиме проектирования, если на форму положить два компонента

    TLine
    , удалить первый, a затем — второй. В этом случае ошибки возникнут в самой среде
    Delphi
    , и ее придется перезапускать. Вообще говоря, компоненты, перехватывающие сообщения владельца, должны делать это только во время выполнения программы, чтобы не "уронить" среду. Здесь мы для наглядности опустили соответствующие проверки.

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

    1.2.3. Пример CoordLabel

    CoordLabel — это пример визуального компонента, перехватывающего сообщения своего родителя. Компонент

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

    Установка компонента

    TCoordLabel
    полностью аналогична установке компонента
    TLine
    из предыдущего раздела. На прилагаемом компакт-диске находится также проект LineCoordSample для того, чтобы работу компонента можно было увидеть без установки в палитру компонентов. На форме проекта LineCoordSample находится панель, кнопка Переместить и компонент
    TLineCoordSample
    , который по нажатию кнопки меняет родителя с формы на панель и обратно.

    Код компонента

    TCoordLabel
    приведен в листинге 1.28.

    Листинг 1.28. Компонент
    TCoordLabel

    type

     TCoordLabel = class(TLabel)

    private

     // Здесь хранится адрес обработчика

     // сообщений, бывший до перехвата.

     FOldProc: TWndMethod;

    protected

     procedure SetParent(AParent: TWinControl); override;

     // Этот метод будет новым обработчиком

     // сообщений владельца

     procedure HookParentMessage(var Msg: TMessage);

    end;

    ...


    procedure TCoordLabel.SetParent(AParent: TWinControl);

    begin

     if Assigned(Parent) and Assigned(FOldProc) then Parent.WindowProc := FOldProc;

     inherited;

     if Assigned(Parent) then

     begin

      FOldProc := Parent.WindowProc;

      Parent.WindowProc := HookParentMessage;

     end;

    end;


    procedure TCoordLabel.HookParentMessage(var Msg: TMessage);

    begin

     if Msg.Msg = WM_LBUTTONDOWN then

      Caption := '(' + IntToStr(Msg.LParamLo) + ', ' + IntToStr(Msg.LParamHi) + ')';

     FOldProc(Msg);

    end;

    Класс

    TLabel
    , предок
    TCoordLabel
    , является визуальным компонентом и сам может получать и обрабатывать сообщения, поэтому метод
    Dispatch
    у него уже "занят". Соответственно, мы не можем диспетчеризовать с его помощью перехваченные сообщения и должны обрабатывать их внутри метода
    HookParentMessage
    .

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

    Parent
    , которое приводит к вызову виртуального метода
    SetParent
    . Мы перекрываем этот метод и выполняем в нем как восстановление обработчика старого родителя, так и перехват сообщений нового. Это позволяет компоненту менять родителя во время работы программы. Писать отдельно деструктор для восстановления оригинального обработчика родителя в данном случае нужды нет, поскольку деструктор, унаследованный от
    TControl
    , содержит вызов метода
    SetParent
    с параметром
    nil
    . Так как мы уже перекрыли
    SetParent
    , это приведет к восстановлению оригинального обработчика, т.е. к тому, что нам нужно.

    Если на форму, содержащую

    TCoordLabel
    , поместить другие компоненты можно заметить, что
    TCoordLabel
    отлавливает нажатия мыши, сделанные на неоконных компонентах, но игнорирует те, которые сделаны на оконных. Это происходит потому, что неоконные компоненты получают сообщения через оконную процедуру родителя (которая перехвачена), а оконные имеют свою оконную процедуру, никак не связанную с оконной процедурой родителя. И, разумеется, компонент
    TCoordLabel
    имеет те же проблемы с восстановлением оригинального обработчика, что и
    TLine
    , если на одном родителе расположены несколько компонентов. Соответственно, применять
    TCoordLabel
    необходимо аккуратно, с учетом возможных последствий.

    1.2.4. Пример PanelMsg

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

    TPanel
    . Для перехвата сообщений используется свойство
    WindowProc
    панели.

    Мы будем обрабатывать два сообщения, приходящих с панели:

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

    Примечание

    Для рисования на поверхности

    панели
    , вообще говоря, существует более простой и правильный способ: нужно положить на панель компонент
    TPaintBox
    , растянуть его на всю область панели и рисовать в его событии OnPaint. Мы здесь используем более сложный способ перехвата сообщения
    WM_PAINT
    только в учебных целях.

    При перехвате сообщения

    WM_PAINT
    любого компонента, на котором расположены неоконные визуальные компоненты, может возникнуть проблема с перерисовкой этих компонентов. Чтобы продемонстрировать способ решения этих проблем, разместим на панели компонент TLabel, который заодно будет показывать пользователю реакцию на двойной щелчок правой кнопкой мыши. В результате получается окно, показанное на рис. 1.9. При двойном щелчке правой кнопкой мыши на панели надпись Сделайте двойной щелчок правой кнопкой перемещается в то место, где находится курсор. Чтобы перехватить оконную процедуру панели, следует написать метод, который ее подменит, а адрес старого метода сохранить в предназначенном для этого поле. Сам перехват будем осуществлять в обработчике события
    OnCreate
    формы (листинг 1.29).

    Рис. 1.9.
    Окно программы PanelMsg


    Листинг 1.29. Перехват обработчика сообщений панели

    type

     TForm1 = class(TForm)

      Panel: TPanel;

      Label1: TLabel;

      procedure FormCreate(Sender: TObject);

     private

      // Здесь будет храниться исходный обработчик сообщений

      // панели

      FOldPanelWndProc: TWndMethod;

      // Этот метод будет перехватывать сообщения,

      // предназначенные панели

      procedure NewPanelWndProc(var Msg: TMessage);

     end;

    ...


    procedure TForm1.FontCreate(Sender: TObject);

    begin

     FOldPanelWndProc := Panel.WindowProc;

     Panel.WindowProc := NewPanelWndProc;

    end;

    Сам перехватчик выглядит так, как показано в листинге 1.30.

    Листинг 1.30. Метод-перехватчик сообщений панели

    procedure TForm1.NewPanelWndProc(var Msg: TMessage);

    var

     NeedDC: Boolean;

     PS: TPaintStruct;

     PanelCanvas: TCanvas;

    begin

     if Msg.Msg = WM_RBUTTONDBLCLK then

     begin

      Label1.Left := Msg.LParamLo;

      Label1.Top := Msg.LParamHi;

      Msg.Result := 0;

     end

     else if Msg.Msg = WM_PAINT then

     begin

      // Проверяем, был ли запрошен контекст устройства

      // обработчиком, стоящим раньше по цепочке, и если не

      // был, то запрашиваем его.

      NeedDC := Msg.WParam = 0;

      if NeedDC then Msg.WParam := BeginPaint(Panel.Handle, PS);

      // Вызываем старый обработчик WM_PAINT. Его нужно

      // вызывать обязательно до того, как мы начнем рисовать

      // на поверхности что-то свое, т.к. в противном случае

      // это что-то будет закрашено стандартным обработчиком.

      POldPanelWndProc(Msg);

      // При использовании графических функций API самое

      // неудобное - это вручную создавать и уничтожать кисти,

      // карандаш и т.п. Поэтому здесь создается экземпляр

      // класса TCanvas для рисования на контексте устройства

      // с дескриптором, полученным при вызове BeginPaint.

      PanelCanvas := TCanvas.Create;

      try

       PanelCanvas.Handle := Msg.WParam;

       FanelCanvas.Pen.Style := psClear;

       PanelCanvas.Brush.Style := bsSolid;

       PanelCanvas.Brush.Color := clWhite;

       PanelCanvas.Ellipse(10, 10, Panel.Width - 10, Panel.Height - 10);

       PanelCanvas.Brush.Color := clYellow;

       PanelCanvas.Rectangle(100, 100, Panel.Width - 100, Panel.Height - 100);

      finally

       PanelCanvas.Free;

      end;

      // В данном случае панель содержит визуальный неоконный

      // компонент TLabel. Отрисовка неоконных компонентов

      // происходит при обработке WM_PAINT родительского

      // компонента, т.е. здесь она была выполнена при вызове

      // стандартного обработчика. Таким образом, сделанный

      // рисунок закрасил не только фон панели, но и

      // неоконные компоненты. Чтобы компоненты были поверх

      // рисунка, их приходится перерисовывать еще раз,

      // вызывая protected-метод PaintControls. Это не очень

      // эффективно, т.к. получается, что компоненты рисуются

      // дважды: в стандартном обработчике и здесь. Но

      // другого способа решить проблему, видимо, нет. Если

      // бы на панели лежали только оконные компоненты,

      // вызывать PaintControls не понадобилось, поскольку то, что

      // мы рисуем на панели, не может затереть поверхность

      // лежащих на этой панели других окон.

      TFakePanel(Panel).PaintControls(Msg.WParam, nil);

      // Если мы получали контекст устройства, мы же должны

      // освободить его.

      if NeedDC then

      begin

       EndPaint(Panel.Handle, PS);

       Msg.WParam := 0;

      end;

     end

     else FOldPanelWndProc(Msg);

    end;

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

    WM_RBUTTONDBLCLK
    просто перемещаем метку
    Label1
    на то место, где пользователь щелкнул мышью. Затем обнуляем результат, давая понять системе, что сообщение полностью обработано. Вызов унаследованного обработчика в данном случае не выполняем, потому что никакая унаследованная реакция на данное событие нам не нужна. Обработка сообщения
    WM_PAINT
    сложнее. Сначала необходимо разобраться с контекстом устройства, на котором будет производиться рисование. Вообще говоря, обработчик
    WM_PAINT
    должен получать этот контекст с помощью функции
    BeginPaint
    . Но если до написанного нами кода сообщение
    WM_PAINT
    уже начало обрабатываться, то контекст устройства уже получен, а вызывать
    BeginPaint
    два раза нельзя. В этом случае контекст устройства передаётся через параметр сообщения
    WParam
    . Соответственно, обработка сообщения
    WM_PAINT
    начинается с того, что мы проверяем, равен ли нулю параметр
    wParam
    , и если равен, то получаем контекст устройства, а если не равен, используем то, что передано.

    Унаследованный обработчик закрашивает всю панель целиком, поэтому его нужно вызывать до того, как мы нарисуем что-то свое, иначе он просто закрасит то, что мы нарисовали. Так что следующий шаг — это вызов стандартного обработчика сообщений панели, указатель на который мы сохранили в поле

    FOldPanelWndProc
    . Только после этого можно что-то рисовать.

    Примечание

    Перекрывая обработку сообщения

    WM_PAINT
    , мы лишаем код VCL возможности полностью контролировать процесс перерисовки. В частности, это означает что значение свойства
    DoubleBuffered
    будет игнорироваться, двойной буферизации не будет. Поэтому еще раз напоминаем, что программа
    PanelMsg
     — это учебный пример, помогающий разобраться с механизмами взаимодействия VCL и Windows API, но не являющийся образцом для подражания. Если в реальной жизни потребуется рисовать что-то непосредственно на панели, нужно порождать от класса
    TPanel
    наследника и перекрывать в нем метод
    Paint
    .

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

    TCanvas
    способом, который был продемонстрирован в листинге 1.17 (см. разд. 1.1.11). Если бы мы остановились на этом, то увидели бы интересную картину: нарисованные фигуры лежат поверх текста метки
    Label1
    . Объяснение этому очень простое: метка является неоконным визуальным компонентом и рисуется на поверхности своего родительского компонента при обработке его сообщения
    WM_PAINT
    . А поскольку стандартный обработчик у нас вызывается до того, как рисуются круг и прямоугольник, любой неоконный компонент будет перекрыт ими. К оконным компонентам это, разумеется, не относится, они лежат над родительской панелью, и то, что мы рисуем на этой панели, не может оказаться над ними.

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

    PaintControls
    , который и используется стандартным обработчиком. Конечно, получится, что неоконные компоненты рисуются дважды: в стандартном обработчике и в нашем, и это не очень хорошо. Но повторим еще раз, что программа
    PanelMsg
    — не образец для подражания, а что-то вроде зонда для исследования особенностей работы VCL.

    Вызов метода

    PaintControls
    затруднен тем, что он объявлен в разделе
    protected
    , а потому не может быть вызван из метода
    NewPanelWndProc
    , который относится к классу формы. Чтобы обойти это ограничение, нужно породить наследника от
    TPanel
    TFakePanel
    . Этот наследник ничего не добавляет к классу
    TPanel
    и ничего не переопределяет в нем. Но раз он объявлен в нашем модуле, все его
    protected
    -члены, в том числе и унаследованный метод
    PaintControls
    , становятся доступными в нем. После этого мы можем привести поле, содержащее ссылку на панель, к этому типу и вызвать
    PaintControls
    . Так как структуры типов
    TPanel
    и
    TFakePanel
    идентичны, это приведет к вызову нужного метода.

    Для завершения обработки сообщения

    WM_PAINT
    осталось только вызвать
    EndPaint
    , разумеется, только в том случае, если
    BeginPaint
    вызывали мы сами.

    И последнее, что мы должны сделать, — это передать все остальные сообщения стандартному обработчику. После этого программа PanelMsg готова.

    1.2.5. Пример NumBroadcast

    Программа NumBroadcast демонстрирует широковещательную рассылку глобальных сообщений. Окно программы показано на рис. 1.10.

    Рис 1.10. Окно программы NumBroadcast

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

    RegisterWindowMessage
    , а в оконной процедуре предусмотрена реакция на это сообщение (число передастся через параметр
    WParam
    ). Код программы приведен в листинге 1.31.

    Листинг 1.31. Модуль главного окна программы NumBroadcast

    unit NBMain;

    interface


    uses

     Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls;

    type TForm1 = class(TForm)

     EditNumber: TEdit;

     BtnBroadcast: TButton;

     LabelNumber: TLabel;

     procedure BtnBroadcastClick(Sender: TObject);

    private

     // Здесь будет храниться номер, присвоенный системой

     // глобальному сообщению

     FSendNumberMessage: Cardinal;

    protected

     // Так как номер сообщения станет известным только при

     // выполнении программы, объявить обработчик сообщения

     // с помощью директивы message нельзя. Приходится

     // перекрывать метод WndProc и обрабатывать сообщение в

     // нем. Можно было бы вместо WndProc перекрыть метод

     // DefaultHandler, но при этом зарегистрированное

     // сообщение обрабатывалось бы медленнее, потому что

     // сначала выполнялся бы метод WndProc, затем Dispatch

     // пытался бы найти подходящий обработчик среди методов

     // объекта, и лишь затем дело доходило бы до перекрытого

     // DefaultHandler. Но, с другой стороны, при перекрытии

     // WndProc обработка всех сообщений начинается со

     // сравнения их номера с FSendNumberMessage и вызова

     // унаследованного WndProc, если это другое сообщение.

     // А до DefaultHandler многие сообщения не дойдут, т.к.

     // будут обработаны ранее, и накладные расходы на

     // сравнение и вызов унаследованного метода будут меньше.

     procedure WndProc(var Msg: TMessage); override;

    public

     constructor Create(AOwner: TComponent); override;

    end;


    var

     Form1: TForm1;


    implementation

    {$R *.dfm}


    constructor TForm1.Create(AOwner: TComponent);

    begin

     // Регистрируем глобальное сообщение с именем

     // WM_DelphiKingdom_APISample_SendNumber. Имя достаточно

     // длинное и осмысленное, поэтому можно надеяться, что

     // никакое другое приложение не зарегистрирует сообщение с

     // таким же именем. Регистрация сообщения выполняется до

     // вызова унаследованного конструктора, т.к. при

     // выполнении этого конструктора окно получит ряд

     // сообщений, и метод WndProc будет несколько раз вызван.

     // Если вызвать унаследованный конструктор до вызова

     // RegisterWindowMessage, то поле FSendNumberMessage

     // будет иметь присвоенное ему по умолчанию значение 0,

     // а это - код сообщения WM_NULL. Таким образом, если в

     // это время окно получит сообщение WM_NULL, оно будет

     // неправильно обработано. Конечно, вероятность получения

     // WM_NULL во время выполнения унаследованного

     // конструктора крайне мала, но лучше подстраховаться и

     // сделать так, чтобы поле FSendNumberMessage на момент

     // первого вызова WndProc уже имело правильное значение.

     FSendNumberMessage := RegisterWindowMessage('WM_DelphiKingdom_APISample_SendNumber');

     inherited;

     // Здесь мы меняем стиль окна поля ввода, добавляя в него

     // ES_NUMBER. Стиль ES_NUMBER запрещает полю ввода

     // вводить какие-либо символы, кроме цифр. Это уменьшает

     // риск ошибки ввода в тех случаях, когда требуется целое

     // неотрицательное число.

     SetWindowLong(EditNumber.Handle, GWL_STYLE, GetWindowLong(EditNumber.Handle, GWL_STYLE) or ES_NUMBER);

    end;


    procedure TForm1.BtnBroadcastClick(Sender: TObject);

    var

     Num: Integer;

     Recipients: DWORD;

    begin

     try

      Num := StrToInt(EditNumber.Text);

      // Для широковещательной рассылки сообщения служит

      // функция BroadcastSystemMessage. В литературе обычно

      // советуют использовать более простую функцию

      // PostMessage, указывая в качестве адресата

      // HWND_BROADCAST. Однако PostMessage рассылает

      // сообщения только окнам верхнего уровня, не имеющим

      // владельца (в терминах системы). Но главная форма

      // приложения имеет владельца - это невидимое окно

      // приложения, реализуемое объектом TApplication.

      // Поэтому такое широковещательное сообщение главная

      // форма приложения не получит — его получит только

      // невидимое окно приложения (это сообщение можно

      // будет перехватить, назначив обработчик

      // Application.OnMessage - вручную или с помощью

      // компонента TApplicationEvents). Чтобы главная форма

      // тоже попала в список окон, получающих

      // широковещательное сообщение, используется функция

      // BroadcastSystemMessage.

      Recipients := BSM_APPLICATIONS;

      BroadcastSystemMessage(BSF_POSTMESSAGE, @Recipients, FSendNumberMessage, Num, 0);

     except

      on EConvertError do

      begin

       Application.MessageBox(

        'Введенное значение не является числом', 'Ошибка',

        MB_OK or MB_ICONSTOP);

      end;

     end;

    end;


    procedure TForm1.WndProc(var Msg: TMessage);

    begin

     if Msg.Msg = FSendNumberMessage then

      LabelNumber.Caption := IntToStr(Msg.WParam)

     else inherited;

    end;


    end.

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

    message
    , т.к. номер сообщения на этапе компиляции еще не известен. Здесь для обработки глобального сообщения мы перекрываем метод
    WndProc
    . Соответственно, все оконные сообщения, в том числе и те, которые окно получает при создании, будет обрабатывать перекрытый метод
    WndProc
    . Это значит, что поле
    FSendNumberMessage
    , которое задействовано в этом методе, должно быть правильно инициализировано раньше, чем окно получит первое сообщение. Поэтому вызов функции
    RegisterWindowMessage
    выполнять, например, в обработчике события
    OnCreate
    формы уже поздно. Его необходимо выполнить в конструкторе формы, причем до того, как будет вызван унаследованный конструктор.

    Примечание

    Существует другой способ решения этой проблемы: метод

    WndProc
    должен проверять значение поля
    FSendNumberMessage
    , и, если оно равно нулю, сразу переходить к вызову унаследованного метода. В этом случае инициализировать
    FSendNumberMessage
    можно позже.

    Нажатие на кнопку

    BtnBroadcast
    приводит к широковещательной отправке сообщения. Отправить широковещательное сообщение можно двумя способами: функцией
    PostMessage
    с адресатом
    HWND_BROADCAST
    вместо дескриптора окна и с помощью функции
    BroadcastSystemMessage
    . Первый вариант позволяет отправить сообщения только окнам верхнего уровня, не имеющим владельца в терминах системы. Таким окном в VCL-приложении является только невидимое окно приложения, создаваемое объектом
    Application
    . Главная форма имеет владельца в терминах системы — то самое невидимое окно приложения. Поэтому широковещательное сообщение, посланное с помощью
    PostMessage
    , главная форма не получит, это сообщение пришлось бы ловить с помощью события
    Application.OnMessage
    . Мы здесь применяем другой способ — отправляем сообщение с помощью функции
    BroadcastSystemMessage
    , которая позволяет указывать тип окон, которым мы хотим отправить сообщения. В частности, здесь мы выбираем тип
    BSM_APPLICATION
    , чтобы сообщение посылалось всем окнам верхнего уровня, в том числе и тем, которые имеют владельца. При таком способе отправки главная форма получит это широковещательное сообщение, поэтому его обработку можно реализовать в главной форме.

    1.2.6. Пример ButtonDel

    Программа ButtonDel демонстрирует, как можно удалить кнопку в обработчике нажатия этой кнопки. Очень распространенная ошибка — попытка написать код, один из примеров которого приведен в листинге 1.32.

    Листинг 1.32. Неправильный вариант удаления кнопки в обработчике ее нажатия

    procedure TForm1.Button1Click(Sender: TObject);

    begin

     Button1.Free;

    end;

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

    WM_COMMAND
    . При обработке форма выясняет, что источником сообщения является объект
    Button1
    и передает этому объекту сообщение
    CN_COMMAND
    .
    Button1
    , получив его, вызывает метод
    Click
    , который проверяет, назначен ли обработчик
    OnClick
    , и, если назначен, вызывает его. Таким образом, после завершения
    Button1Click
    управление снова вернется в метод
    Click
    объекта
    Button1
    , из него — в метод
    CNCommand
    , из него — в
    Dispatch
    , оттуда — в
    WndProc
    , а оттуда — в
    MainWndProc
    . А из
    MainWndProc
    управление будет передано в оконную процедуру, сформированную компонентом с помощью
    MakeObjectInstance
    . В деструкторе
    Button1
    эта оконная процедура будет уже удалена. Таким образом, управление получат последовательно пять методов уже не существующего объекта и одна несуществующая процедура. Это может привести к самым разным неприятным эффектам, но, скорее всего, — к ошибке Access violation (обращение к памяти, которую программа не имеет права использовать). Поэтому приведенный в листинге 1.32 код будет неработоспособным. В классе
    TCustomForm
    для безопасного удаления формы существует метод
    Release
    , который откладывает уничтожение объекта до того момента, когда это будет безопасно, но остальные компоненты подобного метода не имеют.

    Примечание

    Метод

    TCustomForm.Release
    на поверку тоже оказывается не совсем безопасным — подробнее об этом написано в разд. 3.4.3.

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

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

    Как раз для подобных случаев и предусмотрена возможность определять свои сообщения, т.к. ни одно из стандартных для наших целей не подходит. Свое сообщение мы будем посылать только одному окну, без широковещания, поэтому для него вполне подходит диапазон сообщений класса. Номер сообщения становится известным на этапе компиляции, поэтому для обработки этого сообщения мы можем применить самый удобный способ написать метод-обработчик с помощью директивы message. С учётом всего этого код выглядит следующим образом (листинг 1.33).

    Листинг 1.33. Модуль главной формы программы ButtonDel

    unit BDMain;

    interface

    uses

     Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls;


    // Определяем свое сообщение. Константа, добавляемая к

    // WM_USER, может иметь произвольное значение в диапазоне

    // от 0 до 31743.

    const

     WM_DELETEBUTTON = WM_USER + 1;


    type TForm1 = class(TForm)

     BtnDeleteSelf: TButton;

     procedure BtnDeleteSelfClick(Sender: TObject);

    private

     // Определяем метод - обработчик событий WM_DELETEBUTTON.

     // Ему будет передано управление через Dispatch.

     procedure WMDeleteButton(var Msg: TMessage); message WM_DELETEBUTTON;

    public

     { Public declarations }

    end;


    var

     Form1: TForm1;


    implementation

    {$R *.dfm}


    procedure TForm1.BtnDeleteSelfClick(Sender: TObject);

    begin

     // Помещаем сообщение WM_DELETEBUTTON в очередь формы.

     // Указатель на объект, который нужно удалить, помещаем

     // в LParam. В 32-разрядных версиях Windows указатель

     // можно помещать как в wParam, так и в lParam, но по

     // традиции, берущей начало в 16-разрядных версиях,

     // указатель обычно передают через lParam.

     PostMessage(Handle, WM_DELETEBUTTON, 0, LParam(BtnDeleteSelf));

     // Здесь принципиально использование PostMessage, а не

     // SendMessage. SendMessage в данном случае привел бы к

     // немедленному вызову оконной процедуры, и метод

     // WMDeleteButton был бы вызван до завершения работы

     // BtnDeleteSelfClick. Это привело бы к тому же

     // результату, что и прямой вызов BtnDeleteSelf.Free.

    end;


    procedure TForm1.WMDeleteButton(var Msg: TMessage);

    begin

     // Просто удаляем объект, указатель на который передан

     // через lParam.

     TObject(Msg.LParam).Free;

    end;

    end.

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

    Button1
    и
    Button2
    . Обработчик нажатия
    Button1
    содержит длительную операцию, и поэтому в нем вызывается
    Application.ProcessMessages
    . Обработчик нажатия
    Button2
    содержит строку
    Button1.Free
    . Если после запуска программы сразу нажать
    Button2
    , проблем не возникнет и объект
    Button1
    будет благополучно удален. Но если сначала нажать
    Button1
    , а затем —
    Button2
    , возникнет ошибка. Это произойдёт потому, что нажатие
    Button2
    будет в данном случае обработано локальной петлей сообщения, и после обработки управление вернется
    Button1Click
    , а оттуда — в методы уже не существующего объекта
    Button1
    . Посылка в
    Button2Click
    сообщения форме здесь не поможет, потому что это сообщение также будет извлечено и обработано локальной петлей. Общего решения таких проблем, видимо, не существует. В сложных случаях можно посоветовать не удалять объект, а просто прятать его (
    Visible := False
    ) — видимый результат для пользователя будет тот же самый.

    1.2.7. Пример GDIDraw

    Программа GDIDraw демонстрирует некоторые возможности GDI, которые не поддерживаются классом

    TCanvas
    . Выбраны только те возможности, которые поддерживаются не только в Windows NT/2000/XP, но и в 9x/ME. Окно программы показано на рис. 1.11.

    В своей работе программа использует рисунок из стандартных картинок Delphi, предполагая, что эти картинки установлены в папку "С:\Program Files\Common Files\Borland Shared\Images". Если у вас эти картинки установлены в другую папку, или по каким-то причинам вы хотите выбрать другой рисунок, измените обработчик события

    OnCreate
    формы так, чтобы он загружал рисунок из нужного вам файла. Загруженный рисунок сохраняется в поле
    FBitmap
    формы.

    Рис. 1.11. Окно программы GDIDraw


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

    OnPaint
    формы. Мы здесь будем разбирать этот обработчик не целиком, а по частям в соответствии с тем, что каждая часть рисует. Начнем с надписи Delphi Kingdom в левом верхнем углу окна (листинг 1.34).

    Листинг 1.34. Вывод надписи Delphi Kingdom

    var

     R: TRect;

    ...

    // Формируем регион, использующийся для отсечения.

    // Формируем его только при первом вызове метода, а при

    // дальнейших используем созданный ранее. Поле FRgn

    // содержит дескриптор этого региона

    if FRgn = 0 then

    begin

     Canvas.Font.Name := 'Times New Roman';

     Canvas.Font.Style := [fsBold];

     Canvas.Font.Height := 69;

     // Начинаем рисование траектории. Все вызовы

     // графических функций, находящиеся между BeginPath

     // и EndPath, не будут приводить к выводу на экран.

     // Вместо этого информация о том, что рисуется, будет

     // сохраняться а специальном объекте GDI - траектории.

     BeginPath(Canvas.Handle);

     R := Rect(10, 10, 10 + FBitmap.Width, 10 + FBitmap.Height);

     // Если не установить с помощью SetBkMode прозрачный

     // фон, в траекторию попадут не только контуры букв,

     // но и контуры содержащих их прямоугольных знакомест.

     SetBkMode(Canvas.Handle, TRANSPARENT);

     // Выводим текст "Delphi Kingdom", выравнивая его по

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

     DrawText(Canvas.Handle, 'Delphi'#13#10'Kingdom', -1, R,

      DT_CENTER or DT_VCENTER);

     EndPath(Canvas.Handle);

     // Превращаем траекторию в регион. В результате вызова

     // этой функции получится регион, контуры которого

     // совпадают с контурами надписи "Delphi Kingdom",

     // сделанной в указанных координатах выбранным шрифтом.

     FRgn := PathToRegion(Canvas.Handle);

    end;

    // Устанавливаем регион отсечения. Все, что не будет

    // попадать в выбранный регион, при выводе будет

    // игнорироваться.

    SelectClipRgn(Canvas.Handle, FRgn);

    // Выводим изображение. Все, что не попадает в область

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

    // "Delphi Kingdom", подсвеченную выбранным изображением.

    Canvas.Draw(10, 10, FBitmap);

    // Отменяем отсечение по региону

    SelectClipRgn(Canvas.Handle, 0);

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

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

    Соответственно, чтобы сделать такую надпись, нужно создать регион, совпадающий по форме с этой надписью. В GDI есть целый ряд функций для создания регионов различной формы, но вот для создания региона в форме букв функции нет. Зато GDI поддерживает другие объекты — траектории. Строго говоря, это не совсем объекты, траектория не имеет дескриптора (по крайней мере, API не предоставляет этот дескриптор программам), и в каждом контексте устройства может быть только одна траектория. Создание траектории начинается с вызова функции

    BeginPath
    , заканчивается вызовом функции
    EndPath
    . Графические функции, вызванные между
    BeginPath
    и
    EndPath
    , не выводят ничего в контекст устройства, а то, что должно быть выведено, вместо этого запоминается в траектории (которая представляет собой совокупность замкнутых кривых). С траекторией можно выполнить много полезных операций (см., например, разд. 1.3.4). В нашем случае между вызовами
    BeginPath
    и
    EndPath
    мы вызываем
    DrawText
    . формируя таким образом траекторию, состоящую из контуров букв. Затем с помощью функции
    PathToRegion
    мы создаем регион, границы которого совпадают с контурами траектории, т.е., в данном случае, регион, совпадающий по форме с надписью.

    Примечание

    На самом деле не все графические функции, вызванные между

    BeginPath
    и
    EndPath
    , добавляют контуры к траектории. Это зависит от версии операционной системы. Подробнее этот вопрос обсуждается в разд. 1.3.4.

    В ходе работы программы регион не меняется, так что нет нужды создавать его каждый раз при обработке события

    OnPaint
    . Он создается только один раз, и его дескриптор сохраняется в поле
    FRgn
    формы для дальнейшего использования.

    Все, что осталось сделать, — это установить регион отсечения с помощью функции

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

    Теперь рассмотрим, как рисуются звезды в правом верхнем углу окна (листинг 1.35).

    Листинг 1.35. Рисование звезд

    var

     I: Integer;

     Star: array[0..4] of TPoint;

    ...

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

    // надписи. Эти звезды демонстрируют использование двух

    // режимов заливки: WINDING и ALTERNATE. Для простых

    // фигур эти режимы дают одинаковые результаты, разница

    // возникает только при закрашивании сложных фигур,

    // имеющих самопересечения.

    Canvas.Pen.Style := psSolid;

    Canvas.Pen.Width := 1;

    Canvas.Pen.Color := clRed;

    Canvas.Brush.Style := bsSolid;

    Canvas.Brush.Color := clRed;

    // Вычисляем координаты вершин звезды. Они помещаются

    // в массив Star в следующем порядке (если первой

    // считать верхнюю вершину и нумеровать остальные по

    // часовой стрелке от нее): 1-3-5-2-4

    for I := 0 to 4 do

    begin

     Star[I].X := Round(380 + 90 * Sin(0.8 * I * Pi));

     Star[I].Y := Round(100 - 90 * Cos(0.8 * I * Pi));

    end;

    // Устанавливаем режим заливки WINDING. При

    // использовании этого режима закрашивается все

    // содержимое многоугольника независимо от того,

    // как именно он нарисован.

    SetPolyFillMode(Canvas.Handle, WINDING);

    Canvas.Polygon(Star);

    // Сдвигаем координаты звезды, чтобы нарисовать ее

    // правее с другим режимом заливки.

    for I := 0 to 4 do Inc(Star([I].X, 200);

    // Устанавливаем режим заливки ALTERNATE. При

    // использовании этого режима заполняются горизонтальные

    // линии, лежащие между нечетной и четной сторонами

    // многоугольника. В результате пятиугольник в центре

    // звезды оказывается незаполненным.

    SetPolyFillMode(Canvas.Handle, ALTERNATE);

    Canvas.Polygon(Star);

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

    Star
    и эта звезда рисуется с режимом заливки
    WINDING
    . При этом закрашиваются все точки, для которых выполняется условие, что луч, выпущенный из этой точки, пересекает контур многоугольника нечетное число раз, т.е. всю внутренность контура. Затем координаты вершин звезды смещаются вправо, и такая же звезда рисуется точно так же, но уже с режимом заливки
    ALTERNATE
    . В этом режиме закрашиваются только те точки, которые оказались между четной и нечетной сторонами многоугольника, и пятиугольник внутри звезды остается незакрашенным. Обратите внимание, что звезду мы здесь рисуем с помощью класса
    TCanvas
    , и только режимы заливки переключаем API-функциями.

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

    PolyPolygon
    , позволяющей за один раз нарисовать фигуру, ограниченную несколькими замкнутыми многоугольными контурами (листинг 1.36).

    Листинг 1.36. Рисование рамки с использованием
    PolyPolygon

    const

     Pts: array[0..7] of TPoint = (

      (X: 40; Y: 230), (X: 130; Y: 230),

      (X: 130; Y: 320), (X: 40; Y: 320),

      (X: 60; Y: 250), (X: 60; Y: 300),

      (X: 110; Y: 300), (X: 110; Y: 250));

     Cnt: array[0..1] of Integer = (4, 4);

    ...

    // Следующая группа команд рисует прямоугольную рамку

    Canvas.Pen.Color := clLime;

    Canvas.Pen.Width := 3;

    // Эти линии рисуются для того, чтобы показать, что

    // центр рамки остается прозрачным.

    Canvas.MoveTo(30, 220);

    Canvas.LineTo(140, 330);

    Canvas.MoveTo(140, 220);

    Canvas.LineTo(30, 330);

    Canvas.Pen.Color := clBlack;

    Canvas.Brush.Color := clBlack;

    // Функция PolyPolygon позволяет нарисовать несколько

    // многоугольников одной командой. Второй параметр

    // задает координат всех многоугольников, третий

    // параметр задает массив, содержащий число вершин

    // каждого из многоугольников. В нашем случае массив

    // Cnt имеет значение (4, 4). Это значит, что первые

    // четыре элемента массива PCs задают координаты первого

    // многоугольника, следующие четыре - второго. Отметим,

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

    // очень простым способом: сначала нужно получить

    // указатель на массив с помощью оператора @, а потом

    // этот указатель разыменовать. Формальные параметры,

    // определяющие указатели на массив, при импорте функции

    // PolyPolygon в модуле Windows.dcu объявлены как

    // нетипизированные параметры-переменные, поэтому

    // компилятор не разрешает просто передать Pts и Cnt в

    // качестве фактических параметров - он запрещает

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

    // Это не совсем корректно, т.к. локальная

    // типизированная константа - это на самом деле не

    // константа, а глобальная переменная с локальной

    // областью видимости. Тем не менее компилятор имеет

    // такую особенность, которую приходится учитывать.

    // В данном примере функция PolyPolygon используется для

    // рисования двух квадратов, один из которых целиком

    // лежит внутри другого. При этом содержимое внутреннего

    // квадрата остается незаполненным. Обратите внимание,

    // что квадраты рисуются в разных направлениях: внешний

    // по часовой стрелке, внутренний - против. Если

    // установлен режим заполнения ALTERNATE, это никак не

    // влияет на результат, но если установить режим WINDING,

    // внутренний квадрат не будет закрашен только в том

    // случае, если квадраты рисуются в противоположных

    // направлениях.

    PolyPolygon(Canvas.Handle, (@Pts)^, (@Cnt)^, 2);

    Вся хитрость в этом коде — как передать параметры в функцию

    PolyPolygon
    . Ее второй параметр — это указатель на массив элементов
    TPoint
    , содержащий координаты вершин всех контуров в массиве: сначала все вершины первого контура в нужном порядке, затем — все вершины второго контура и т.д. Третий параметр — это указатель на массив, содержащий число точек в каждом контуре: первый элемент массива содержит число точек в первом контуре, второй — во втором и т.д. Общее число контуров определяется четвёртым, последним параметром функции
    PolyPolygon
    . Число элементов во втором массиве должно быть равно значению четвертого параметра, a число элементов в первом массиве — сумме значений элементов второго массива. За выполнением этих требований должен следить сам программист, если он ошибется, функция может обратиться к памяти, лежащей за пределами массивов, и последствия будут непредсказуемыми.

    В оригинале параметры-массивы функции

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

    Нетрудно убедиться, что первые четыре элемента массива

    Pts
    содержат координаты вершин внешнего квадрата рамки, последние четыре — внутреннего квадрата.
    Массив
    Cnt, соответственно, содержит два элемента, оба из которых имеют значение 4. Это означает, что в нашей фигуре два замкнутых контура, и оба содержат по четыре вершины. Порядок следования вершин во внешнем квадрате — по часовой стрелке, во внутреннем — против. Это имеет значение, если выбран режим заливки
    WINDING
    , тогда направления обхода контуров должны быть противоположными, иначе отверстие тоже окажется закрашенным. Для режима заливки
    ALTERNATE
    направление обхода контуров не имеет значения.

    Далее программа

    GDIDraw
    демонстрирует работу функции
    InvertRect
    , которая инвертирует цвета в заданной прямоугольной области контекста устройства. Для того чтобы это было нагляднее, мы сначала выведем на форму загруженный в
    OnCreate
    рисунок (только на этот раз без региона отсечения) и инвертируем область, частично пересекающуюся с областью рисунка (листинг 1.37).

    Листинг 1.37. Пример использования функции
    InvertRect

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

    // его часть

    Canvas.Draw(300, 220, FBitmap);

    // Функция InvertRect делает указанный прямоугольник

    // "негативом".

    InvertRect(Canvas.Handle, Rect(320, 240, 620, 340));

    Ещё одна забавная функция GDI, которая почему-то не нашла отражения в классе

    TCanvas
    — это
    GrayString
    . Она предназначена для вывода "серого" текста, т.е. текста, который по яркости находится посредине между черным и белым. Обычно для этого просто устанавливается цвет
    RGB(128, 128, 128)
    , но некоторые черно-белые устройства не поддерживают полутона (это касается, прежде всего, старых моделей принтеров) — именно на них и ориентирована функция
    GrayString
    . Она позволяет рисовать серый текст произвольным образом с помощью функции обратного вызова, но эту функцию можно не указывать, и тогда рисование осуществляется функцией
    TextOut
    . Но при этом текст выводится через промежуточную растровую картинку в памяти, что обеспечивает полупрозрачность текста, т.к. закрашиваются не все пикселы, а только половина в шахматном порядке. На черно-белых принтерах с большим разрешением это действительно выглядит как серый текст, на экране же можно получать "полупрозрачные" надписи. Пример использования функции
    GrayString
    приведен в листинге 1.38.

    Листинг 1.38. Пример использования функции
    GrayString

    // Следующая группа команд выводит "полупрозрачную"

    // надпись "Windows API"

    Canvas.Brush.Color := clBlue;

    // Функция GrayString при выводе текста закрашивает

    // заданной кистью не все пикселы подряд, а в шахматном

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

    // эффект полупрозрачности.

    Canvas.Font.Name := 'Times New Roman';

    Canvas.Font.Style := [fsBold];

    Canvas.Font.Height := 69;

    GrayString(Canvas.Handle, Canvas.Brush.Handle, nil, LPARAM(PChar('Windows API')), 0, 20, 350, 0, 0);

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

    GrayString
    игнорирует ту кисть, которая выбрана в контексте устройства и использует свою. Здесь для простоты мы передаем ей кисть контекста устройства, но, в принципе, это могла бы быть любая другая кисть. Третий параметр — это указатель на функцию обратного вызова. В нашем случае он равен
    nil
    , что указывает на использование функции
    TextOut
    . Четвертый параметр имеет тип
    LPARAM
    и содержит произвольные данные, которые передаются функции обратного вызова. В случае использования
    TextOut
    это интерпретируется как указатель на строку, которую нужно вывести, поэтому здесь приходится возиться с приведением типов. Пятый параметр содержит длину выводимой строки. Это очень характерно для функций GDI, предназначенных для вывода текста, конец строки в них определяется не обязательно по завершающему символу
    #0
    , можно вывести только часть строки, явно задав нужное число символов. Но этот же параметр можно сделать равным нулю (как в нашем случае), и тогда длина строки определяется обычным образом — по символу #0. Прочие параметры функции определяют координаты выводимой строки.

    Последняя часть примера посвящена вопросу, который долгое время был очень популярен в форумах: как вывести текст, расположенный наклонно (в программе примером такого текста является надпись Sample, выведенная под углом 60 градусов). Это связано с тем, что только в BDS 2006 у класса TFont появилось свойство

    Orientation
    , позволяющее задавать направление текста (в справке BDS 2006 информация об этом свойстве отсутствует, она появляется только в справке Delphi 2007, но это свойство, тем не менее, есть и в BDS 2006, а также в Turbo Delphi). В более ранних версиях текст под углом можно было вывести только с помощью функций GDI, вручную создавая шрифт (листинг 1.9).

    Листинг 1.39. Вывод текста под углом средствами GDI

    // Следующая группа функций выводит надпись "Sample".

    // повернутую на угол 60 градусов.

    Canvas.Brush.Style := bsClear;

    // При создании логического шрифта для контекста

    // устройства следует в обязательном порядке указать

    // угол поворота. Однако класс TFont игнорирует такую

    // возможность, поэтому шрифт нужно создавать вручную.

    // Чтобы выбрать шрифт в контексте устройства, легче

    // всего присвоить его дескриптор свойству

    // Canvas.Font.Handle. Параметры fdwItalic, fdwUnderline

    // и fdwStrikeOut, согласно справке, могут принимать

    // значения True или False, но имеют тип DWORD. Для

    // С/C++ это не имеет значения - целый и логический типы

    // в этих языках совместимы. Но в Delphi приходится

    // использовать 0 и 1 вместо True и False. Угол поворота

    // шрифта задается в десятых долях градуса, т.е.

    // значение 600 означает 60 градусов.

    Canvas.Font.Handle := CreateFont(60, 0, 600, 600, FW_NORMAL, 0, 0, 0,

     ANSI_CHARSET, OUT_TT_PRECIS, CLIP_DEFAULT_PRECIS,

     DEFAULT_QUALITY, DEFAULT_РIТСН, 'Times New Roman');

    Canvas.TextOut(140, 320, 'Sample');

    // Эта строка нужна для того, чтобы пример работал

    // корректно в BDS2006 и выше. В этой версии у класса

    // TFont появилось свойство Orientation, задающее

    // направление текста, и этот класс научился определять

    // и сохранять это направление даже в том случае, если

    // оно было задано функцией GDI, а не через свойство

    // Orientation. Чтобы этого не происходило, нужно снова

    // придать шрифту горизонтальное направление. В версиях

    // Delphi, более ранних, чем BDS 2006, эта строка

    // не нужна: при изменении шрифта через класс TFont

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

    Canvas.Font.Handle := Create Font(60, 0, 0, 0, FW_NORMAL, 0, 0, 0,

     ANSI_CHARSET, OUT_TT_PRECIS, CLIP_DEFAULT_PRECIS,

     DEFAULT_QUALITY, DEFAULT_PITCH, 'Times New Roman');

    Новый шрифт создается функцией

    CreateFont
    . Если бы мы программировали без VCL, то полученный в результате вызова этой функции дескриптор шрифта необходимо было бы выбрать в контексте устройства (функция
    SelectObject
    ) и вывести надпись. Затем в устройстве следовало бы выбрать другой шрифт, а созданный ранее удалить. Но т.к. VCL мы все же используем, можно поступить проще: присвоить созданный дескриптор свойств
    Canvas.Font.Handle
    , а все остальное сделают классы
    TCanvas
    и
    TFont
    .

    Примечание

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

    Функция

    CreateFont
    имеет 14 параметров, определяющих свойства создаваемого шрифта. Мы не будем перечислять их все, отметим только, что мы здесь создаем шрифт на основе гарнитуры Times New Roman, имеющий размер 60 обычный (т.е. не жирный и не наклонный). О точных значениях всех параметров рекомендуем посмотреть в MSDN.

    Самые интересные для нас параметры — это третий (

    nEscapement
    ) и четвертый (
    nOrientation
    ), которые и определяют угол наклона шрифта. Они задаются в десятых долях градуса, т.е., чтобы получить нужное значение параметра, следует требуемое число градусов умножить на 10) (в нашем примере оба эти параметра равны 600, что означает 60 градусов). Параметр
    nEscapement
    задает угол поворота базовой линии текста относительно горизонтальной оси. Параметр
    nOrientation
    задаст угол поворота отдельных букв относительно своего нормального положения. По умолчанию в контекст устройства включен режим
    GM_COMPATIBLE
    при котором эти два значения должны совпадать, т.е. угол поворота надписи в целом и угол поворота отдельной буквы всегда совпадают. В Windows NT/2000/ХР с помощью функции
    SetGraphicsMode
    можно установить для контекста устройства режим
    GM_ADVANCED
    , при котором, в частности, параметры (
    nOrientation
    и
    nEscapement
    могут принимать различные значения (в Windows 9х/МЕ тоже есть функция
    SetGraphicsMode
    , но установить режим
    GM_ADVANCED
    она не позволяет). Когда мы присваиваем значение свойству
    TFont.Handle
    , все прочие свойства объекта TFont меняют свои значения в соответствии с тем, какой шрифт установлен. Так как в Delphi до 7-й версии свойство
    TFont.Orientation
    отсутствует, направление шрифта, установленное нами, в этом классе не запоминается, и поэтому при дальнейшем изменении шрифта с помощью свойств
    Canvas.Font.Name
    ,
    Canvas.Font.Size
    и т.п. мы снова получим горизонтальный шрифт. Другое дело — BDS 2006 и выше. В этих версиях направление шрифта тоже запоминается, и поэтому дальнейшие манипуляции со свойствами
    Canvas.Font
    будут снова давать наклонный шрифт, пока мы явно не присвоим значение 0 свойству
    Canvas.Font.Orientation
    . В нашем случае это означает, что при повторном вызове события
    OnPaint
    при вызове функции
    GrayString
    будет выведен наклонный текст, если не принять дополнительные меры. Как мы уже сказали, проблема легко решается присваиванием нуля свойству
    Canvas.Font.Orientation
    , но, т.к. наши примеры должны работать во всех версиях Delphi, начиная с пятой, этот вариант нам не подходит. Поэтому мы здесь вновь вручную создаем шрифт, на этот раз не важно, какой именно, главное, чтобы его параметры
    nOrientation
    и
    nEscapement
    были равны нулю. В Delphi до 7-й версии программа GDIDraw будет корректно работать и без второго вызова функции
    CreateFont
    .

    Отметим, что во всех версиях до Delphi 2007 как минимум, класс

    TFont
    имеет свойство
    Orientation
    , но не имеет свойства
    Escapement
    . Это означает, что если вы хотите вывести надпись, у которой угол наклона букв и угол наклона базовой линии будут разными, вам все-таки придется самостоятельно вызывать функцию
    CreateFont
    .

    1.2.8. Пример BitmapSpeed

    Программа BitmapSpeed предназначена для сравнения скорости работы с растровыми изображениями в формате DDB и DIB через класс

    TBitmap
    . Тестируются три операции: рисование прямых линий, вывод растра на экран и работа со свойством
    ScanLine
    . Окно программы показано на рис 1.12.

    Рис. 1.12. Окно программы BitmapSpeed после завершения теста


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

    DoTest
    , показанном в листинге 1.40.

    Листинг 1.40. Метод
    DoTest
    , выполняющий тесты скорости

    procedure TForm1.DoTest(Cnt, XOfs, ColNum: Integer; PixelFormat: TPixelFormat);

    { Cnt - число повторов операции при тестах

     XOfs - X-координата области, в которой будет выполняться вывод изображения во втором тесте

     ColNum - номер колонки в GridResults, в которую будут выводиться результаты

     Pixel Format - формат изображения }

    var

     Pict: TBitmap;

     I: Integer;

     P: Pointer;

     Freq, StartTime, EndTime: Int64;

    begin

     // Узнаем частоту условного счетчика тактов

     QueryPerformanceFrequency(Freq);

     // Создаем изображение

     Pict := TBitmap.Create;

     try

      Pict.PixelFormat := PixelFormat;

      Pict.Width := PictSize;

      Pict.Height := PictSize;

      Pict.Canvas.Pen.Width := 0;

      // Вывод линий на картинку

      // Выводится Cnt линий со случайными координатами

      QueryPerformanceCounter(StartTime);

      for I := 1 to Cnt do

      begin

       Pict.Canvas.Pen.Color :=

        RGB(Random(256), Random(256), Random(256));

       Pict.Canvas.MoveTo(Random(PictSize), Random(PictSize));

       Pict.Canvas.LineTo(Random(PictSize), Random(PictSize));

      end;

      QueryPerformanceCounter(EndTime);

      GridResults.Cells[ColNum, 1] :=

       FloatToStrF((EndTime - StartTime) / Freq * 1000, ffFixed, 10, 2);

      // Вызываем Application.ProcessMessages, чтобы GridResults

      // перерисовался в соответствии с новым значением ячейки

      Application.ProcessMessages;

      // Второй тест - вывод рисунка на экран

      QueryPerformanceCounter(StartTime);

      // Повторяем вывод рисунка на экран Cnt раз

      // Чтобы пользователь мог видеть, когда вывод

      // заканчивается, каждый раз добавляем к координатам

      // случайную величину

      for I := 1 to Cnt do

       Canvas.Draw(XOfs + Random(50), 10 + Random(50), Pict);

      QueryPerformanceCounter(EndTime);

      GridResults.Cells[ColNum, 2] :=

       FloatToStrF((EndTime - StartTime) / Freq + 1000, ffFixed, 10, 2);

      Application.ProcessMessages;

      // Третий тест - доступ к свойству ScanLine

      QueryPerformanceCounter(StartTime);

      // Обращаемся к случайной строке свойства ScanLine

      // Cnt раз

      for I := 1 to Cnt do

       P := Pict.ScanLine(Random(PictSize));

      QueryPerformanceCounter(EndTime);

      GridResults.Cells[ColNum, 3] :=

       FloatToStrF((EndTime - StartTime) / Freq * 1000, ffFixed, 10, 2);

      Application.ProcessMessages;

     finally

      Pict.Free;

     end;

    end;

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

    QueryPerformanceCounter
    , число тактов счетчика в секунду — с помощью функции
    QueryPerformanceFrequency
    . Этот счетчик позволяет получить более точные результаты, чем традиционно применяющаяся для таких целей функция
    GetTickCount
    . Теоретически, счетчик производительности может не поддерживаться аппаратной частью (в этом случае функция
    QueryPerformanceFrequency
    вернет нулевую частоту), однако все современные компьютеры такой счетчик поддерживают, поэтому его можно применять без опасений.

    В зависимости от параметра

    PixelFormat
    метод
    DoTest
    создает DDB- или DIB-изображение и тестирует скорость исполнения операций с ним. В первом тесте
    Cnt
    раз рисуется линия случайного цвета со случайными координатами — так проверяется скорость рисования на картинке. Разумеется, это весьма односторонний тест, т.к. при рисовании других примитивов будет, скорее всего, иное соотношение скоростей для DIB и DDB. Но общее представление о соотношении скоростей он все же дает.

    Во втором тесте полученное изображение

    Cnt
    раз выводится на экран. Если бы оно выводилось всегда в одном и том же месте, пользователь не видел бы процесс вывода на экран, т.к. каждый следующий раз картинка рисовалась бы точно в том же месте, что и в предыдущий, и общее изображение не менялось бы. Чтобы этого не происходило, изображение выводится со случайным смещением относительно базовых координат, и пользователь может наблюдать за процессом. Кроме того, координаты определяются также параметром XOfs — это сделано для того, чтобы при тестировании DDB- и DIB-изображений рисунки выводились в разных частях окна и не накладывались друг на друга.

    На некоторых компьютерах в этом тесте с DDB-изображением наблюдается интересный эффект: время, измеренное программой, заметно меньше, чем время, когда картинка меняется на экране (например, пользователь ясно видит, что тест выполняется в течение примерно трех секунд, в то время как программа дает значение около одной секунды). Это связано со способностью некоторых видеокарт буферизовать переданные им команды и выполнять их асинхронно, т.е. вызов функции завершается очень быстро, программа продолжает работать дальше, а видеокарта параллельно ей выполняет команду. Если вы столкнетесь с такой ситуацией, можете провести небольшой эксперимент: вставить вызов функции Beep сразу после окончания второго теста. Вы услышите звуковой сигнал раньше, чем изображение закончит меняться.

    Третий тест самый простой:

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

    Таким образом, метод

    DoTest
    нужно вызвать два раза: для DDB-изображения и для DIB это делает обработчик нажатия кнопки
    BtnStart
    (листинг 1.41).

    Листинг 1.41. Обработчик нажатия кнопки
    BtnStart

    procedure TForm1.BtnStartClick(Sender: TObject);

    var

     IterCnt, RandomStart: Integer;

    begin

     IterCnt := StrToInt(EditIter.Text);

     GridResults.Cells[1, 1] := '';

     GridResults.Cells[1, 2] := '';

     GridResults.Cells[1, 3] := '';

     GridResults.Cells[2, 1] := '';

     GridResults.Cells[2, 2] := '';

     GridResults.Cells[2, 3] := '';

     // Чтобы новый текст ячеек отобразился в GridResults,

     // нужно, чтобы было извлечено их очереди и обработано

     // сообщение WM_PAINT. Чтобы сделать это немедленно,

     // вызываем Application.ProcessMessages.

     Application.ProcessMessages;

     Random.Start := Random(MaxInt);

     Screen.Cursor := crHourGlass;

     // Точное измерение времени выполнения кода в Windows

     // невозможно, потому что это многозадачная система, и

     // часть измеренного времени может быть потрачена на

     // выполнение кода других процессов. Чтобы максимально

     // уменьшить погрешность измерения, нужно установить

     // наивысший приоритет процессу и его главной нити -

     // тогда вероятность переключения процессора на

     // выполнение другой задачи будет минимальным. Столь

     // высокий приоритет приводит к тому, что во время

     // выполнения теста система перестаёт реагировать на

     // перемещение мыши. Поэтому необходимо использовать блок

     // try/finally, чтобы даже при возникновении исключения

     // приоритет процесса и нити был снижен до нормального

     // уровня.

     SetThreadPriority(GetCurrentThread, THREAD_PRIORITY_TIME_CRITICAL);

     SetPriorityClass(GetCurrentProcess, REALTIME_PRIORITY_CLASS);

     try

      // В тестах активно используются псевдослучайные числа.

      // Чтобы сравнение было корректно, нужно, чтобы

      // последовательности чисел в экспериментах с DIB и DDB

      // были одинаковыми. Каждое следующее псевдослучайное

      // число генерируется на основе значения глобальной

      // переменной модуля System RandSeed. Значение RandSeed

      // при этом обновляется по определенному закону. Таким

      // образом, если установить определенное значение

      // RandSeed, то последовательность псевдослучайных чисел

      // будет строго детерминирована. Это свойство генератора

      // случайных чисел используется, чтобы в обоих

      // экспериментах были одинаковые последовательности.

      RandSeed := RandomStart;

      DoTest(IterCnt, 200, 1, pfDevice);

      RandSeed := RandomStart;

      DoTest(IterCnt, 450, 2, pf24bit);

     finally

      Screen.Cursor := crDefault;

      SetThreadPriority(GetCurrentThread, THREAD_PRIORITY_NORMAL);

      SetPriorityClass(GetCurrentProcess, NORMAL_PRIORITY_CLASS);

     end;

    end;

    Все три теста используют случайные числа. Чтобы условия были одинаковыми, нужно обеспечить идентичность последовательностей случайных чисел при тестировании DDB- и DIB-изображений. К счастью, этою легко добиться, установив перед тестированием одинаковые значения переменной

    RandSeed
    модуля
    System
    , которая и определяет последующее случайное число. Начальное значение
    RandSeed
    также выбирается случайным образом, а т.к. в обработчике события
    OnCreate
    формы есть вызов
    Randomize
    , при каждом запуске будет сгенерирована новая последовательность случайных чисел. Это одна из причин того, что результаты тестов будут меняться от запуска к запуску.

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

    Что касается самих результатов, то они, конечно, сильно зависят от конфигурации компьютера. По первым двум тестам время выполнения для DDB-растра может быть как в два-три раза меньше, чем для DIB, так и несколько превышать его. В третьем тесте DIB-растр, разумеется, существенно опережает по скорости DDB, хотя отношение и здесь зависит от компьютера. Также наблюдается некоторая зависимость от версии Delphi, под которой откомпилирован проект. Например, первый тест и для DIB, и для DDB выполняется несколько быстрее под Delphi 2007, чем под Delphi 5, а вот третий тест под Delphi 2007 выполняется несколько медленнее.

    1.3. Обобщающие примеры

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

    1.3.1. Обобщающий пример 1 — Информация о процессах

    Первым обобщающим примером станет программа для получения информации о процессах системы и об окнах, которые они открывают. На компакт-диске, прилагаемом к книге, эта программа называется ProcInfo. Окно программы ProcInfo показано на рис 1.13.

    Рис. 1.13. Окно программы ProcInfo

    1.3.1.1. Получение списка процессов

    Исторически сложилось так, что существует два способа получить список процессов: с помощью функций Tool Help и посредством функций PSAPI. Эти две группы функций использовались в разных линиях Windows: функции Tool Help появились в Windows 95, функции PSAPI — в Windows NT 4. Windows 2000 XP также поддерживают функции Tool Help, в то время как Windows 98/ME не поддерживают PSAPI. Поэтому мы выберем функции Tool Help, что даст нашему примеру возможность работать во всех версиях Windows, кроме NT 4 (впрочем, в Windows 95 пример тоже не будет работать, но по другой причине: из-за функций

    GetWindowInfo
    и
    RealGetWindowClass
    , отсутствующих в этой версии). Функции Tool Help объявлены в модуле
    TlHelp32

    Для получения списка процессов необходимо сделать "снимок" состояния системы с помощью функции

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

    Навигация по списку процессов, сохраненных в снимке, осуществляется с помощью функций

    Process32First
    и
    Process32Next
    . Они позволяют получить ряд параметров процесса, главный среди которых — идентификатор процесса (Process Identifier, PID). Это уникальный идентификатор процесса, с помощью которого можно отличать один процесс от другого. 

    Примечание

    Не следует путать идентификатор процесса и дескриптор объекта процесса, который используется, например, в функции

    SetPriorityClass
    . Объект процесса — это специальный объект, связанный с процессом, но не тождественный ему. В частности, объект процесса может продолжать существовать уже после того, как сам процесс завершит работу (это позволяет, например, корректно синхронизироваться с уже завершенным процессом при помощи функции
    WaitForSingleObject
    ). Через объект процесса можно управлять многими свойствами процесса. Поучить дескриптор объекта процесса по идентификатору процесса можно с помощью функции
    OpenProcess
    .

    Код для получения списка процессов показан в листинге 1.42.

    Листинг 1.42. Получение списка процессов с помощью Tool Help

    procedure TProcessesInfoForm.FillProcessList;

    var

     SnapProc: THandle;

     ProcEntry: TProcessEntry32;

     Item: TListItem;

    begin

     ClearAll;

     // Создаем снимок, в котором сохраняем все процессы, а

     // затем в цикле получаем информацию о каждом из этих

     // процессов, перенося ее в ListProcesses

     SnapProc := CreateToolhelp32Snapshot(TH32CS_SNAPROCESSES, 0);

     if SnapProc <> INVALID_HANDLE_VALUE then

     try

      ProcEntry.dwSize := SizeOf(TProcessEntry32);

      if Process32First(SnapProc, ProcEntry) then repeat

       Item := ListProcesses.Items.Add;

       Item.Caption := ProcEntry.szExeFile;

       Item.SubItems.Add(IntToStr(ProcEntry.tb32ProcessID);

       Item.SubItems.Add(IntToStr(ProcEntry.th32ParentProcessID));

       Item.SubItems.Add(IntToStr(ProcEntry.cntThreads));

       // Сохраняем PID в поле Data соответствующего

       // элемента списка. Вообще, поле Data имеет тип

       // Pointer, а PID - это целое число, но т.к. оба этих

       // типа 32-битные, их можно приводить друг к другу

       Item.Data := Pointer(ProcEntry.th32ProcessID);

      until not Process32Next(SnapProc, ProcEntry);

     finally

      CloseHandle(SnapProc);

     end

     else

     begin

      ListProcesses.Visible := False;

      LabelProcessError.Caption :=

       'Невозможно получить список процессов:'#13#10'Ошибка №' +

       IntToStr(GetLastError);

     end;

    end;

    Для получения списка модулей данного процесса также используется снимок. Функция

    CreateToolhelp32Snapshot
    вызывается с параметром
    TH32CS_SNAPMODULE
    , в качестве второго параметра ей передается PID процесса, модули которого требуется получить. Навигация по снимку модулей осуществляется с помощью функций
    Module32First
    и
    Module32Next
    . В остальном код получения списка модулей совпадает с кодом, приведенным в листинге 1.42.

    1.3.1.2. Получение списка и свойств окон

    Список окон, созданных процессом, формируется с помощью функции

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

    Для каждого из окон верхнего уровня, принадлежащих процессу, с помощью функции

    EnumChildWindows
    ищутся дочерние окна, а для каждого из найденных таким образом дочерних окон — его дочерние окна. Здесь следует учесть, что
    EnumChildWindows
    возвращает не только дочерние окна заданного окна, но и все окна, которыми владеют эти дочерние окна. Чтобы в дереве окон не было дублирования, при построении очередного уровня дерева окон отбрасываются все окна, непосредственным родителем которых не является данное окно. Код, выполняющий построение дерева, приведен в листинге 1.43.

    Листинг 1.43. Получение всех окон, относящихся к данному процессу

    function EnumWindowsProc(Wnd: HWnd; ParentNode: TTreeNode): BOOL; stdcall;

    var

     Text: string, TextLen: Integer;

     ClassName: array [0..ClassNameLen - 1] of Char;

     Node: TTreeNode; NodeName: string;

    begin

     Result := True;

     // функция EnumChildWindows возвращает список

     // не только прямых потомков окна, но и потомков его

     // потомков, поэтому необходимо отсеять все те окна,

     // которые не являются прямыми потомками данного

     if Assigned(ParentNode) and (THandle(ParentNode.Data) <> GetAncestor(Wnd, GA_PARENT)) then Exit;

     TextLen := GetWindowTextLength(Wnd);

     SetLength(Text, TextLen);

     if TextLen > 0 then GetWindowText(Wnd, PChar(Text), TextLen + 1);

     if TextLen > 100 then Text := Copy(Text, 1, 100) + '...';

     GetClassName(Wnd, ClassName, ClassNameLen);

     ClassName[ClassNameLen - 1] := #0;

     if Text = '' then NodeName := 'Без названия (' + ClassName + ')';

     else NodeName := Text + ' (' + ClassName + ')';

     NodeName := '$' + IntToHex(Wnd, 8) + ' ' + NodeName;

     Node := ProcessesInfoForm.TreeWindows.Items.AddChild(ParentNode, NodeName);

     Node.Data := Pointer(Wnd);

     EnumChildWindows(Wnd, @EnumWindowsProc, LParam(Node));

    end;


    function EnumTopWindowsProc(Wnd: HWnd; PIDNeeded: Cardinal): BOOL; stdcall;

    var

     Text: string;

     TextLen: Integer;

     ClassName: array[0..ClassNameLen - 1] of Chars;

     Node: TTreeNode;

     NodeName: string;

     WndPID: Cardinal;

    begin

     Result := True;

     // Здесь отсеиваются окна, которые не принадлежат

     // выбранному процессу

     GetWindowThreadProcessID(Wnd, @WndPID);

     if WndPID = PIDNeeded then

     begin

      TextLen := GetWindowTextLength(Wnd);

      SetLength(Text, TextLen);

      if TextLen > 0 then GetWindowText(Wnd, PChar(Text), TextLen + 1);

      if TextLen > 100 then Text := Copy(Text, 1, 100) + '...';

      GetClassName(Wnd, ClassName, ClassNameLen);

      ClassName[ClassNameLen - 1] := #0;

      if Text = '' then NodeName := 'Без названия (' + ClassName + ')'

      else NodeName := Text + ' (' + ClassName + ')';

      NodeName := '$' + IntToHex(Wnd, 8) + ' ' + NodeName;

      Node := ProcessesInfoForm.TreeWindows.Items.AddChild(nil, NodeName);

      Node.Data := Pointer(Wnd);

      EnumChildWindows(Wnd, @EnumWindowsProc, LParam(Node));

     end;

    end;


    procedure TProcessesInfoForm.FillWindowList(PID: Cardinal);

    begin

     if PID = 0 then Exit;

     EnumWindows(@EnumTopWindowsProc, PID);

    end;

    В отличие от примера

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

    Примечание

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

    CreateWindow(Ex)
    позволяет при создании нового окна использовать в качестве родительского окно другого процесса. Поэтому наш код ошибочно отнесет подобные окна к тому процессу, к которому относятся их родители, а не к тому, который их реально создал. Здесь мы пренебрегаем такой возможностью, потому что для ее учета не нужны дополнительные знания API, необходимо просто запрограммировать более сложный алгоритм отсева. В учебном примере, посвященном API, реализация такого алгоритма была бы неоправданным усложнением. но в реальных программах эту возможность следует учесть.

    Для получения названия окна в приведенном коде используется функция

    GetWindowText
    . Эта функция безопасна при работе с зависшими приложениями, поскольку она гарантирует, что вызвавшее ее приложение не зависнет само, пытаясь получить ответ от зависшего приложения. Но
    GetWindowText
    не всегда может получить названия элементов управления, расположенных в окнах чужих приложений (точнее, в MSDN написано, что она вообще не может получать названия элементов управления в чужих окнах, но практика показывает, что нередко
    GetWindowText
    все же делает это). Существует альтернативный способ получения названия окна — отправка ему сообщения
    WM_GETTEXT
    . При этом ограничений на работу с чужими элементами управления нет, но и гарантии, что из-за отсутствия ответа от чужого приложения программа не зависнет, тоже нет.

    Использование

    WM_GETTEXT
    показано в другой части программы — при заполнении списка параметров окна, отображающегося в правом нижнем углу формы. Чтобы программа не зависала, вместо
    SendMessage
    для отправки
    WM_GETTEXT
    применяется
    SendMessageTimeout
    . Код получения имени показан в листинге 1.44.

    Листинг 1.44. Получение заголовков "чужих" окон

    if SendMessageTimeout(Wnd, WM_GETTEXTLENGTH, 0, 0,

     SMTO_NORMAL or SMTO_ABORTIFHUNG, 5000, TextLen) = 0 then

    begin

     LastError := GetLastError;

     if LastError = 0 then Text := 'Приложение не отвечает'

     else

    Text:= 'Ошибка при получении длины заголовка: ' + IntToStr(LastError);

    end

    else

    begin

     SetLength(Text, TextLen);

     if TextLen > 0 then

      if SendMessageTimeout(Wnd, WM_GETTEXT, TextLen + 1, LParam(Text),

       SMTO_NORMAL or SMTO_ABORTIFHUNG, 5000, TextLen) = 0 then

      begin

       LastError := GetLastError;

       if LastError = 0 then Text := 'Приложение не отвечает'

       else Text := 'Ошибка при получении заголовка:' + IntToStr(LastError);

      end;

    end;

    Для каждого окна программа выводит имя оконного класса и реальный класс окна. В большинстве случаев эти два класса совпадают. Они различаются только для тех окон, чьи классы "унаследованы" от стандартных классов, таких как

    EDIT
    ,
    COMBOBOX
    и т.п.

    Вообще, наследования оконных классов в Windows нет. Но существует один нехитрый прием, который позволяет имитировать наследование. Оконная процедура обычно не обрабатывает все сообщения, а передает часть их в одну из стандартных оконных процедур (

    DefWindowProc
    ,
    DefFrameProc
    и т.п.). Программа может с помощью функции
    GetClassInfo
    узнать адрес оконной процедуры, назначенной стандартному классу, и использовать ее вместо стандартной оконной процедуры. Так как большая часть свойств окна определяется тем, как и какие сообщения оно обрабатывает, использование оконной процедуры другого класса позволяет почти полностью унаследовать свойства этого класса. (В VCL для наследования оконных классов существует метод
    TWinControl.CreateSubClass
    .) Функция
    RealGetWindowClass
    позволяет узнать имя класса-предка, если такой имеется. Соответствующая часть кода примера приведена в листинге 1.45.

    Листинг 1.45. Получение реального класса окна

    GetClassName(Wnd, ClassName, ClassNameLen);

    ClassName[ClassNameLen - 1] := #0;

    ListParams.Items[2].SubItems[0] := ClassName;

    RealGetWindowClass(Wnd, ClassName, ClassNameLen);

    ClassName[ClassNameLen - 1] := #0;

    ListParams.Items[3].SubItems[0] := ClassName;
     

    У окна, если оно имеет стиль

    WS_CHILD
    , должно быть родительское окно. Если такого стиля нет, то окно располагается непосредственно на рабочем столе. Кроме того, такое окно может (но не обязано) иметь владельца. Получить дескриптор родительского окна можно с помощью функции
    GetParent
    . Владельца — с помощью функции
    GetWindow
    с параметром
    GW_OWNER
    .

    Примечание

    Кроме

    GetParent
    существует функция
    GetAncestor
    , которая также возвращает дескриптор родительского окна, если она вызвана с параметром
    GA_PARENT
    . Разница между этими функциями заключается в том. что для окон верхнего уровня (т.е. расположенных непосредственно на рабочем столе)
    GetParent
    возвращает 0, a
    GetAncestor
    — дескриптор рабочего стопа (этот дескриптор можно получить через функцию
    GetDesktopWindow
    ).

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

    ES_NOHIDESEL
    и
    BS_LEFT
    имеют одинаковые значения. Поэтому при расшифровке стиля следует также учитывать класс окна. Приводить здесь этот код мы не будем по причине его тривиальности. Его можно посмотреть в примере на компакт-диске.

    1.3.2. Обобщающий пример 2 — Ассоциированные файлы и предотвращение запуска второй копии приложения

    Расширения файлов могут быть связаны (ассоциированы) с определенной программой. Такие ассоциации помогают системе выбрать программу для выполнения различных действий с файлом из Проводника. Так, например, если на компьютере установлен Microsoft Office, двойной щелчок в Проводнике на файле с расширением xls приведет к запуску Microsoft Excel и открытию файла в нем. Это происходит потому, что расширение xls ассоциировано с приложением Microsoft Excel.

    Примечание

    Добиться аналогичного эффекта в своей программе можно используя функцию

    ShellExecute
    (стандартная системная функция, в Delphi импортируется в модуле
    ShellAPI
    ). Эта функция запускает файл, имя которого передано ей как параметр. Если это исполняемый файл, он запускается непосредственно, если нет — функция ищет ассоциированное с расширением файла приложение и открывает файл в нем. 

    Пример, который мы здесь рассмотрим (программа DKSView), умеет ассоциировать файлы с расширением dks с собой, а также проверять, не были ли они ассоциированы с другим приложением. DKSView является MDI-приложением, т.е. может открывать одновременно несколько файлов. Если приложение уже запущено, а пользователь пытается открыть еще один dks-файл, желательно, чтобы он открывался не в новом экземпляре DKSView, а в новом окне уже имеющегося. Поэтому наш пример будет также уметь обнаруживать уже запущенный экземпляр программы и переадресовывать открытие файла ему.

    1.3.2.1. Ассоциирование расширения с приложением

    Файловые ассоциации прописываются в реестре, в разделе

    HKEY_CLASSES_ROOT
    . Чтобы связать расширение с приложением, необходимо выполнить следующие действия:

    1. В корне раздела

    HKEY_CLASSES_ROOT
    нужно создать новый раздел, имя которого совладает с расширением с точкой перед ним (в нашем случае это будет раздел с именем ".dks"). В качестве значения по умолчанию в этот раздел должна быть записана непустая строка, которая будет идентифицировать соответствующий тип файла. Содержимое этой строки может быть произвольным и определяется разработчиком (в нашем случае эта строка имеет значение "DKS_View_File").

    2. Далее в корне раздела

    HKEY_CLASSES_ROOT
    следует создать раздел, имя которого совпадает со значением ключа из предыдущего пункта (т.е. в нашем случае — с именем "DKS_View_File"). В качестве значения по умолчанию для этого ключа нужно поставить текстовое описание типа (это описание будет показываться пользователю в Проводнике в качестве типа файла).

    3. В этом разделе создать подраздел Shell, в нем — подраздел Open, а в нем — подраздел Command, значением по умолчанию которого должна стать командная строка для запуска файла. Имя файла в ней заменяется на %1 (подробнее о командной строке чуть ниже).

    4. Описанных действий достаточно, чтобы система знала, как правильно открывать файл из Проводника или с помощью

    ShellExecute
    . Однако правила хорошего тона требуют, чтобы с файлом была ассоциирована также иконка, которую будет отображать рядом с ним Проводник. Для этого в разделе, созданном во втором пункте, следует создать подраздел "DefaultIcon" и в качестве значения по умолчанию задать ему имя файла, содержащего иконку. Если это ico-файл, содержащий только одну иконку, к имени файла ничего добавлять не нужно. Если иконка содержится в файле, в котором может быть несколько иконок (например, в exe или dll), после имени файла следует поставить запятую и номер требуемой иконки (иконки нумеруются, начиная с нуля).

    Приведенный список — это самый минимальный набор действий, необходимых для ассоциирования расширения с приложением. Вернемся к третьему пункту. Имя подраздела "Open" задает команду, связанную с данным расширением, т.е. в данном случае — команду "Open". В разделе Shell можно сделать несколько аналогичных подразделов — в этом случае с файлом будет связано несколько команд. У функции

    ShellExecute
    есть параметр
    lpOperation
    , в котором задается имя требуемой команды. Пользователь Проводника может выбрать одну из возможных команд через контекстное меню, которое появляется при нажатии правой кнопки мыши над файлом. Существует возможность установить для этих пунктов меню более дружественные имена. Для этого нужно задать значение по умолчанию соответствующего подраздела. В этой строке допустим символ "&" для указания "горячей" клавиши, аналогично тому, как это делается, например, в компоненте
    TButton
    .

    Если в

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

    В нашем примере будет две команды: Open (открыть для редактирования) и View (открыть для просмотра). Поэтому информация в реестр заносится так, как показано в листинге 1.46.

    Листинг 1.46. Занесение в реестр информации, необходимой для ассоциирования файла с приложением

    const

     FileExt = '.dks';

     FileDescr = 'DKS_View_File'.

     FileTitle = 'Delphi Kingdom Sample file';

     OpenCommand = '&Открыть';

     ViewCommand = '&Просмотреть';


    // Занесение в реестр информации об ассоциации

    // Расширения dks с программой

    procedure TDKSViewMainForm.SetAssociation(Reg: TRegistry);

    begin

     Reg.OpenKey('\' + FileExt, True);

     Reg.WriteString('' , FileDescr);

     Reg.OpenKey('\' + FileDescr, True);

     Reg.WriteString(FileTitle);

     Reg.OpenKey('Shell', True);

     Reg.OpenKey('Open', True);

     Reg.WriteString('', OpenCommand);

     Reg.OpenKey('command', True);

     Reg.WriteString('', '"' + ParamStr(0) + '" "%1"');

     Reg.OpenKey('\' + FileDescr, True);

     Reg.OpenKey('Shell', True);

     Reg.OpenKey('View', True);

     Reg.WriteString('', ViewCommand);

     Reg.OpenKey('command', True);

     Reg.WriteString('' + ParamStr(0) + '" "%1" /v');

     Reg.OpenKey('\' + FileDescr, True);

     Reg.OpenKey('DefaultIcon', True);

     Reg.WriteString('', ParamStr(0) + ',0');

    end;

    1.3.2.2. Командная строка

    Командная строка досталась Windows по наследству от DOS. Там основным средством общения пользователя с системой был ввод команд с клавиатуры. Команда запуска приложения выглядела так:

    <Имя приложения> <Строка параметров>

    Строка параметров — это произвольная строка, которая без изменений передавалась программе. От имени программы она отделялась пробелом (пробелы в именах файлов и директорий в DOS не допускались). Разработчик конкретного приложения мог, в принципе, интерпретирован, эту строку как угодно, но общепринятым стал способ, когда строка разбивалась на отдельные параметры, которые разделялись пробелами. Вид и смысл параметров зависел от конкретной программы. В качестве параметров нередко передавались имена файлов, с которыми должна была работать программа.

    В Windows мало что изменилось — функции

    CreateProcess
    и
    ShellExecute
    , запускающие приложение, по-прежнему используют понятие командной строки. Разве что теперь максимальная длина строки стала существенно больше, и командную строку можно получить в кодировке Unicode. Но, как и раньше, разделителем параметров считается пробел. Однако теперь пробел может присутствовать и в имени файла, как в имени самой программы, так и в именах файлов, передаваемых в качестве параметров. Чтобы отличать такой пробел от пробела-разделителя, параметры, содержащие пробелы, заключаются в двойные кавычки. Если имя программы содержит пробелы, они тоже заключаются в двойные кавычки. И, конечно же, если в кавычки окажется заключенным параметр, в котором нет пробелов, хуже от этого не будет.

    Для работы с параметрами командной строки в Delphi существуют две стандартные функции:

    ParamCount
    и
    ParamStr
    . Функция
    ParamCount
    возвращает количество параметров, переданных в командной строке.
    ParamStr
    — параметр с заданным порядковым номером. Параметры нумеруются начиная с единицы, нулевым параметром считается имя самой программы (при подсчетах с помощью
    ParamCount
    этот "параметр" не учитывается). Эти функции осуществляют разбор командной строки по описанным ранее правилам: разделитель —пробел, за исключением заключенных в кавычки. Кавычки, в которые заключен параметр, функция
    ParamStr
    не возвращает.

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

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

    <Имя программы> "%1"

    Если существуют разные варианты запуска одного файла (т.е. как в нашем случае — open и view), они различаться дополнительным параметрами. В частности, в нашем примере для открытия для редактирования не будут требоваться дополнительные параметры, для открытия для просмотра в качестве второго параметра должен передаваться кляч v, т.е. в реестр для этой команды будет записана такая строка:

    <Имя программы> "%1" v

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

    Листинг 1.47. Анализ командной строки

    procedure TDKSViewMainForm.FormShow(Sender: TObject);

    var

     OpenForView: Bооlean;

    begin

     // Проверяем наличие ключа "/v" в качестве второго параметра

     OpenForView := (ParamCount > 1) and (CompareText(ParamStr(2), '/v') = 0);

     if ParamCount > 0 then OpenFile(ParamStr(1), OpenForView);

     ...

    end;

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

    1.3.2.3. Поиск уже запущенной копии приложения

    Во многих случаях желательно не давать пользователю возможности запустить второй экземпляр вашего приложения. В 16-разрядных версиях Windows все приложения выполнялись в одной виртуальной машине, и каждому из них через переменную

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

    Для обнаружения уже запущенного приложения многие авторы предлагают использовать именованные системные объекты (мьютексы, семафоры, атомы и т.п.). При запуске программа пытается создать такой объект с определенным именем. Если оказывается, что такой объект уже создан, программа "понимает", что она — вторая копия, и завершается. Недостаток такого подхода — с его помощью можно установить только сам факт наличия предыдущей копии, но не более того. В нашем случае задача шире: при запуске второго экземпляра приложения должен активизироваться первый, а если второму экземпляру была передана непустая командная строка, первый должен получить эту строку и выполнить соответствующее действие, поэтому описанный способ нам не подходит.

    Для решения задачи нам подойдут почтовые ящики (mailslots). Это специальные системные объекты для односторонней передачи сообщений между приложениями (ничего общего с электронной почтой эти почтовые ящики не имеют). Под сообщением здесь понимаются не сообщения Windows, а произвольный набор данных (здесь больше подходит скорее термин "дейтаграмма", а не "сообщение"). Каждый почтовый ящик имеет уникальное имя. Алгоритм отслеживания повторного запуска с помощью почтового ящика следующий. Сначала программа пытается создать почтовый ящик как сервер. Если оказывается, что такой ящик уже существует, то она подключается к нему как клиент и передает содержимое своей командной строки и завершает работу. Сервером в таком случае становится экземпляр приложения, запустившийся первым, — он-то и создаёт почтовый ящик. Остальным экземплярам останется только передать ему данные.

    Примечание

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

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

    Листинг 1.48 Создание почтового ящика в главном файле проекта

    const

     MailslotName = '\\.\mailslot\DelphiKingomSample_Viewer_FileCommand';

     EventName = 'DelphiKingdomSamplе_Viewer_Command_Event';


    var

     ClientMailslotHandle: THandle;

     Letter: string;

     OpenForView: Boolean;

     BytesWritten: DWORD;

    begin

     // Пытаемся создать почтовый ящик

     ServerMailslotHandle := CreateMailSlot(MailslotName, 0,

      MAILSLOT_WAIT_FOREVER, nil);

     if ServerMailslotHandle = INVALID_HANDLE_VALUE then

     begin

      if GetLastError = ERROR_ALREADY_EXISTS then

      begin

       // Если такой ящик уже есть, подключаемся к нему, как клиент

       ClientMailslotHandle := CreateFile(MailslotName, GENERIC_WRITE,

        FILE_SHARE_READ, nil, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0);

       // В зависимости от того, какие переданы параметры, формируем

       // строку для передачи предыдущему экземпляру. Первый символ

       // строки - команда:

       // e - открыть файл для редактирования

       // v — открыть файл для просмотра

       // s — просто активизировать предыдущий экземпляр

       // Для команд e и v к строке, начиная со 2-го символа,

       // добавляется имя файла

       if ParamCount > 0 then

       begin

        OpenForView := (ParamCount > 1) and

         (CompareText(ParamStr(2), '/v') = 0);

        if OpenForView then Letter := 'v' + ParamStr(1)

        elsе Letter := 'e' + ParamStr(1);

       end

       else Letter := 's';

       // Отправляем команду в почтовый ящик

       WriteFile(ClientMailslotHandle, Letter[1], Length(Letter),

        BytesWritten, nil);

       // Сигнализируем об отправке данных через специальное событие

       CommandEvent := OpenEvent(EVENT_MODIFY_STATE, False, EventName);

       SetEvent(CommandEvent);

       // Закрываем все дескрипторы

       CloseHandle(CommandEvent);

       CloseHandle(ClientMailslotHandle);

      end;

     end

     else

     begin

      // Создаем событие для сигнализирования о поступлении  данных

      CommandEvent := CreateEvent(nil, False, False, EventName);

      // Выполняем обычный для VCL-приложений цикл

      Application.Initialize;

      Application.CreateForm(TDKSViewMainForm, DKSViewMainForm);

      Application.Run;

      // Закрываем все дескрипторы

      CloseHandle(ServerMailslotHandle);

      CloseHandle(CommandEvent);

     end;

    end.

    Теперь осталось "научить" первую копию приложения обнаруживать момент, когда в почтовом ящике оказываются сообщения, и забирать их оттуда. Было бы идеально, если при поступлении данных главная форма получала бы какое-то сообщение, но готового такого механизма, к сожалению, не существует. Из положения можно выйти, задействовав события.

    Примечание

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

    WaitForSingleObject
    можно перевести нить в состояние ожидания до тех пор. пока указанное событие не будет взведено. Подробное рассмотрение объектов синхронизации выходит за рамки нашей книги; они детально описаны, например, в [2].

    В принципе, при использовании перекрытого ввода-вывода система может сама взводить указанное программой событие при получении данных почтовым ящиком, но перекрытый ввод-вывод имеет ограниченную поддержку в Windows 9х/МЕ и на почтовые ящики не распространяется. Чтобы приложение могло работать не только в Windows NT/2000/XP, мы не будем применять перекрытый ввод-вывод.

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

    CreateEvent
    создает событие, а последующие копии с помощью
    OpenEvent
    получают дескриптор этого события и взводят его. чтобы послать сигнал о появлении данных в почтовом ящике. Для обнаружения этого момента в первой копии приложения создается отдельная нить, которая ожидает событие и, дождавшись, посылает главной форме сообщение (эта нить практически не требует процессорного времени, потому что почти все время находится в режиме ожидания, т.е. квант времени планировщик задач ей не выделяет, по крайней мере, проверка наличие данных в главной нити по таймеру отняла бы больше ресурсов). Это сообщение определяется пользователем и берется из диапазона
    WM_USER
    , т.к. его широковещательной рассылки не будет. При получении этого сообщения форма выполняет код, приведенный в листинге 1.49.

    Листинг 1.49. Реакция формы на поступление данных в почтовый ящик

    // Реакция на получение команд от других экземпляров приложения

    procedure TDKSViewMainForm.WMCommandArrived(var Message: TMessage);

    var

     Letter: string;

    begin

     // Переводим приложение на передний план

     GoToForeground;

     // Пока есть команды, читаем их и выполняем

     Letter := ReadStringFromMailslot;

     while Letter <> '' do

     begin

      // Анализируем и выполняем команду.

      // Команда "s" не требует никаких действий, кроме перевода

      // приложения на передний план, поэтому здесь мы ее не учитываем

      case Letter[1] of

      'e': OpenFile(Copy(Letter, 2, MaxInt), False);

      'v': OpenFile(Copy(Letter, 2, MaxInt), True);

      end;

      Letter := ReadStringFronMailslot;

     end;

    end;


    // Чтение очередного сообщения из почтового ящика

    function TDksViewMainForm.ReadStringFromMailslot: string;

    var

     MessageSize: DWORD;

    begin

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

     GetMailslotInfo(ServerMailslotHandle, nil, MessageSize, nil, nil);

     // Если сообщения нет, возвращаем пустую строку

     if MessageSize = MAILSLOT_NO_MESSAGE then

     begin

      Result := '';

      Exit;

     end;

     // Выделяем для сообщения буфер и читаем его в этот буфер

     SetLength(Result, MessageSize);

     ReadFile(ServerMailslotHandle, Result[1], MessageSize, MessageSize, nil);

    end;

    Примечание

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

    1.3.2.4. Перевод приложения на передний план

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

    SetForegroundWindow
    мы можем вывести туда любое окно. Однако так было только до Windows 95 и NT 4. В более поздних версиях введены ограничения, и теперь программа не может вывести себя на передний план по собственному усмотрению. Функция
    SetForegroundWindow
    просто заставит мигать соответствующую кнопку на панели задач.

    Тем не менее, если программа свернута, команда

    Application.Restore
    не только восстанавливает окно, но и выводит его на передний план, что нам и требуется. Ну а если программа не свернута, то "выливаем из чайника воду и тем самым сводим задачу к предыдущей": сначала сворачиваем приложение с помощью
    Application.Minimize
    , а потом разворачиваем его. Цели мы добились — главное окно на переднем плане.

    Дело портит только то, что изменение состояния окна сопровождается анимацией: видно, как главное окно сначала сворачивается, а потом разворачивается. Чтобы убрать этот неприятный эффект, можно на время сворачивания/разворачивания окна запретить анимацию, а потом восстановить ее. С учетом этого метод

    GoToForeground
    выглядит так, как показано в листинге 1.50.

    Листинг 1.50. Перевод приложения на передний план

    // Перевод приложения на передний план

    procedure TDKSViewMainForm.GoToForeground;

    var

     Info: TAnimationInfo;

     Animation: Boolean;

    begin

     // Проверяем, включена ли анимация для окон

     Info.cbSize := SizeOf(TAnimationInfo);

     Animation := SystemParametersInfo(SPI_GETANIMATION,

      SizeOf(Info), @Info, 0 and (Info.iMinAnimate <> 0);

     // если включена, отключаем, чтобы не было ненужного мерцания

     if Animation then

     begin

      Info.iMinAnimate := 0;

      SysteParametersInfo(SPI_SETANIMATION, SizeOf(Info), @Info, 0);

     end;

     // Если приложение не минимизировано, минимизируем

     if not IsIconic(Application.Handle) then Application.Minimize;

     // Восстанавливаем приложение. При этом оно автоматически выводится

     // на передний план

     Application.Restorе;

     // Если анимация окон была включена, снова включаем ее

     if Animation than

     begin

      Info.iMinAnimate := 1;

      SystemParametersInfo(SPI_SETANIMATION, SizeOf(Info), @Info, 0);

     end;

    end;

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

    1.3.3. Обобщающий пример 3 — "Дырявое" окно

    В этом примере мы создадим "дырявое" окно. Те, кто уже знаком с функцией

    SetWindowRgn
    , знает, что сделать "дырку" в окне или придать ему какую-либо другую необычную форму не так уж и сложно. Но мы здесь пойдем дальше: у дырки в нашем окне будет рамка, и пользователь сможет изменять размеры и положение дырки так же, как он может изменять положение и размеры окна. Как это выглядит, показано на рис. 1.14.

    Рассмотрим те средства, которые нам понадобятся для реализации этого.

    1.3.3.1. Сообщение WM_NCHCHITTEST

    Каждое окно в Windows делится на две области: клиентскую и не клиентскую. Клиентской называется та область, в которой отображается содержимое окна. Неклиентская область — это различные служебные области окна: рамка, заголовок, полосы прокрутки, главное меню и т.п. Положение клиентской части окна относительно неклиентской определяет само окно при обработке сообщения

    WM_NCCALCRECT
    . Многие окна (особенно различные элементы управления) вообще не имеют неклиентской части.

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

    WM_PAINT
    , а неклиентской —
    WM_NCPAINT
    . Нажатие левой кнопки мыши над клиентской частью окна генерирует сообщение
    WM_LBUTTONDOWN
    , а над неклиентской —
    WM_NCLBUTTONDOWN
    и т.п. Неклиентская область неоднородна: в нее входит заголовок, кнопки сокрытия, разворачивания и закрытия окна, иконка системного меню, главное меню, вертикальная и горизонтальная полосы прокрутки и рамка. Рамка тоже неоднородна — она имеет левую, правую, верхнюю и нижнюю границы и четыре угла. Сообщение
    WM_NCCALCSIZE
    позволяет выяснить, какая область окна является неклиентской, но не позволяет узнать, где какая часть неклиентской области находится. Эта задача решается с помощью другого сообщения —
    WM_NCHITTEST
    . В качестве входных параметров
    WM_NCHITTEST
    получает координаты точки, а результат кодирует, к какой части окна относится эта точка (например,
    HTCLIENT
    означает, что точка принадлежит к клиентской части окна,
    HTCAPTION
     — к заголовку,
    HTLEFT
    — к левой границе рамки, меняющей размер, и т.п.).

    Рис. 1.14. "Дырявое" окно


    При любых событиях от мыши система начинает с того, что посылает окну сообщение

    WM_NCHITTEST
    с координатами положения мыши. Получив результат, система решает, что делать дальше. В частности, при нажатии левой кнопки мыши окну посылается
    WM_NCHITTEST
    . Затем, если результатом был
    HTCLIENT
    , посылается сообщение
    WM_LBUTTONDOWN
    , в противном случае —
    WM_NCLBUTTONDOWN
    . При каждом перемещении мыши окно также получает
    WM_NCHITTEST
    — это позволяет системе постоянно отслеживать, над какой частью окна находится курсор, при необходимости меняя его вид (как, например, при прохождении курсора над рамкой).

    Что будет, если подменить обработчик

    WM_NCHITTEST
    ? Например, так, чтобы при попадании точки в клиентскую часть окна он возвращал не
    HTCLIENT
    , а
    HTCAPTION
    ? Это приведет к тому, что любые события от мыши над клиентской областью будут восприниматься так же, как над заголовком. Например, можно будет взять окно за клиентскую часть и переместить его, а двойной щелчок на ней приведет к разворачиванию окна. Однако это полностью блокирует нормальную реакцию на мышь, потому что вместо клиентских "мышиных" сообщений окно будет получать неклиентские.

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

    WM_NCHITTEST
    можно сделать более интеллектуальным и получить довольно интересные эффекты. Например, положив на форму панель и переопределив у панели обработчик
    WM_NCHITTEST
    таким образом, чтобы при нахождении мыши около границ панели возвращался результат, соответствующий различным частям рамки с изменяемым размером, можно получить панель, размеры которой пользователь программы сможет изменять: система будет реагировать на эту область панели как на обычную рамку, которую можно взять и потянуть. (Пример такой панели можно увидеть в статье "Компонент, который меняет свои размеры в режиме run-time аналогично тому, как это происходит в design-time" http://www.delphikingdom.com/asp/viewitem.asp?catalogid=22.) Фантазия может подсказать и многие другие способы получения интересных эффектов с помощью
    WM_NCHITTEST
    .

    1.3.3.2. Регионы

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

    CreateRectRgn
    ,
    CreateEllipticRgn
    ,
    CreatePolygonRgn
    и т.п.), а также функция
    СombineRgn
    для объединения регионов различными способами. Все это вместе позволяет получать регионы любых форм. Область применения регионов достаточно широка. Ранее мы уже видели, как с помощью регионов можно ограничить область вывода графики. Здесь же мы будем с помощью функции
    SetWindowRgn
    изменять форму окна, придавая ему форму заданного региона.

    1.3.3.3. Сообщения WM_SIZE и WM_SIZING

    События

    WM_SIZE
    и
    WM_SIZING
    позволяют окну реагировать на перемещение его пользователем. В "классическом" варианте, когда пользователь начинает тянуть рамку окна, на экране рисуется "резиновый" прямоугольник, соответствующая сторона или угол которого движется за курсором мыши. Окно получает сообщение
    WM_SIZING
    при каждом изменении размера этого прямоугольника. Параметр
    lParam
    при этом содержит указатель на структуру
    TRect
    с новыми координатами прямоугольника. Окно может не только прочитать эти координаты, но и изменить их, блокировав тем самым нежелательные изменения размера. На этом, в частности, основано использование свойства
    Constraints
    : если размер окна при перемещении становится меньше или больше заданного, при обработке сообщения
    WM_SIZING
    размер увеличивается или уменьшается до необходимого. Параметр
    wParam
    содержит информацию о том, за какую сторону или угол тянет пользователь, чтобы программа знала, координаты какого из углов прямоугольника нужно смещать, если возникнет такая необходимость.

    После того как пользователь закончит изменять размеры окна и отпустит кнопку мыши, окно получает сообщение

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

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

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

    1.3.3.4. А теперь — все вместе

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

    Для начала объявим несколько констант, которые нам потребуются при вычислении размеров дырки и т.п. (листинг 1.51).

    Листинг 1.51. Константы примера WndHole

    const

     // минимальное расстояние от дырки до края окна

     HoleDistance = 40;

     // Зона чувствительности рамки панели - на сколько пикселов

     // может отстоять курсор вглубь от края панели, чтобы его

     // положение расценивалось как попадание в рамку.

     BorderMouseSensivity = 3;

     // Зона чувствительности угла рамки панели - на сколько пикселов

     // может отстоять курсор от угла панели, чтобы его

     // положение расценивалось как попадание в угол рамки.

     CornerMouseSensivity = 15;

     // Толщина рамки дырки, использующаяся при вычислении региона

     HoleBorder = 3;

     // Минимальная ширина и высота дырки

     MinHoleSize = 10;

     // Смещение стрелки относительно соответствующего угла

     ArrowOffset = 8;

    Теперь приступаем к созданию программы. На форму "кладем" панель. С помощью функции

    SetWindowRgn
    устанавливаем такую форму окна, чтобы от панели была видна только рамка, а на всю внутреннюю часть панели пришлась дырка. Рамку выбираем такую, чтобы панель выглядела утопленной, так края дырки будут выглядеть естественней. Для расчета региона используется метод
    SetRegion
    (листинг 1.52), он вызывается всегда, когда нужно изменить регион окна.

    Листинг 1.52. Метод
    SetRegion
    , устанавливающий регион окна

    procedure TFormHole.SetRegion;

    var

     Rgn1, Rgn2: HRGN;

     R, R2: TRect;

    begin

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

     Rgn1 := CreateRectRgn(0, 0, Width, Height);

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

     // верхнего угла окна (а не относительно левого верхнего

     // угла клиентской области, как это задается свойствами

     // Left и Тор). Функций для получения смещения клиентской

     // области относительно левого верхнего угла окна нет.

     // Придется воспользоваться сообщением WM_NCCalcRect

     R2 := Rect(Left, Top, Left + Width, Top + Height);

     Perform(WM_NCCALCSIZE, 0, LParam(@R2));

     // Переводим координаты полученного прямоугольника из

     // экранных в координаты относительно левого верхнего

     // угла окна

     OffsetRect(R2, -Left, -Top);

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

     // верхнего угла клиентской области и пересчитываем их

     // в координаты относительно верхнего левого угла окна

     R := Rect(0, 0, PanelHole.Width, PanelHole.Height);

     OffsetRect(R, PanelHole.Left + R2.Left, PanelHole.Top + R2.Top);

     // уменьшаем прямоугольник на величину рамки и создаем

     // соответствующий регион

     InflateRect(R, -HoleBorder, -HoleBorder);

     Rgn2 := CreateRectRgnIndirect(R);

     // вычитаем один прямоугольный регион из другого, получая

     // прямоугольник с дыркой

     CombineRgn(Rgn1, Rgn1, Rgn2, RGN_DIFF);

     // уничтожаем вспомогательный регион

     DeleteObject(Rgn2);

     // Назначаем регион с дыркой окну

     SetWindowRgn(Handle, Rgn1, True);

     // обратите внимание, что регион, назначенный окну, нигде

     // не уничтожается. После выполнения функции SetWindowRgn

     // регион переходит в собственность системы, и она сама

     // уничтожит его при необходимости

    end;

    Сообщения, поступающие с панели, перехватываются через ее свойство

    WindowProc
    (подробно эта технология описана в первой части данной главы, здесь мы ее касаться не будем). Сообщение
    WM_NCHITTEST
    будем обрабатывать так, чтобы при попадании мыши на рамку панели возвращались такие значения, чтобы за эту рамку можно было тянуть. В обработчике сообщения
    WM_SIZE
    панели изменяем регион так, чтобы он соответствовал новому размеру панели. Все, дырка с изменяемыми размерами готова. Теперь нужно научить "дырку" менять размеры при изменении размеров окна, если окно стало слишком маленьким, чтобы вместить в себя дырку. Осталось только немного "навести красоту". "Красота" заключается в том, чтобы пользователь не мог уменьшить размеры дырки до нуля и увеличить так, чтобы она вышла за пределы окна, а также уменьшить окно так. чтобы дырка оказалась за пределами окна. Первая из этих задач решается просто: добавляется обработчик сообщения
    WM_SIZING
    для дырки таким образом, чтобы ее размеры не могли стать меньше, чем
    MinHoleSize
    на
    MinHoleSize
    пикселов, а границы нельзя было придвинуть к границам окна ближе, чем на
    HoleDistance
    пикселов. Вторая задача решается еще проще: в обработчике
    WM_SIZE
    дырки меняем свойство
    Constraints
    формы таким образом, чтобы пользователь не мог слишком сильно уменьшить окно. Теперь окно с дыркой ведет себя корректно при любых действиях пользователя с дыркой. Получившийся в результате код обработчика сообщений панели приведен в листинге 1.53.

    Листинг 1.53. Обработчик сообщений панели, образующей "дырку"

    procedure TFormHole.PanelWndProc(var Msg: TMessage);

    var

     Pt: TPoint;

     R: TRect;

    begin

     POldPanelWndProc(Msg);

     if Msg.Msg = WM_NCHITTEST then

     begin

      // Вся хитрость обработки сообщения WM_NCHITTEST

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

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

      // мыши на сторону рамки или в ее угол. Дело упрощается

      // тем, что у панели нет неклиентской части, поэтому

      // верхний левый угол окна и верхний левый угол клиентской

      // части совпадают.

      Pt := PanelHole.ScreenToClient(Point(Msg.LParamLo, Msg.LParamHi));

      if Pt.X < BorderMouseSensivity then

       if Pt.Y < CornerMouseSensivity then Msg.Result := HTTOPLEFT

       else

        if Pt.Y >= PanelHole.Height - CornerMouseSensivity then

    Msg.Result := HTBOTTOMLEFT

        else Msg.Result := HTLEFT

       else

        if Pt.X >= PanelHole.Width - BorderMouseSensivity then

         if Pt.Y < CornerMouseSensivity then Msg.Result := HTTOPRIGHT

         else

          if Pt.Y >= PanelHole.Height - CornerMouseSensivity then

           Msg.Result := HTBOTTOMRIGHT

          else Msg.Result := HTRIGHT

        else

         if Pt.Y < BorderMouseSensivity then

          if Pt.X < CornerMouseSensivity then Msg.Result := HTTOPLEFT

          else

           if Pt.X >= PanelHole.Width - CornerMouseSensivity then

            Msg.Result := HTTOPRIGHT

           else Msg.Result := HTTOP

         else

    if Pt.Y >= PanelHole.Height - BorderMouseSensivity then

           if Pt.X < CornerMouseSensivity then

            Msg.Result := HTBOTTOMLEFT

           else

            if Pt.X >= PanelHole.Width - CornerMouseSensivity then

             Msg.Result := HTBOTTOMRIGHT

            else Msg. Result := HTBOTTOM;

     end

     else if Msg.Msg = WM_SIZE then

     begin

      // Пересчитываем регион SetRegion;

      // Устанавливаем новые ограничения для размеров окна.

      // учитывающие новое положение дырки

      Constraints.MinWidth :=

       Width - ClientWidth + PanelHole.Left + MinHoleSize + HoleDistance;

      Constraints.MinHeight :=

       Height - ClientHeight + PanelHole.Top + MinHoleSize + HoleDistance;

     end

     else if Msg.Msg = WM_SIZING then

     begin

      // Копируем переданный прямоугольник в переменную R,

      // одновременно пересчитывая координаты из экранных

      // в клиентские

      R.TopLeft := ScreenToClient(PRect(Msg.LParam)^.TopLeft);

      R.BottomRight := ScreenToClient(PRect(Msg.LParam)^.BottomRight);

      // Если ширина слишком мала, проверяем, за какую

      // сторону тянет пользователь. Если за левую -

      // корректируем координаты левой стороны, если за

      // правую - ее координаты

      if R.Right - R.Left < MinHoleSize then

       if Msg.WParam in [WMSZ_BOTTOMLEFT, WMSZ_LEFT, WMSZ_TOPLEFT] then

        R.Left := R.Right - MinHoleSize

       else

        R.Right := R.Left + MinHoleSize;

        // Аналогично действуем, если слишком мала высота

        if R.Bottom - R.Top < MinHoleSize then

         if Msg.WParam in [WMSZ_TOP, WMSZ_TOPLEFT, WMSZ_TOPRIGHT] then

          R.Top := R.Bottom - MinHoleSize

         else R.Bottom := R.Top + MinHoleSize;

      // Сдвигаем стороны, слишком близко подошедшие

      // к границам окна

      if R.Left < HoleDistance then R.Left := HoleDistance;

      if R.Top < HoleDistance then R.Top := HoleDistance;

      if R.Right > ClientWidth - HoleDistance then

       R.Right := ClientWidth - HoleDistance;

      if R.Bottom > ClientHeight - HoleDistance then

       R.Bottom := ClientHeight - HoleDistance;

      // Копируем прямоугольник R, переводя его координаты

      // обратно в экранные

      PRect(Msg.LParam)^.TopLeft := ClientToScreen(R.TopLeft);

      PRect(Msg.LParam)^.BottomRight := ClientToScreen(R.BottomRight);

     end;

    end;

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

    WM_SIZE
    окна (листинг 1.54).

    Листинг 1.54. Обработчик сообщения
    WM_SIZE
    главного окна

    procedure TFormHole.WMSize(var Msg: TWMSize);

    begin

     inherited;

     // При уменьшении размеров окна уменьшаем размер дырки,

     // если границы окна подошли слишком близко к ней

     if PanelHole.Left + PanelHole.Width > ClientWidth - HoleDistance then

      PanelHole.Width := ClientWidth - HoleDistance - PanelHole.Left;

     if PanelHole.Top + PanelHole.Height > ClientHeight - HoleDistance then

      PanelHole.Height := ClientHeight - HoleDistance - PanelHole.Top;

     // На случай увеличения окна пересчитываем его регион,

     // иначе та часть, которая добавилась, окажется за его

     // пределами и будет отрезана SetRegion;

     // Пересчитываем координаты стрелок

     CalculateArrows;

     Invalidate;

    end;

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

    Листинг 1.55. Расчет координат стрелок

    // координаты верхней левой стрелки, отсчитанные от точки

    // (0,0). Для получения координат реальных стрелок эти точки

    // будут смещаться и отражаться

    const

     ArrowTemplate: TArrowCoords = (

      (X:0; Y:0), (X:24; Y:0), (X:17; Y:7), (X:29; Y:19),

      (X:19; Y:29), (X:7; Y:17), (X:0; Y:24));


    procedure TFomHole.CalculateArrows;

    var

     Arrow: TArrowCoords;

     I: Integer;

    begin

     // Вычисление региона левой верхней стрелки

     // Координаты просто смещаются на постоянную величину

     for I := 0 to High(Arrow) do

     begin

      Arrow[I].X := ArrowTemplate[I].X + ArrowOffset;

      Arrow[I].Y := ArrowTemplate[I].Y + ArrowOffset;

     end;

     // При необходимости уничтожаем старый регион

     if ArrowTopLeft <> 0 then DeleteObject(ArrowTopLeft);

     ArrowTopLeft :=

      CreatePolygonRgn(Arrow[0], Length(Arrow), WINDING);

     // Вычисление региона правой верхней стрелки

     // Координаты по X отражаются и смещаются

     // на постоянную величину относительно правого края окна

     for I := 0 to High(Arrow) do

     begin

      Arrow[I].X := ClientWidth - ArrowOffset - 1 - ArrowTemplate[I].X;

      Arrow[I].Y := ArrowTemplate[I].Y + ArrowOffset;

     end;

     if ArrowTopRight <> 0 then DeleteObject(ArrowTopRight);

     ArrowTopRight := CreatePolygonRgn(Arrow[0], Length(Arrow), WINDING);

     // Вычисление региона левой нижней стрелки

     // Координаты по Y отражаются и смещаются

     // на постоянную величину относительно нижнего края окна

     for I := 0 to High(Arrow) do

     begin

      Arrow[I].X := ArrowTemplate[I].X + ArrowOffset;

      Arrow[I].Y := ClientHeight - ArrowOffset - 1 - ArrowTemplate[I].Y;

     end;

     if ArrowBottomLeft <> 0 then DeleteObject(ArrowBottomLeft);

     ArrowBottomLeft := CreatePolygonRgn(Arrow[0], Length(Arrow), WINDING);

     // Вычисление региона правой нижней стрелки

     // Координаты по обеим осям отражаются и смещаются

     // на постоянную величину относительно правого нижнего угла окна

     for I := 0 to High(Arrow) do

     begin

      Arrow[I].X := ClientWidth - ArrowOffset - 1 - ArrowTemplate[I].X;

      Arrow[I].Y := ClientHeight - ArrowOffset - 1 - ArrowTemplate[I].Y;

     end;

     if ArrowBottomRight <> 0 then DeleteObject(ArrowBottomRight);

     ArrowBottomRight := CreatePolygonRgn(Arrow[0], Length(Arrow), WINDING);

    end;

    Следующий шаг — рисование стрелки на форме. Делается это очень просто (листинг 1.56).

    Листинг 1.56. Рисование стрелок на форме

    procedure TFormHole.FormPaint(Sender: TObject);

    begin

     // Закрашиваем регионы стрелок

     Canvas.Brush.Style := bsSolid;

     Canvas.Brush.Color := clRed;

     FillRgn(Canvas.Handle, ArrowTopLeft, Canvas.Brush.Handle);

     FillRgn(Canvas.Handle, ArrowTopRight, Canvas.Brush.Handle);

     FillRgn(Canvas.Handle, ArrowBottomLeft, Canvas.Brush.Handle);

     FillRgn(Canvas.Handle, ArrowBottomRight, Canvas.Brush.Handle);

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

    WM_NCHITTEST
    . Вопрос только в том, как узнать, когда координаты мыши попадают внутрь нарисованной стрелки, поскольку стрелка является объектом сложной формы, вычислить это не очень просто. Данная задача также решается с помощью регионов: попадание координат курсора в регион каждой из стрелок отслеживается с помощью стандартной функции
    PtInRegion
    (листинг 1.57).

    Листинг 1.57. Обработчик
    WM_NCHITTEST
    формы

    procedure TFormHole.WMNCHitTest(var Msg: TWMNCHitTest);

    var

     Pt: TPoint;

    begin

     // Чтобы правильно обрабатывать стандартную неклиентскую область,

     // вызываем унаследованный обработчик

     inherited;

     // Не забываем, что параметры WM_NCHITTEST дают экранные,

     // а не клиентские координаты

     Pt := ScreenToClient(Point(Msg.XPos, Msg.YPos));

     // Проверяем координаты на попадание в регионы стрелок

     if PtInRegion(ArrowTopLeft, Pt.X, Pt.Y) then

      Msg.Result := HTTOPLEFT

     else if PtInRegion(ArrowTopRight, Pt.X, Pt.Y) then

      Msg.Result := HTTOPRIGHT

     else

      if PtInRegion(ArrowBottomLeft, Pt.X, Pt.Y) then

       Msg.Result := HTBOTTOMLEFT

      else

       if PtInRegion(ArrowBottomRight, Pt.X, Pt.Y) then

        Msg.Result := HTBOTTOMRIGHT;

    end;

    Вот и все. С помощью нескольких нехитрых приемов мы получили окно, которое имеет такой необычный вид (см. рис. 1.14).

    1.3.4. Обобщающий пример 4 — Линии нестандартного стиля

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

    1.3.4.1. Получение координат точек прямой

    Рисование нестандартных линий выполняется следующим образом: вычисляются координаты всех пикселов, составляющих данную прямую, а потом каждый из них (а при необходимости — и какая-либо его окрестность) раскрашиваются нужным цветом. Следовательно, возникает вопрос об определении координат пикселов.

    Существует ряд алгоритмов вычисления этих координат. Наиболее известный из них — алгоритм Брезенхэма (Bresengham), который заключается в равномерном разбрасывании "ступенек" разной длины вдоль линии. В Windows используется алгоритм GIQ (Grid Intersection Quantization). Каждый пиксел окружается воображаемым ромбом из четырех пикселов. Если прямая имеет общие точки с этим ромбом, то пиксел рисуется.

    Самостоятельно реализовывать один из таких алгоритмов нет необходимости — в Windows существует функция

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

    В примере Lines (рис. 1.15) с помощью

    LineDDA
    рисуется пять различных типов линий. Рассмотрим на примере самого сложного из реализуемых программой типов линии ("Зеленая елочка"), как это делается (листинг 1.58).

    Рис. 1.15. Окно программы Lines


    Листинг 1.58. Рисование линии сложного стиля

    // константы для типа "Зеленая елочка"

    const

     // Угол отклонения "иголки" от направления линии

     FirNeedleAngle = 30;

     //Длина иголки

     FirNeedleLength = 8;


    var

     Counter: Integer; // Счетчик точек линии

     // Вспомогательные переменные для построения "елочки"

     DX1, DY1, DX2, DY2: Integer;


    // Линия в виде "елочки"

    procedure LineDrawFir(X, Y: Integer; Canvas: TCanvas); stdcall;

    begin

     with Canvas do case Counter mod 10 of

      0: begin

       MoveTo(X, Y);

       LineTo(X + DX1, Y + DY1);

      end;

      5:

      begin

       MoveTo(X, Y);

       LineTo(X + DX2, Y + DY2);

      end;

     end;

     Inc(Counter);

    end;


    procedure TLinesForm.Line(X1, Y1, X2, Y2: Integer);

    var

     Angle: Extended;

    begin

     case RGroupLine.ItemIndex of

      ...

      4:

     begin

       Counter := 0;

       Angle := ArcTan2(Y2 - Y1, X2 - X1);

       DX1 := Round(FirNeedleLength *

        Cos(Angle + Pi / 180 * FirNeedleAngle));

       DY1 := Round(FirNeedleLength *

        Sin(Angle + Pi / 180 * FirNeedleAngle));

       DX2 := Round(FirNeedleLength *

        Cos(Angle - Pi / 180 * FirNeedleAngle));

       DY2 := Round(FirNeedleLength *

        Sin(Angle - Pi / 180 * FirNeedleAngle));

       LineDDA(X1, Y1, X2, Y2, @LineDrawFir, Integer(Canvas));

      end;

     end;

    end;

    Каждая "иголка" — это линия длиной

    FirNeedleLength
    пикселов, отклоняющаяся от направления прямой на угол
    FirNeedleAngle
    градусов. "Иголки" отклоняются попеременно то в одну, то в другую сторону от прямой. В процедуре
    Line
    сначала рассчитываются смещения координат конца "иголки" относительно начала и результаты помещаются в глобальные переменные
    DX1
    ,
    DY1
    ,
    DX2
    ,
    DY2
    . Переменная
    Counter
    служит для определения номера точки. Перед вызовом
    LineDDA
    она инициализируется нулем. Затем вызывается функция
    LineDDA
    , в качестве одного из параметров которой передается указатель на функцию обратного вызова
    LineDrawFir
    . В результате этого функция
    LineDrawFir
    будет вызвана последовательно для каждого из пикселов, составляющих линию, начиная с (X1, Y1).
    LineDrawFir
    ведет подсчет пикселов, каждый раз увеличивая
    Counter
    на единицу. Если остаток от деления номера точки на 10 равен 0, рисуется "иголка", отклоняющаяся в положительном направлении, если 5 — в отрицательном. В остальных случаях не рисуется ничего. Так получается "елочка".

    1.3.4.2. "Резиновая" линия и растровые операции

    Теперь нужно дать пользователю возможность рисовать линии. Для этого мы используем стандартную "резиновую" линию: пользователь нажимает левую кнопку мыши и, удерживая ее, передвигает мышь. До тех пор, пока кнопка удерживается, за курсором тянется линия. Как только пользователь отпускает кнопку, линия "впечатывается" в рисунок.

    Сама по себе реализация "резиновой" линии очень проста: при наступлении события

    OnMouseDown
    запоминаются координаты начала линии и взводится флаг, показывающий, что включен режим рисования "резиновой" линии. Также запоминаются координаты конца отрезка, который на данный момент совпадает с началом. В обработчике
    OnMouseMove
    , если включен режим рисования "резиновой" линии, стирается линия со старыми координатами конца и рисуется с новыми. При наступлении
    OnMouseUp
    программа выходит из режима рисования "резиновой" линии, рисуя окончательный ее вариант с текущими координатами конца.

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

    Для решения этой задачи мы здесь рассмотрим самый простой метод — инверсное рисование (более сложный метод будет рассмотрен чуть позже). При этом каждая точка, принадлежащая линии, закрашивается не каким-либо фиксированным цветом, а инвертируется (т.е. к текущему цвету точки применяется операция

    not
    ). Для стирания линии просто рисуем ее еще раз: двойная инверсия восстанавливает предыдущий цвет точек (
    not not X = X
    для любого X).

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

    R2_COPYPEN
    , в которой цвет фона игнорируется, а результирующий цвет пиксела совпадает с цветом пера или кисти. Изменить растровую операцию можно с помощью функции
    SetROP2
    (двойка в названии функции показывает, что устанавливаемая растровая операция имеет два аргумента — цвет рисования и цвет фона: при выводе растровых рисунков могут применяться растровые операции с тремя аргументами — см. функцию
    BitBlt
    ). Нас будет интересовать операция
    R2_NOT
    , которая инвертирует фоновый цвет, игнорируя цвет пера или кисти.

    Примечание

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

    SetPixel
    (и, соответственно, изменение цвета с помощью
    Canvas.Pixels[X, Y]
    ), т.к. эта операция выполняется с мощью кистей.

    Код, рисующий "резиновую" линию, приведен в листинге 1.59.

    Листинг 1.59. Рисование "резиновой" линии инверсным методом

    procedure TLinesForm.FormMouseDown(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Integer);

    begin

     if Button = mbLeft then begin

      OldX := X;

      OldY := Y;

      BegX := X;

      BegY := Y;

      LineDrawing := True;

     end;

    end;


    procedure TLinesForm.FormMouseMove(Sender: TObject; Shift: TShiftState; X, Y: Integer);

    begin

     if LineDrawing and ((X <> OldX) or (Y <> OldY)) then

      with Canvas do

     begin

      SetROP2(Handle, R2_NOT);

      Line(BegX, BegY, OldX, OldY); // Стираем старую линию.

      Line(BegX, BegY, X, Y); // Рисуем новую.

      OldX := X;

      OldY := Y;

     end;

    end;


    procedure TLinesFom.FormMouseUp(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Integer);

    begin

     if (Button = mbLeft) and LineDrawing then

     begin

      case RGroupLine.ItemIndex of

      2: Canvas.Pen.Color := clBlue;

      3: begin

       Canvas.Brush.Color := clRed;

       Canvas.Pen.Color := clRed;

      end;

      4: Canvas.Pen.Color := clGreen;

      end;

      Line(BegX, BegY, X, Y);

      LineDrawing := False;

     end;

    end;

    Обратите внимание, что резиновая линия следует за мышью даже тогда, когда мышь выходит за пределы формы, т.е. форма получает сообщения мыши, когда курсор находится за ее пределами. Это становится возможным благодаря захвату мыши окном. Любое окно в Windows может захватить мышь для монопольного использования, и тогда все сообщения от мыши будет получать это окно, независимо от того, где находится курсор. В VCL любой визуальный компонент, у которого установлен стиль

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

    1.3.4.3. Кривые Безье

    Сделаем следующий шаг — научимся рисовать произвольным стилем не только прямые, но и кривые. Проще всего это сделать с так называемыми кривыми Безье — они, во-первых, поддерживаются системой Windows, а во-вторых, ими можно аппроксимировать многие другие кривые (в частности, в Windows NT/2000 XP все кривые — окружности, эллипсы, дуги — аппроксимируются кривыми Безье).

    Теорию кривых Безье разработал П. де Кастело в 1959 году и, независимо от него, П. Безье в 1962 году. Для построения кривой Безье N-го порядка необходимо N+1 точек, две из которых определяют концы кривой, а остальные N-1 называются опорными. В компьютерной графике наибольшее распространение получили квадратичные кривые Безье, строящиеся по трем точкам, и кубические кривые Безье, строящиеся по четырем точкам. Квадратичные кривые Безье используются, например, в шрифтах TrueType при определении контуров символов. Windows API позволяет строить только кубические кривые Безье.

    Кубические кривые Безье задаются следующей формулой:

    P(t) = А(1-t)³ + 3Bt(1-t)² + 3Ct²(1-t)+Dt³ (1)

    где А — начало кривой, D — ее конец, а В и С — первая и вторая опорные точки. Прямая АВ касательная к кривой в точке А, прямая CD — в точке D. Параметр t изменяется от 0 до 1. При t = 0 P(t) = А, при t = 1 P(t) = D.

    Одним из важнейших свойств кривой Безье является ее делимость. Если кривую разделить на две кривых в точке t = 0,5, каждая из полученных кривых также будет являться кривой Безье. На этом свойстве основывается алгоритм рисования кривых Безье: если кривая может быть достаточно точно аппроксимирована прямой, рисуется отрезок прямой, если нет — она разбивается на две кривых Безье, к каждой из которых вновь применяется этот алгоритм. Для рисования кривых Безье служат функции

    PolyBezier
    ,
    PolyBezierTo
    и
    PolyDraw
    .

    В некоторых случаях удобно строить кривую Безье не по опорным точкам, а по точкам, через которые она должна пройти. Пусть кривая начинается в точке А, при t=⅓ проходит через точку В', при t=⅔  — через точку С', и заканчивается в точке D. Подставляя эти точки в уравнение (1), получаем систему, связывающую В' и С' с В и С . Решая систему, получаем

     (2)

    Из этих уравнений, в частности, следует, что для любых четырех точек плоскости существует, и притом единственная, кривая Безье, которая начинается в первой точке, проходит при t=⅓ через вторую точку, при t=⅔ — через третью и завершается в четвертой точке. Аналогичным образом можно вычислить опорные точки для кривой, которая должна проходить через заданные точки при других значениях t.

    1.3.4.4. Траектории 

    API Windows реализует поддержку специфических объектов, называемых траекториями (path). Траектория представляет собой запись движения пера и включает один или несколько замкнутых контуров. Каждый контур состоит из отрезков прямых и кривых Безье. Для построения траектории в Windows NT/2000/XP могут быть задействованы все графические функции рисования прямых, кривых и замкнутых контуров, а также функции вывода текста (в этом случае замкнутые контуры будут совпадать с контурами символов). В Windows 9x/Me могут быть использованы только функции рисования прямых, ломаных, многоугольников (за исключением

    PolyDraw
    и
    Rectangle
    ), кривых Безье и функций вывода текста. Функции рисования эллипсов, окружностей и эллиптических дуг не могут быть использованы для создания траектории в Windows 9x/Me, т.к. в этих системах эллиптические кривые рисуются специальным алгоритмом, а не аппроксимируются кривыми Безье. Для создания траектории предусмотрены функции
    BeginPath
    и
    EndPath
    . Все вызовы графических функций, расположенные между
    BeginPath
    и
    EndPath
    , вместо вывода в контекст устройства будут создавать в нем траекторию.

    После того как траектория построена, ее можно отобразить или преобразовать. Мы не будем здесь перечислять все возможные операции с траекториями, остановимся только на преобразовании траектории в ломаную. Как уже отмечалось, все контуры траектории представляют собой набор отрезков прямых и кривых Безье. С другой стороны, при построении кривой Безье она аппроксимируется ломаной. Следовательно, вся траектория может быть аппроксимирована набором отрезков прямой. Функция

    FlattenPath
    преобразует кривые Безье, входящие в состав траектории, в ломаные линии. Таким образом, после вызова этой функции траектория будет состоять из отрезков прямой.

    Отметим также некоторые другие преобразование траектории, полезные для создания графических редакторов и подобных им программ. Функция

    PathToRegion
    позволяет преобразовать траекторию в регион. Это может понадобиться, в частности, при определении того обстоятельства, попадает ли курсор мыши в область объекта, представляемого сложной фигурой. Функция
    WidenPath
    превращает каждый контур траектории в два контура — внутренний и внешний. Расстояние между ними определяется толщиной текущего пера. Таким образом, траектория как бы утолщается. После преобразования утолщенной траектории в регион можно определить, попадает ли курсор мыши на кривую с учетом погрешности, определяемой толщиной пера.

    Получить информацию о точках текущей траектории можно с помощью функции

    GetPath
    . Для каждой точки траектории эта функция возвращает координаты и тип точки (начальная линии, замыкающая точка отрезка, точка кривой Безье, конец контура).

    Таким образом, создав траекторию из кривой Безье (

    BeginPath/PoliBezier/EndPath
    ), мы можем преобразовать эту траекторию в ломаную (
    FlattenPath
    ), а затем получить координаты угловэтой ломаной (
    GetPath
    ). А каждое звено этой ломаной мы можем нарисовать произвольным стилем, используя
    LineDDA
    . Таким образом, задача построения кривой Безье сведена к уже решенной задаче построения отрезка.

    В листинге 1.60 реализован метод

    DrawCurve
    , выполняющий указанные действия. Здесь
    FCurve
    — это поле формы типа
    TCurve
    , в котором хранятся координаты четырех точек, образующих кривую.

    Листинг 1.60. Работа с траекторией на основе кривой Безье

    type

     // Тип TCurve хранит координаты кривой в следующем порядке: начало,

     // первую промежуточную точку, вторую промежуточную точку, конец

     TCurve = array[0..3] of TPoint;


    // Функция обратного вызова для LineDDA

    procedure LineDrawFunc(X, Y: Integer; Canvas: TCanvas); stdcall;

    begin

     case CurveForm.RGroupType.ItemIndex of

     // Разноцветные шарики

     0: if CurveForm.FCounter mod 10 = 0 then

     begin

      Canvas.Pen.Style := psSolid;

      Canvas.Pen.Width := 1;

      Canvas.Brush.Style := bsSolid;

      if CurveForm.FCounter mod 15 = 0 then Canvas.Pen.Color := clBlue

      else if CurveForm.FCounter mod 15 = 5 then Canvas.Pen.Color := сlLime

      else Canvas.Pen.Color := clRed;

      Canvas.Brush.Color := Canvas.Pen.Color;

      Canvas.Ellipse(X - 2, Y - 2, X + 3, Y + 3);

     end;

     // Поперечные полосы

     1: it CurveForm.FCounter mod 5 = 0 then

     begin

      Canvas.Pen.Style := psSolid;

      Canvas.Pen.Width := 1;

      Canvas.Pen.Color := clBlue;

      Canvas.MoveTo(X - CurveForm.FDX, Y - CurveForm.FDY);

      Canvas.LineTo(X + CurveForm.FDX, Y + CurveForm.FDY);

     end;

     // Плакатное перо

     2: begin

      Canvas.Pen.Style := psSolid;

      // Предположим, некоторая точка прямой имеет координаты (X, Y),

      // а соседняя с ней - координаты (Х+1, Y-1). Тогда при проведении

      // через эти точки наклонной линии одинарной ширины между ними

      // останутся незаполненные точки, как на шахматной доске.

      // Поэтому потребовалось увеличить толщину пера

      Canvas.Pen.Width := 2;

      Canvas.Pen.Color := clBlack;

      Canvas.MoveTo(X - 5, Y - 5);

      Canvas.LineTo(X + 6, Y + 6);

     end;

     // Цепочка

     3: begin

      case CurveForm.FCounter mod 15 of

      0: begin

       Canvas.Pen.Style := psSolid;

       Canvas.Pen.Width := 1;

       Canvas.Pen.Color := clBlack;

       Canvas.Brush.Style := bsClear;

       Canvas.Ellipse(X - 5, Y - 5, X + 6, Y + 6);

      end;

      2..13: Canvas.Pixels[X, Y] := clBlack;

      end;

     end;

     end;

     Inc(CurveForm.FCounter);

    end;


    procedure TCurveForm.DrawCurve(Canvas: TCanvas);

    var

     LCurve: TCurve;

     I, Size: Integer;

     PtBuf: array of TPoint;

     TpBuf: array of Byte;

     L: Extended;

    begin

     // LCurve хранит координаты начала и конца кривой и ее

     // опорных точек. Если включен режим рисования по опорным

     // точкам, LCurve совпадает с FCurve, если включен режим

     // рисования по точкам кривой, опорные точки LCurve[1]

     // и LCurve[2] рассчитываются по приведенным в книге

     // формулам на основании точек FCurve

     LCurve := FCurve;

     if RGroupDrawMethod.ItemIndex = 1 then

     begin

      LCurve[1].X :=

       Round((-5 * FCurve[0].X + 18 * FCurve[1].X -

       9 * FCurve[2].X + 2 * FCurve[3].X) / 6);

      LCurve[1].Y :=

       Round((-5 * FCurve[0].Y + 18 * FCurve[1].Y -

       9 * FCurve[2].Y + 2 * FCurve[3]-Y) / 6);

      LCurve[2].X :=

       Round((2 * FCurve[0].X - 9 * FCurve[1].X +

       18 * FCurve[2].X - 5 * FCurve[3].X) / 6);

      LCurve[2].Y :=

       Round((2 * FCurve[0].Y - 9 * FCurve[1].Y +

       18 * FCurve[2].Y - 5 * FCurve[3].Y) / 6);

     end;

     // Создаем траекторию на основе кривой

     BeginPath(Canvas.Handle);

     Canvas.PolyBezier(LCurve);

     EndPath(Canvas.Handle);

     // Аппроксимируем траекторию отрезками прямых

     FlattenPath(Canvas.Handle);

     // Получаем число точек траектории. Так как сами точки никуда

     // пока не копируются, в качестве фиктивного буфера можно указать

     // любую переменную. В данном случае - переменную I

     Size := GetPath(Canvas.Handle, I, I, 0);

     // Выделяем память для хранения координат и типов точек траектории

     SetLength(PtBuf, Size);

     SetLength(TpBuf, Size);

     // Получаем координаты и типы точек. Типы точек нас в данном случае

     // не интересуют: у первой точки будет тип PT_MOVETO,

     // а у остальных - PT_LINETO. Появление PT_MOVETO у других точек

     // невозможно, т.к. траектория содержит только один замкнутый

     // контур, состояний из кривой и соединяющей ее концы прямой.

     // Появление точек типа PT_BEZIERTO также исключено, т.к. после

     // вызова FlattenPath контур содержит только отрезки прямых.

     // Поэтому значения, записанные в TpBuf, будут в дальнейшем

     // игнорироваться

     GetPath(Canvas.Handle, PtBuf[0], TpBuf[0], Size);

     FCounter := 0;

     // Рисуем по отдельности каждый из отрезков, составляющих контур

     for I := 1 to Size - 1 do

     begin

      // Вычисляем длину отрезка

      L :=

       Sqrt(Sqr(PtBuf[I - 1].X - PtBuf[I].X) +

       Sqr(PtBuf[I - 1].Y - PtBuf[I].Y));

      // Практика показала, что аппроксимированный контур может

      // содержать отрезки нулевой длины - видимо, это издержки

      // алгоритма аппроксимации. Так как в дальнейшем нам придется

      // делить на L, такие отрезки мы просто игнорируем, т.к.

      // на экране они все равно никак не отображаются

      if L > 0 then begin

       // переменные FDX и FDY используются только при рисовании

       // линии типа "поперечные полосы". Если бы линии этого

       // типа не было, то FDX, FDY, а так же L можно было бы

       // не рассчитывать

       FDX := Round (4 * (PtBuf[I - 1].Y - PtBuf[I].Y) / L);

       FDY := Round(4 * (PtBuf[I].X - PtBuf[I - 1].X) / L);

       LineDDA(PtBuf[I - 1].X, PtBuf[I - 1].Y, PtBuf[I].X, PtBuf[I].Y,

        @LineDrawFunc, Integer(Canvas));

      end;

     end;

    end;

    1.3.4.5. Интерактивная кривая

    Описанная технология создания "резиновой" линии не годится для рисования кривой Безье, т. к. пользователь должен задать координаты не двух точек, а четырех. Удобнее всего это сделать следующим образом: сначала нарисовать "резиновую" прямую, задав тем самым начало и конец кривой, а потом дать пользователю возможность перемещать опорные или промежуточные точки кривой до тех пор, пока она не будет завершена. При этом логично дать возможность перемещать и концы линии, а также менять ее стиль, т.е. свободно манипулировать незавершенной кривой. Для ее завершения будет использоваться кнопка Завершить (рис. 1.16).

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

    Рис. 1.16. Окно программы Bezier. Красные квадратики — области за которые можно перемещать концы и опорные точки незавершенной кривой


    Когда пользователь нажимает кнопку мыши, программа проверяет, есть ли незавершенная кривая. Если таких кривых нет, начинается создание новой кривой. До тех пор. пока пользователь не отпустит кнопку мыши, рисуется резиновая прямая. Эта прямая становится заготовкой для новой незавершенной кривой.

    Если в момент нажатия кнопки мыши незавершенная кривая уже существует, координаты мыши сравниваются с координатами опорных и концевых точек и, если они оказываются достаточно близки к одной из них, дальнейшее перемещение мыши (при удерживании кнопки) приводит к перемещению соответствующей точки и перерисовке кривой в новом положении. Изменение типа линии и/или способа построения отражается на незавершенной кривой — она немедленно перерисовывается в соответствии с новыми параметрами.

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

    Реализацию интерактивной кривой в данном случае иллюстрирует листинг 1.61.

    Листинг 1.61. Реализация интерактивной кривой

    const

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

     // в некоторую ее окрестность. Константа RectSize задает размер этой

     // окрестности

     RectSize = 3;


    type

     // Тип TDragPoint показывает, какую точку перемещает пользователь:

     // ptNone — пользователь пытается тянуть несуществующую точку

     // ptFirst - пользователь перемещает вторую точку "резиновой" прямой

     // ptBegin - пользователь перемещает начало кривой

     // ptInter1, ptInter2 - пользователь перемещает промежуточные точки

     // ptEnd - пользователь перемещает конец кривой

     TDragPoint = (dpNone, dpFirst, dpBegin, dpInter1, dpInter2, dpEnd);

     TCurveForm = class(TForm)

      BtnEnd: TButton;

      RGroupType: TRadioGrour;

      RGroupDrawMethod: TRadioGroup;

      procedure FormCreate(Sender: TObject);

      procedure FomMouseDown(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Integer);

      procedure FormMouseMove(Sender: TObject; Shift: TShiftState; X, Y: Integer);

      procedure FormMouseUp(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Integer);

      procedure FormPaint(Sender: TObject);

      procedure BtnEndClick(Sender: TObject);

      procedure RGroupTypeClick(Sender: TObject);

      procedure FormDestroy(Sender: TObject);

     private

      // Если FNewLine = True, незавершённых кривых нет, и при нажатии на

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

      // Если FNewLine = False, есть незавершенная кривая, и нажатия мыши

      // интерпретируются как попытки ее редактирования

      FNewLine: Boolean;

      // Поле FDragPoint указывает, какую точку перемещает пользователь

      FDragPoint: TDragPoint;

      // Поле FCurve хранит координаты незавершенной кривой

      FCurve: TCurve;

      // FBack - фоновый рисунок с завершенными кривыми

      FBack: TBitmap;

      // FCounter - счетчик точек, использующийся при рисовании отрезков

      // с помощью LineDDA

      FCounter: Integer;

      // FDX, FDY - смещения относительно координаты точки кривой для

      // рисования поперечной полосы

      FDX, FDY: Integer;

      // Функция PtNearPt возвращает True, если точка с координатами

      // (X1, Y1) удалена от точки Pt по каждой из координат не более

      // чем на RectSize

      functionPtNearPt(X1, Y1: Integer; const Pt: TPoint): Boolean;

      // Процедура DrawCurve рисует кривую по координатам FCurve вида,

      // задаваемого RadioGroup.ItemIndex

      procedure DrawCurve(Canvas: TCanvas);

     end;

    ...


    procedure TCurveForm.FormCreate(Sender: TObject);

    begin

     FNewLine := True;

     FDragPoint := dpNone;

     FBack := TBitmap.Create;

     FBack.Canvas.Brush.Color := Color;

     // Устанавливаем размер фонового рисунка равным размеру развернутого

     // на весь рабочий стол окна

     FBack.Width := GetSystemMetrics(SM_CXFULLSCREEN);

     FBack.Height := GetSystemMetrics(SM_CYFULLSCREEN);

     // Включаем режим двойной буферизации, чтобы незавершенная кривая

     // не мерцала

     DoubleBuffered := True;

    end;


    procedure TCurveForm.FormMouseDown(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Integer);

    begin

     if Button = mbLeft then

     begin

      // Если незавершенных кривых нет, начинаем рисование новой кривой

      if FNewLine then

      begin

       FDragPoint := dpFirst;

       FCurve[0].X := X;

       FCurve[0].Y := Y;

       FCurve[3] := FCurve[0];

      end

      else

      begin

       // Если есть незавершенная кривая, определяем, в какую точку попал

       // курсор мыши. Строго говоря, необходимо также запоминать,

       // насколько отстоят координаты курсора мыши от координат

       // контрольной точки, чтобы при первом перемещении не было скачка.

       // Но т.к. окрестность точки очень мала, этот прыжок практически

       // незаметен, и в данном случае этим можно пренебречь, чтобы

       // не усложнять программу

       if PtNearPt(X, Y, FCurve[0]) then FDragPoint := dpBegin

       else if PtNearPt(X, Y, FCurve[1]) then FDragPoint := dpInter1

       else if PtNearPt(X, Y, FCurve[2]) then FDragPoint : = dpInter2

       else if PtNearPt(X, Y, FCurve[3]) then FDragPoint := dpEnd

       else FDragPoint := dpNone;

      end;

     end;

    end;


    procedure TCurveForm.FormMouseMove(Sender: TObject; Shift: TShiftState; X, Y: Integer);

    begin

     if ssLeft in Shift then

     begin

      case FDragPoint of

      dpFirst, dpEnd: begin

       FCurve[3].X := X;

       FCurve[3].Y := Y;

       Refresh;

      end;

      dpBegin: begin

       FCurve[0].X := X;

       FCurve[0].Y := Y;

       Refresh;

      end;

      dpInter1: begin

       FCurve[1].X := X;

       FCurve[1].Y := Y;

       Refresh;

      end;

      dpInter2: begin

       FCurve[2].X := X;

       FCurve[2].Y := Y;

       Refresh;

      end;

      end;

     end;

    end;


    procedure TCurve Form.FormMouseUp(Sender: TObject; Button: ТМouseButton; Shift: TShiftState; X, Y: Integer);

    begin

     // Если кнопка отпущена при отсутствии незавершенной кривой, значит,

     // пользователь закончил рисование резиновой прямой, на основе которой

     // нужно делать новую кривую

     if (Button = mbLeft) and (FDragPoint = dpFirst) then

     begin

      FNewLine := False;

      FDragPoint := dpNone;

      // Промежуточные точки равномерно распределяем по прямой

      FCurve[1].X := FCurve[0].X + Round((FCurve[3].X - FCurve[0].X) / 3);

      FCurve[1].Y := FCurve[0].Y + Round((FCurve[3].Y - FCurve[0].Y) / 3);

      FCurve[2].X := FCurve[0].X + Round(2 + (FCurve[3].X - FCurve[0].X) / 3);

      FCurve[2].Y := FCurve[0].Y + Round(2 + (FCurve[3].Y - (Curve[0].Y) / 3);

      Refresh;

     end;

    end;


    procedure TCurveForm.FormPaint(Sender: TObject);

    var

     I: Integer;

     L: Extended;

    begin

     // Сначала выводим фон

     Canvas.Draw(0, 0, FBack);

     if FNewLine then

     begin

      // Если программа находится в режиме рисования резиновой прямой,

      // рисуем прямую от точки FCurve[0] до FCurve[3]. Значение FCurve[1]

      // и FCurve[2] на данном этапе игнорируется

      if FDragPoint = dpFirst then

      begin

       FCounter := 0;

       L :=

        Sqrt(Sqr(FCurve[0].X - FCurve[3].X) +

        Sqr(FCurve[0].Y - FCurve[3].Y));

       if L > 0 then

       begin

        FDX := Round(4 * (FCurve[0].Y -FCurve[3].Y) / L);

        FDY := Round(4 * (FCurve[3].X - FCurve[0].X) / L);

        LineDDA(FCurve[0].X, FCurve[0].Y, FCurve[3].X, FCurve[3].Y,

         @LineDrawFunc, Integer(Canvas));

       end;

      end;

     end

     else

     begin

      // Если есть незавершённая кривая и установлен режим рисования

      // по опорным точкам, выводим отрезки, показывающие касательные

      // к кривой в её начале и конце

      if RGroupDrawMethod.ItemIndex = 0 then

      begin

       Canvas.Pen.Style := psDot;

       Canvas.Pen.Width := 3;

       Canvas.Pen.Color := clDkGrey;

       Canvas.MoveTo(FCurve[0].X, FCurve[0].Y);

       Canvas.LineTo(FCurve[1].X, FCurve[1].Y);

       Canvas.MoveTo(FCurve[3].X, FCurve[3].Y);

       Canvas.LineTo(FCurve[2].X, FCurve[2].Y);

      end;

      // Рисуем красные квадраты, показывающие точки, которые пользователь

      // может перемещать

      Canvas.Pen.Style := psSolid;

      Canvas.Pen.Width := 1;

      Canvas.Pen.Color := clRed;

      Canvas.Brush.Style := bsClear;

      for I := 0 to 3 do

       Canvas.Rectangle(FCurve[I].X - RectSize, FCurve[I].Y - RectSize,

        FCurve[I].X + RectSize + 1, FCurve[I].Y + RectSize + 1);

     end;

    end;


    // функция PtNearPt возвращает True, если точка с координатами (X1, Y1)

    // удалена от точки Pt по каждой из координат не более чем на RectSize

    function TCurveForm.PtNearPt(X1, Yl: Integer; const Pt: TPoint): Boolean;

    begin

     Result :=

      (X1 >= Pt.X - RectSize) and (X1 <= Pt.X + RectSize) and

      (Y1 >= Pt.Y - RectSize) and (Y1 <= Pt.Y + RectSize);

    end;


    procedure TCurveForm.BtnEndClick(Sender: TObject);

    begin

     if not FNewLine then

     begin

      DrawCurve(FBack.Canvas);

      FNewLine := True;

      Refresh;

     end;

    end;

    Размеры фонового растра устанавливаются равными размеру развернутого на весь экран окна. Таким образом, если уменьшить окно, то те завершенные кривые, которые окажутся за его пределами, не пропадут — они вновь будут видимы, если увеличить размеры окна. Однако в программе не предусмотрено, что система позволяет пользователю менять разрешение экрана. Это можно учесть, добавив реакцию на сообщение

    WM_DISPLAYCHANGE
    и меняя в нем размеры фонового рисунка.








    Главная | В избранное | Наш E-MAIL | Прислать материал | Нашёл ошибку | Наверх