что такое дескриптор окна

Иллюстрированный самоучитель по Delphi 7 для профессионалов

Базовые классы элементов управления

Вслед за классом TComponent в иерархии базовых классов (см. рис. 2.1) располагается группа из трех классов, которые обеспечивают создание различных визуальных компонентов. Визуальные компоненты – это разнообразные стандартные для Windows и специальные (созданные разработчиками Inprise) элементы управления.

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

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

Класс TWinControl обеспечивает использование в Delphi оконных элементов управления. Главное отличие оконного элемента управления от любых других – наличие дескриптора окна hwnd.

Дескриптор окна – это специальный идентификатор, который операционная система присваивает всем объектам, которые должны обладать свойствами окна. Если элемент управления имеет дескриптор окна, то он должен уметь выполнять следующие операции:

Оконными элементами управления являются не только формы, но и практически все стандартные элементы управления Windows: и списки, и редакторы имеют дескриптор окна.

Итак, все визуальные компоненты происходят от класса TWinControl. Однако нестандартные элементы управления имеют еще одного общего предка. Это класс TCustomContrl. Он существенно облегчает использование элементов управления, т. к. позволяет управлять отрисовкой компонента путем использования специального класса TCanvas – так называемой канвы (см. гл. 11) вместо обращения к системным функциям GUI.

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

Источник

Заголовки и текст окон (расширенные)

AutoIt может искать окна в одном из трёх режимов сравнения заголовков. Режим сравнения устанавливается функцией AutoItSetOption с помощью опции WinTitleMatchMode

Режим 1 (по умолчанию)

Сравнивает часть заголовка с его началом.

Сравнивает любую подстроку заголовка.

Полное совпадение заголовка.

Режим 4 (Оставлено для обратной совместимости)

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

Принудительное сравнение заголовка в нижнем регистре (по соответствующим режиму правилам).

Расширенные установки поиска окна

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

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

Пары «Свойство» и «Значение» перечисляются через «;», а между собой «Свойство» и «Значение» разделяются с помощью «:».

Примечание: если «Значение» должно содержать символ «;», он должен быть продублирован.

Пример: ожидать активацию окна с названием класса «Notepad»

Пример: закрыть текущее активное окно

Пример: ожидать активацию второго окна с заголовком «My Window» и именем класса «My Class». Используются 3 свойства

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

Пример: получить текст заголовка окна, с координатами X=50; Y=40, шириной равной 300, высотой равной 250. Всю метрику окна указывать не обязательно. Используются 5 свойств.

WinGetTitle ( «[CLASS:My Class; X:50; Y:40; W:300; H:250]» )

Дескрипторы окон (HWND)

Примечание: при использовании дескриптора окно однозначно определяется, не принимая во внимание установленный режим WinTitleMatchMode.

Источник

Структура оконного приложения

Оконные приложения строятся по принципам событийно-управляемого программирования (event-driven programming) — стиля программирования, при котором поведение компонента системы определяется набором возможных внешних событий и ответных реакций компонента на них. Такими компонентами в Windows являются окна.

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

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

Классическое оконное приложение, как правило, состоит по крайней мере из двух функций:

Стартовая функция WinMain

Эта функция использует последовательность вызовов API и при завершении возвращает операционной системе целое число.
Аргументы функции:

В структуре стартовой функции Windows можно выделить следующие операции, образующие «скелет» программы:

Регистрация класса окна

Регистрация класса окна осуществляется функцией

Члены структуры
style — устанавливает стиль(и) класса. Этот член структуры может быть любой комбинацией стилей класса.

lpfnWndProc — указатель на оконную процедуру.

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

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

hInstance — дескриптор экземпляра, который содержит оконную процедуру для класса.

hIcon — дескриптор значка класса, дескриптор ресурса значка. Если этот член структуры — NULL, система предоставляет заданный по умолчанию значок.

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

Создание окна

Создание окна осуществляется функцией

Прототип функции находится в файле библиотеки user32.dll.
Возвращаемое значение – дескриптор создаваемого окна. В случае невозможности создать окно возвращается NULL.

Аргументы функции :
lpClassName – указывает на строку с ‘\0’ в конце, которая определяет имя класса окна. Имя класса может быть зарегистрированным функцией RegisterClass или любым из предопределенных имен класса элементов управления.

lpWindowName — указывает на строку с ‘\0’ в конце, которая определяет имя окна.

dwStyle — определяет стиль создаваемого окна.

у – определяет координату верхней стороны окна относительно верхней стороны экрана. Измеряется в единицах измерения устройства, чаще всего в точках (pt). Для дочернего окна определяет координату верхней стороны относительно начальной координаты родительского окна.

