Дескриптор окна что это
Что такое окно?
Что такое окно?
Очевидно, что Windows является центральной для Windows. Так важно, чтобы они называли операционную систему после них. Но что такое окно? Если вы считаете окно, вы, вероятно, думаете примерно так:
Вот еще один тип окна:
если вы не знакомы с Windows программированием, это может заудивлено тем, что элементы управления пользовательского интерфейса, такие как кнопки и поля редактирования, являются окнами. Основное различие между элементом управления пользовательского интерфейса и окном приложения заключается в том, что сам элемент управления не существует. Вместо этого элемент управления располагается относительно окна приложения. При перетаскивании окна приложения элемент управления перемещается вместе с ним, как и хотелось бы. Кроме того, элемент управления и окно приложения могут взаимодействовать друг с другом. (Например, окно приложения получает команду уведомления от кнопки.)
Таким образом, при обдумывании окна не следует просто думать окно приложения. Вместо этого представьте окно как конструкцию программирования, которая:
родительский Windows и владелец Windows
В случае элемента управления пользовательского интерфейса окно элемента управления называется дочерним элементом окна приложения. Окно приложения является родительским для окна управления. Родительское окно предоставляет систему координат, используемую для размещения дочернего окна. Наличие родительского окна влияет на аспекты внешнего вида окна; Например, дочернее окно обрезается таким образом, что никакая часть дочернего окна не может отображаться вне границ родительского окна.
На следующем рисунке показано приложение, которое отображает диалоговое окно с двумя кнопками:
Окно приложения владеет диалоговым окном, а диалоговое окно является родительским для обоих окон кнопок. Эти связи показаны на следующей схеме:
Дескрипторы окон
Windows являются объектами — они содержат как код, так и данные, но они не являются классами C++. Вместо этого программа ссылается на окно, используя значение, называемое маркером. Маркер является непрозрачным типом. По сути, это просто число, используемое операционной системой для обнаружения объекта. вы можете создать изображение Windows как наличие большой таблицы всех созданных окон. Она использует эту таблицу для поиска окон по их дескрипторам. (Будь это именно то, как он работает внутренне, не имеет значения.) Для дескрипторов окон используется тип данных HWND, который обычно произносится как «аитч-ветер». Дескрипторы окон возвращаются функциями, которые создают окна: CreateWindow и CreateWindowEx.
Первый параметр — это маркер окна, которое требуется переместить. Другие параметры указывают новое расположение окна и необходимость перерисовки окна.
Помните, что дескрипторы не являются указателями. Если HWND является переменной, содержащей дескриптор, попытка разыменования дескриптора с помощью записи *hwnd является ошибкой.
Координаты экрана и окна
В зависимости от задачи можно измерять координаты относительно экрана, относительно окна (включая рамку) или относительно клиентской области окна. Например, можно разместить окно на экране с помощью экранных координат, но нарисовать внутри окна с помощью клиентских координат. В каждом случае источник (0, 0) всегда находится в левом верхнем углу области.
Окна на чистом WinAPI. Или просто о сложном
Казалось бы, что WinAPI уходит в прошлое. Давно уже существует огромное количество кросс-платформенных фреймфорков, Windows не только на десктопах, да и сами Microsoft в свой магазин не жалуют приложения, которые используют этого монстра. Помимо этого статей о том, как создать окошки на WinAPI, не только здесь, но и по всему интернету, исчисляется тысячами по уровню от дошколят и выше. Весь этот процесс разобран уже даже не по атомам, а по субатомным частицам. Что может быть проще и понятнее? А тут я еще…
Но не все так просто, как кажется.
Почему о WinAPI сейчас?
В один прекрасный момент, изучая потроха одной из игр в весьма неплохом эмуляторе NES, я подумал: Вроде неплохой такой эмуль, а в отладчике нет такой простой вещи, как навигация по кнопкам клавиатуры, которая есть в любом нормальном отладчике.
Здесь я не зря дал ссылку на репозиторий, т.к. видно, что ребята столкнулись с проблемой, о которой речь пойдет ниже, но так и не решили ее.
О чем это я? А вот об этом кусочке кода:
Таким образом, авторы хотели добавить поддержку клавиатуры, но суровая реальность недр архитектуры диалоговых окон в Windows жестко пресекла такую самодеятельность. Те, кто пользовался эмулятором и отладчиком в нем, хоть раз видели это сообщение?
В чем же проблема?
Ответ такой: так делать нельзя!
И, возвращаясь, к изначальному вопросу о WinAPI: очень много популярных, и не очень, проектов продолжают его использовать и в настоящее время, т.к. лучше, чем на чистом API многие вещи не сделать (тут можно бесконечно приводить аналогии вроде сравнения высокоуровневых языков и ассемблера, но сейчас не об этом). Да и мало ли почему? Просто используют и все тут.
О проблеме
Диалоговые окна упрощают работу с GUI, одновременно лишая нас возможности сделать что-то самостоятельно. Например, сообщения WM_KEYDOWN/WM_KEYUP, приходящие в оконную процедуру, «съедаются» в недрах DefDlgProc, беря на себя такие вещи, как: Навигация по Tab, обработка клавиш Esc, Enter, и т.д. Кроме того, диалоги не нужно создавать вручную: проще, ведь, набросать кнопок, списков, в редакторе ресурсов, вызвать в WinMain CreateDialog/DialogBox и все готово.
Обойти такие мелкие неприятности просто. Есть, как минимум, два вполне легальных способа:
Tutorials?
Не побоюсь сказать, что все туториалы по созданию окон через WinAPI начинаются с такого незамысловатого кода, обозначая его, как «цикл обработки сообщений» (опущу детали по подготовке класса окна и прочую обвязку):
Здесь действительно все просто:
И ниже приводится пример правильного цикла.
Стоит сказать, что в шаблонах VS для Win32 приложений, написан именно такой неправильный цикл. И это очень печально. Ведь мало кто будет вникать в то, что сделали сами авторы, ведь это априори правильно. И неправильный код множится вместе с багами, которые очень сложно отловить.
После этого фрагмента кода, как правило, следует рассказ про акселераторы, и добавляется пара новых строчек (учитывая замечание в MSDN, предлагаю сразу писать правильный цикл):
Этот вариант я видел чаще всего. И он (та-дам) снова неправильный!
Сперва о том, что изменилось (потом о проблемах этого кода):
В первой строчке из ресурсов загружается таблица клавиш, при нажатии на которые, будет формироваться сообщение WM_COMMAND с соответствующим id команды.
Собственно TranslateAccelerator этим и занимается: если видит WM_KEYDOWN и код клавиши, которые есть в этом списке, то (опять же ключевой момент) будет формировать сообщение WM_COMMAND (MAKEWPARAM(id, 1)) и отправлять в соответствующую для дескриптора окна, указанного в первом аргументе, процедуру обработки.
Из последней фразы, думаю, стало понятно, в чем проблема предыдущего кода.
Поясню: GetMessage выхватывает сообщения для ВСЕХ объектов типа «окно» (в число которых входят и дочерние: кнопки, списки и прочее), а TranslateAccelerator будет отправлять сформированную WM_COMMAND куда? Правильно: обратно в кнопку/список и т.д. Но мы обрабатываем WM_COMMAND в своей процедуре, а значит нам интересно ее получать в ней же.
Ясно, что TranslateAccelerator надо вызывать для нашего созданного окна:
И вроде все хорошо и замечательно теперь: мы разобрали все детально и все должно работать идеально.
И снова нет. 🙂 Это будет работать правильно, пока у нас ровно одно окно — наше. Как только появится немодальное новое окно (диалог), все клавиши, которые будут в нем нажаты оттранслируются в WM_COMMAND и отправляться куда? И опять же правильно: в наше главное окно.
На этом этапе предлагаю не городить костылей по решению этой тупиковой ситуации, а предлагаю рассмотреть вещи, которые уже реже (или почти не встречаются) в туториалах.
IsDialogMessage
По названию этой функции можно подумать, что она зачем-то определяет: относится данное сообщение диалогу или нет. Но, во-первых, зачем нам это знать? А во-вторых, что с этой информацией нам делать дальше?
На самом деле, делает она чуть больше, чем следует из названия. А именно:
Во-вторых, она нам облегчит жизнь по всем остальным пунктам, перечисленным в списке (и даже немного больше).
Вообще, она используется где-то в недрах Windows для обеспечения работы модальных диалоговых окон, а программистам дана, чтобы вызывать ее для немодальных диалогов. Однако мы ее можем использовать где угодно:
Although the IsDialogMessage function is intended for modeless dialog boxes, you can use it with any window that contains controls, enabling the windows to provide the same keyboard selection as is used in a dialog box.
Т.е. теперь, если мы оформим цикл так:
То наше окошко будет иметь навигацию, как в родном диалоге Windows. Но теперь мы получили два недостатка:
Пора поговорить о том, чего нет в туториалах и ответах.
Как правило (как правило! Если кому-то захочется большего, то можно регистрировать свой класс для диалогов и работать так. И, если же, кому-то это интересно, я могу дополнить этим статью) WM_KEYDOWN хотят тогда, когда хотят обработать нажатие на клавишу, которая выполнит функцию в независимости от выбранного контрола в окне — т.е. некая общая функция для всего данного конкретного диалога. А раз так, то почему бы не воспользоваться богатыми возможностями, которые нам сама WinAPI и предлагает: TranslateAccelerator.
Везде используют ровно одну таблицу акселераторов, и только для главного окна. Ну действительно: цикл GetMessage-loop один, значит и таблица одна. Куда еще их девать?
На самом деле, циклы GetMessage-loop могут быть вложенными. Давайте еще раз посмотрим описание PostQuitMessage:
The PostQuitMessage function posts a WM_QUIT message to the thread’s message queue and returns immediately; the function simply indicates to the system that the thread is requesting to quit at some time in the future.
If the function retrieves the WM_QUIT message, the return value is zero.
Таким образом, выход из GetMessage-loop осуществится, если мы вызовем PostQuitMessage в процедуре окна. Что это значит?
Мы можем для каждого немодального окна в нашей программе создавать свой собственный подобный цикл. В данном случае DialogBoxParam нам не подходит, т.к. оно крутит свой собственный цикл и повлиять мы на него не можем. Однако если создадим диалог через CreateDialogBoxParam или окно через CreateWindow, то можно закрутить еще один цикл. При этом в каждом таком окне и диалоге мы должны вызывать PostQuitMessage:
Обратите внимание: теперь для каждого нового окна в нашей программе мы можем добавить в обработку собственную таблицу акселераторов. WM_QUIT будет выхватывать GetMessage из цикла для диалога, а внешний цикл его даже не увидит. Почему так происходит?
Дело в том, что внешний цикл «встал» на вызове DispatchMessage, который вызвал нашу процедуру, которая крутит свой собственный внутренний цикл GetMessage с таким же DispatchMessage. Классический вложенный вызов (в данном случае DispatchMessage). Посему внешний цикл не получит WM_QUIT и не завершится на этом этапе. Все будет работать стройно.
Но и тут есть свои недостатки:
Каждый такой цикл будет обрабатывать сообщения только для «своего» окна. Про другие-то мы здесь не знаем. А значит, если где-то объявится еще один цикл, то все остальные окна не будут получать нужной обработки своих сообщений парой TranslateAccelerator/IsDialogMessage.
Что ж, пора учесть все эти замечание и написать наконец правильную обработку всех сообщений от всех окон нашей программы. Хочу заметить, что ниже рассматривается случай для одного потока. Т.к. каждый поток имеет свою очередь сообщений, то для каждого потока придется создавать свои структуры. Делается это весьма тривиальными изменениями в коде.
Делаем красиво
Т.к. правильная постановка задачи является половиной решения, то сперва надо эту самую задачу правильно же и поставить.
Во-первых, было бы логично, что только активное окно принимает сообщения. Т.е. для неактивного окна мы не будем транслировать акселераторы и передавать сообщения в IsDialogMessage.
Во-вторых, если для окна не задана таблица акселераторов, то транслировать нечего, будем просто отдавать сообщение в IsDialogMessage.
Создадим простой std::map, который будет мапить дескриптор окна в дескриптор таблицы акселераторов. Вот так:
И по мере создания окон будем в него добавлять новые окна с дескриптором на свою любимую таблицу (или нуль, если такая обработка не требуется).
Ну и после закрытия окна удалять. Вот так:
Теперь, как создаем новый диалог/окно, вызываем AddAccelerators( hNewDialog, IDR_MY_ACCEL_TABLE ). Как закрываем: DelAccel( hNewDialog ).
Список окон с нужными дескрипторами у нас есть. Немного модифицируем наш основной цикл обработки сообщений:
Значительно лучше! Что же там в HandleAccelArray и зачем там GetActiveWindow()?
Есть две функции, возвращающих дескриптор активного окна GetForegroundWindow и GetActiveWindow. Отличие первой от второй вполне доходчиво описано в описании второй:
The return value is the handle to the active window attached to the calling thread’s message queue. Otherwise, the return value is NULL.
Если первая будет возвращать дескриптор любого окна в системе, то последняя только того, которое использует очередь сообщений нашего потока. Т.к. нас интересуют окна только нашего потока (а значит те, которые будут попадать в нашу очередь сообщений), то и возьмем последнюю.
Так вот HandleAccelArray, руководствуясь переданным ей дескриптором на активное окно, ищет это самое окно в нашей мапе, и если оно там есть, отдает это сообщение на трансляцию в TranslateAccelerator, а затем (если первый не увидел нужного) в IsDialogMessage. Если и последняя не обработала сообщение, то возвращаем FALSE, чтобы пройти по стандартной процедуре TranslateMessage/DispatchMessage.
Теперь каждое дочернее окно вправе добавить себе любимую таблицу акселераторов и спокойно ловить и обрабатывать WM_COMMAND с нужным кодом.
А что там еще об одной строчке в коде обработчика WM_COMMAND?
To differentiate the message that this function sends from messages sent by menus or controls, the high-order word of the wParam parameter of the WM_COMMAND or WM_SYSCOMMAND message contains the value 1.
Обычно код обработки WM_COMMAND выглядит так:
Теперь можно написать так:
И теперь, возвращаясь к тому же fceux, добавив всего одну строчку в код обработки команд от кнопок, мы получим желаемое: управлять дебагером с клавиатуры. Достаточно добавить небольшую обертку вокруг главного цикла сообщений и новую таблицу акселераторов с нужными соответствиями VK_KEY => IDC_DEBUGGER_BUTTON.
P.S.: Мало кто знает, но можно создавать свою собственную таблицу акселераторов, а теперь и применять ее прямо налету.
P.P.S.: Т.к. DialogBox/DialogBoxParam крутит собственный цикл, то от при вызове диалога через них акселераторы работать не будут и наш цикл (или циклы) будет «простаивать».
P.P.P.S.: После вызова HandleAccelWindow мап l_mAccelTable может измениться, т.к. TranslateAccelerator или IsDialogMessage вызывают DispatchMessage, а там может встретиться AddAccelerators или DelAccel в наших обработчиках! Поэтому лучше его после этой функции не трогать.
Пощупать код можно здесь. За основу был взят код, генерируемый из стандартного шаблона MS VS 2017.
Заголовки и текст окон (расширенные)
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.
О Windows
В этом разделе описываются программные элементы, используемые приложениями для создания и использования окон. Управление связями между окнами; и размер, перемещение и отображение окон.
Обзор включает в себя следующие разделы.
Окно рабочего стола
При запуске система автоматически создает окно рабочего стола. Окно рабочего стола — это системное окно, которое рисует фон экрана и служит базой для всех окон, отображаемых всеми приложениями.
Функция жетдесктопвиндов возвращает маркер окна рабочего стола.
Windows приложений
каждое графическое приложение Windows создает по крайней мере одно окно, именуемое главным окном, которое служит основным интерфейсом между пользователем и приложением. Большинство приложений также создают другие окна, прямо или косвенно, для выполнения задач, связанных с главным окном. Каждое окно играет часть при отображении выходных данных и получении входных данных от пользователя.
При запуске приложения система также связывает с приложением кнопку панели задач. Кнопка на панели задач содержит значок программы и заголовок. Когда приложение активно, его кнопка панели задач отображается в состоянии отправлено.
Окно приложения включает такие элементы, как заголовок окна, строка меню, меню окно (ранее — системное меню), Кнопка сворачивания, кнопка развертывания, кнопка восстановления, кнопка «Закрыть», граница размера, область клиента, горизонтальная полоса прокрутки и вертикальная полоса прокрутки. Главное окно приложения обычно включает все эти компоненты. На следующем рисунке показаны эти компоненты в обычном главном окне.
Клиентская область
Клиентская область — это часть окна, в которой приложение отображает выходные данные, такие как текст или графика. Например, приложение для публикации на рабочем столе отображает текущую страницу документа в клиентской области. Приложение должно предоставить функцию, называемую процедурой окна, для обработки входных данных в окне и вывода выходных данных в клиентской области. Дополнительные сведения см. в разделе Процедуры окна.
Неклиентская область
Строка заголовка, строка меню, меню окон, кнопки сворачивания и развернуть, граница размера и полосы прокрутки вместе называются неклиентской областью окна. Система управляет большинством аспектов неклиентской области; Приложение управляет внешним видом и поведением клиентской области.
В заголовке окна отображается значок и строка текста, определенные в приложении. как правило, текст указывает имя приложения или указывает назначение окна. Приложение задает значок и текст при создании окна. Кроме того, строка заголовка позволяет пользователю перемещать окно с помощью мыши или другого указывающего устройства.
Меню «окно» создается и управляется системой. Он содержит стандартный набор пунктов меню, которые, по выбору пользователя, устанавливают размер или расположение окна, закрывают приложение или выполняют задачи. Дополнительные сведения см. в разделе меню.
Кнопки в правом верхнем углу влияют на размер и расположение окна. При нажатии кнопки «развернуть» система увеличивает окно до размера экрана и позиционирует окно, так что оно охватывает весь рабочий стол, за вычетом панели задач. В то же время система заменяет кнопку «развернуть» нажатием кнопки «восстановить». При нажатии кнопки восстановить система восстанавливает предыдущий размер и расположение окна. При нажатии кнопки сворачивания система сокращает окно до размера кнопки на панели задач, размещает окно на кнопке панели задач и отображает кнопку панели задач в нормальном состоянии. Чтобы восстановить предыдущий размер и положение приложения, нажмите соответствующую кнопку на панели задач. При нажатии кнопки Закрыть приложение завершает работу.
Граница размера — это область вокруг периметра окна, которая позволяет пользователю изменять размер окна с помощью мыши или другого указывающего устройства.
Горизонтальная и вертикальная полосы прокрутки преобразуют ввод мыши или клавиатуры в значения, используемые приложением для сдвига содержимого клиентской области по горизонтали или по вертикали. Например, приложение для обработки текстов, которое отображает длинный документ, обычно предоставляет вертикальную полосу прокрутки, позволяющую пользователю пролистывать документ вверх и вниз.
Элементы управления и диалоговые окна
Приложение может создавать несколько типов окон в дополнение к главному окну, включая элементы управления и диалоговые окна.
Элемент управления — это окно, которое используется приложением для получения определенного фрагмента информации от пользователя, например имени открываемого файла или требуемого размера точки выделения текста. Приложения также используют элементы управления для получения сведений, необходимых для управления определенной функцией приложения. Например, приложение для обработки текстов обычно предоставляет элемент управления, позволяющий пользователю включать и отключать перенос слов. дополнительные сведения см. в разделе элементы управления Windows.
Элементы управления всегда используются совместно с другим окном — обычно это диалоговое окно. Диалоговое окно — это окно, содержащее один или несколько элементов управления. Приложение использует диалоговое окно, в котором пользователю предлагается ввести данные, необходимые для выполнения команды. Например, приложение, которое содержит команду для открытия файла, покажет диалоговое окно, содержащее элементы управления, в которых пользователь указывает путь и имя файла. В диалоговых окнах обычно не используется тот же набор компонентов окна, что и в главном окне. У большинства есть заголовок окна, меню окон, границы (без изменения размера) и клиентской области, но обычно они не имеют строки меню, кнопок сворачивания и развертывания или полос прокрутки. Дополнительные сведения см. в разделе диалоговые окна.
Окно сообщения — это специальное диалоговое окно, в котором отображается замечание или предупреждение. Например, окно сообщения может сообщить пользователю о проблеме, обнаруженной приложением при выполнении задачи. Дополнительные сведения см. в разделе сообщения.
Атрибуты окна
При создании окна приложение должно предоставить следующие сведения. (За исключением обработчика окна, который функция создания возвращает для уникальной идентификации нового окна.)
Эти атрибуты окна описаны в следующих разделах.
Имя класса
Каждое окно принадлежит классу окна. Приложение должно зарегистрировать класс окна перед созданием окон этого класса. Класс Window определяет большинство аспектов внешнего вида и поведения окна. Главным компонентом класса окна является процедура окна, функция, которая получает и обрабатывает все входные данные и запросы, отправленные в окно. Система предоставляет входные данные и запросы в виде сообщений. Дополнительные сведения см. в разделе классы окон, процедуры окон, сообщения и очереди сообщений.
Имя окна
Имя окна — это текстовая строка, определяющая окно для пользователя. Главное окно, диалоговое окно или окно сообщения, как правило, отображает имя окна в строке заголовка, если оно есть. Элемент управления может отображать свое имя окна в зависимости от класса элемента управления. Например, кнопки, элементы управления и статические элементы управления отображают имена окон внутри прямоугольника, занятого элементом управления. Однако элементы управления, такие как списки и поля со списком, не отображают имена окон.
Стиль окна
Система и, в некоторой степени, процедура окна для класса, интерпретирует стили окна.
Некоторые стили окна применяются ко всем окнам, но наиболее применимы к окнам определенных классов окон. Общие стили окон представлены константами, которые начинаются с _ префикса WS; они могут сочетаться с оператором OR для формирования различных типов окон, включая основные окна, диалоговые окна и дочерние окна. Стили окон, зависящие от класса, определяют внешний вид и поведение окон, принадлежащих предопределенным классам элементов управления. Например, класс ScrollBar определяет элемент управления «полоса прокрутки», но стили SBS _ горизонтали и SBS по вертикали определяют, создан ли элемент управления горизонтальной или вертикальной полосой прокрутки. _
Список стилей, которые могут использоваться в Windows, см. в следующих разделах:
Расширенный стиль окна
Дополнительные сведения см. в разделе CreateWindowEx.
Положение
Расположение окна определяется как координаты его верхнего левого угла. Эти координаты, иногда называемые координатами окна, всегда зависят от левого верхнего угла экрана или, для дочернего окна, верхнего левого угла клиентской области родительского окна. Например, окно верхнего уровня с координатами (10, 10) размещается на 10 пикселей справа от верхнего левого угла экрана и на 10 пикселей вниз от него. Дочернее окно с координатами (10, 10) размещается на 10 пикселей справа от левого верхнего угла клиентской области родительского окна и через 10 пикселей вниз от него.
Функция виндовфромпоинт Извлекает маркер окна, занимающие определенную точку на экране. Аналогичным образом функции чилдвиндовфромпоинт и чилдвиндовфромпоинтекс получают маркер дочернего окна, занимающие определенную точку в клиентской области родительского окна. Несмотря на то, что чилдвиндовфромпоинтекс может игнорировать невидимые, отключенные и прозрачные дочерние окна, чилдвиндовфромпоинт не может.
Размер
Маркер окна родителя или владельца
Окно может иметь родительское окно. Окно, имеющее родительский элемент, называется дочерним окном. Родительское окно предоставляет систему координат, используемую для размещения дочернего окна. Наличие родительского окна влияет на аспекты внешнего вида окна; Например, дочернее окно обрезается таким образом, что никакая часть дочернего окна не может отображаться вне границ родительского окна.
Окно, которое не имеет родителя или родительский элемент которого является окном рабочего стола, называется окном верхнего уровня. Приложение может использовать функцию EnumWindows для получения маркера для каждого окна верхнего уровня на экране. В свою очередь, метод EnumWindows передает этот маркер в каждое окно верхнего уровня, а в свою функцию обратного вызова, определяемую приложением, енумвиндовспрок.
Окно верхнего уровня может принадлежать другому окну или принадлежать ему. Принадлежащее окно всегда отображается перед окном своего владельца, скрыто, когда окно его владельца свернется, и уничтожается при уничтожении окна-владельца. Дополнительные сведения см. в разделе владелец Windows.
Маркер меню или идентификатор Child-Window
Любое окно, за исключением дочернего окна, может иметь меню. Приложение может включать меню, предоставляя маркер меню при регистрации класса окна или при создании окна.
Маркер экземпляра приложения
С каждым приложением связан связанный с ним экземпляр. Система предоставляет экземпляру обработчика для приложения при запуске приложения. Поскольку она может запускать несколько копий одного и того же приложения, система использует внутренние дескрипторы экземпляров, чтобы отличать один экземпляр приложения от другого. Приложение должно указать этот экземпляр в различных окнах, включая те, которые создают Windows.
Создание данных
С каждым окном могут быть связаны связанные с приложением данные о создании. При первом создании окна система передает указатель на данные в процедуру окна создаваемого окна. В процедуре окна используются данные для инициализации переменных, определенных приложением.
Дескриптор окна
Создание окна
В этом разделе рассматриваются следующие вопросы.
Существуют дополнительные функции для создания специальных окон, например диалоговых окон и окон сообщений. Дополнительные сведения см. в разделе диалогбокс, креатедиалоги MessageBox.
Создание главного окна
Система не отображает автоматически главное окно после его создания; Вместо этого приложение должно использовать функцию ShowWindow для вывода главного окна. После создания главного окна функция WinMain приложения вызывает функцию ShowWindow, передавая ей два параметра: указатель на главное окно и флаг, указывающий, следует ли отображать или разворачивание главного окна при первом отображении. Обычно флагу можно присвоить любые константы, начинающиеся с _ префикса SW. Однако при вызове ShowWindow для вывода главного окна приложения флаг должен иметь значение SW _ шовдефаулт. Этот флаг сообщает системе, что окно отображается в соответствии с программой, которая запустила приложение.
Если класс окна был зарегистрирован в версии класса registerClassс поддержкой Юникода, то окно получает только сообщения в Юникоде. Чтобы определить, использует ли окно кодировку Юникода, вызовите исвиндовуникоде.
Сообщения Window-Creation
Многопоточные приложения
приложение на основе Windows может иметь несколько потоков выполнения, и каждый поток может создавать окна. Поток, который создает окно, должен содержать код для своей процедуры окна.
Приложение может использовать функцию енумсреадвиндовс для перечисления окон, созданных определенным потоком. Эта функция передает этот обработчик в каждое окно потока, в свою очередь, в определяемую приложением функцию обратного вызова енумсреадвндпрок.
Функция жетвиндовсреадпроцессид возвращает идентификатор потока, создавшего конкретное окно.