nHeight – определяет высоту окна в единицах измерения устройства.

hWndParent – дескриптор родительского окна.

hInstance — идентифицирует экземпляр модуля, который будет связан с окном.

lpParam — указывает на значение, переданное окну при создании.

Отображение и перерисовка окна

Отображение окна осуществляется функцией

Прототип функции находится в файле библиотеки user32.dll.
Возвращаемое значение: 1 – успешное отображение окна, 0 – ошибка.

Аргументы функции :
hWnd – дескриптор отображаемого окна.

nCmdShow – константа, определяющая, как будет отображаться окно согласно таблице.

Перерисовка окна осуществляется функцией

Прототип функции находится в файле библиотеки user32.dll.
Возвращаемое значение: 1 – успешная перерисовка окна, 0 – ошибка.
Аргумент функции hWnd – дескриптор окна.

Цикл обработки сообщений

Для получения сообщения из очереди используется функция:

Аргументы функции :
lpMsg — указатель на структуру сообщения.

Структура POINT имеет вид

hWnd — дескриптор окна, очередь для которого просматривается.

wMsgFilterMin — нижняя граница фильтра идентификаторов сообщений.

wMsgFilterMax — верхняя граница фильтра идентификаторов сообщений.

передает аргумент — структуру msg обратно в Windows для преобразования какого-либо сообщения с клавиатуры. Возвращает ненулевое значение в случае успешной расшифровки сообщения, 0 – ошибка.

передает аргумент — структуру msg обратно в Windows. Windows отправляет сообщение для его обработки соответствующей оконной процедуре — таким образом, Windows вызывает соответствующую оконную функцию, указанную при регистрации класса окна.

Пример стартовой функции, создающей и выводящей окно размером 500х300 точек:

Примечание : Для корректной сборки приложения используется многобайтовая кодировка.

Оконная функция — обработка сообщений окна

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

Вызов функции DefWindowProc() обрабатывает по умолчанию все сообщения, которые не обрабатывает оконная процедура.
Функция PostQuitMessage() сообщает Windows, что данный поток запрашивает завершение. Аргументом является целочисленное значение, которое функция вернет операционной системе.

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

Комментариев к записи: 13

Источник

Что такое окно?

Что такое окно?

Очевидно, что Windows является центральной для Windows. Так важно, чтобы они называли операционную систему после них. Но что такое окно? Если вы считаете окно, вы, вероятно, думаете примерно так:

Вот еще один тип окна:

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

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

родительский Windows и владелец Windows

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

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

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

Дескрипторы окон

Windows являются объектами — они содержат как код, так и данные, но они не являются классами C++. Вместо этого программа ссылается на окно, используя значение, называемое маркером. Маркер является непрозрачным типом. По сути, это просто число, используемое операционной системой для обнаружения объекта. вы можете создать изображение Windows как наличие большой таблицы всех созданных окон. Она использует эту таблицу для поиска окон по их дескрипторам. (Будь это именно то, как он работает внутренне, не имеет значения.) Для дескрипторов окон используется тип данных HWND, который обычно произносится как «аитч-ветер». Дескрипторы окон возвращаются функциями, которые создают окна: CreateWindow и CreateWindowEx.

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

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

Координаты экрана и окна

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

Источник

Что такое дескриптор Windows?

Что такое «дескриптор» при обсуждении ресурсов в Windows? Как они работают?

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

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

Сам по HANDLE себе просто интегральный тип. Обычно, но не обязательно, это указатель на некоторый базовый тип или область памяти. Например, HANDLE возвращаемое значение на GetModuleHandle самом деле является указателем на базовый адрес виртуальной памяти модуля. Но нет правила, утверждающего, что дескрипторы должны быть указателями. Дескриптор также может быть простым целым числом (которое может быть использовано некоторыми Win32 API в качестве индекса в массиве).

HANDLE Это намеренно непрозрачные представления, которые обеспечивают инкапсуляцию и абстрагирование от внутренних ресурсов Win32. Таким образом, Win32 API могли бы потенциально изменить базовый тип за HANDLE, без какого-либо влияния на пользовательский код (по крайней мере, в этом идея).

Оба эти последствия могут быть нежелательными.

Зачем переживать эту проблему? Рассмотрим этот четвертый пример более новой версии этого же API:

Обратите внимание, что интерфейс функции идентичен третьему примеру выше. Это означает, что пользовательский код может продолжать использовать эту новую версию API без каких-либо изменений, даже несмотря на то, что реализация «за кулисами» изменилась для использования NewImprovedWidget структуры вместо этого.

Источник