Что такое windows api где можно найти информацию по этому вопросу
Разбираемся в WinAPI
Для кого эта статья
Эта статья адресована таким же, как и я новичкам в программировании на С++ которые по воле случая или по желанию решили изучать WinAPI.
Хочу сразу предупредить:
Я не претендую на звание гуру по C++ или WinAPI.
Я только учусь и хочу привести здесь несколько примеров и советов которые облегчают мне изучение функций и механизмов WinAPI.
В данной статье я предполагаю что вы уже достаточно ознакомились с С++, что бы уметь создавать классы и перегружать для них различные операторы и что вы уже «прятали» какие-то свои механизмы в класс.
Создание и использование консоли
Для отладки Win32 приложения или просто для того что посмотреть как оно там всё внутри происходит я всегда пользуюсь консолью.
Так как вы создаете GUI приложение, а не консольное, то консоль не подключается. Для того что бы её вызвать в недрах интернета был найден вот этот код
if (AllocConsole())
<
int hCrt = _open_osfhandle((long)GetStdHandle(STD_OUTPUT_HANDLE), 4);
*stdout = *(::_fdopen(hCrt, «w»));
::setvbuf(stdout, NULL, _IONBF, 0);
*stderr = *(::_fdopen(hCrt, «w»));
::setvbuf(stderr, NULL, _IONBF, 0);
std::ios::sync_with_stdio();
>
Для удобства советую обернуть его в функцию. Например:
void CreateConsole()
<
if (AllocConsole())
<
int hCrt = _open_osfhandle((long)GetStdHandle(STD_OUTPUT_HANDLE), 4);
*stdout = *(::_fdopen(hCrt, «w»));
::setvbuf(stdout, NULL, _IONBF, 0);
*stderr = *(::_fdopen(hCrt, «w»));
::setvbuf(stderr, NULL, _IONBF, 0);
std::ios::sync_with_stdio();
>
Вызванная консоль работает только в режиме вывода и работает он также как и в консольных приложениях. Выводите информацию как и обычно — cout/wcout.
Для работоспособности данного кода необходимо включить в прект следующие файлы:
#include
#include #include
и включить пространство имен std в глобальное пространство имён:
using namespace std;
Конечно же, если вы не хотите этого делать, то просто допишите std:: ко всем сущностям которые в ней находятся.
Наследование объектов для вывода и арифм. операций
При создании и изучении самих «окошек» мне всегда требовалось выводить в консоль какое-нибудь значение.
Например:
Вы получаете размер клиентской области окна с помощью функции GetClientRect куда как параметр передается адрес объекта структуры RECT, что бы заполнить этот объект данными. Если вам нужно узнать размер полученной клиентский области вы просто можете вывести его в уже подключённую консоль
Но делать так каждый раз (особенно если вам часто приходиться делать что-то подобное) очень неудобно.
Здесь нам на помощь приходит наследование.
Создайте класс который открыто наследуется от структуры RECT и перегрузите оператор вывода class newrect:public RECT
<
public:
friend ostream& operator
Теперь просто выводите обьект с помощью cout/wcout:
И вам в удобном виде будет выводиться всё так, как вам требуется.
Так же вы можете сделать с любыми нужными вам операторами.
Например, если надо сравнивать или присваивать структуры (допустим тот же RECT или POINT) — перегрузите operator==() и operator=() соответственно.
Если хотите реализовать оператор меньше class BaseWindow
<
WNDCLASSEX _wcex;
TCHAR _className[30];
TCHAR _windowName[40];
HWND _hwnd;
bool _WindowCreation();
public:
BaseWindow(LPCTSTR windowName,HINSTANCE hInstance,DWORD style,UINT x,UINT y,UINT height,UINT width);
BaseWIndow(LPCTSTR windowName,HINSTANCE hInstance);
const HWND GetHWND()const
LPCTSTR GetWndName()const
>;
Один раз хорошенько продумав и написав такой класс вы облегчите себе жизнь и будете больше времени уделять обучению и оттачиванию навыков чем написанию одного и того же каждый раз. Тем более, я считаю это очень полезно — самому сделать такой класс и дополнять его по необходимости.
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
Microsoft Windows API
Содержание
Общие сведения
Работа через Windows API — это наиболее близкий к операционной системе способ взаимодействия с ней из прикладных программ. Более низкий уровень доступа, необходимый только для драйверов устройств, в текущих версиях Windows предоставляется через Windows Driver Model.
Windows API представляет собой множество функций, структур данных и числовых констант, следующих соглашениям языка Си. Все языки программирования, способные вызывать такие функции и оперировать такими типами данных в программах, исполняемых в среде Windows, могут пользоваться этим API. В частности, это языки C++, Pascal, Visual Basic и многие другие. Эти функции в свою очередь могут быть разбиты на следующие основные категории:
История Microsoft API
Microsoft прилагает усилия, чтобы сохранить обратную совместимость. Для достижения этой цели при разработке новых версий Windows, Microsoft иногда реализует обходные пути, чтобы обеспечить совместимость с программным обеспечением сторонних производителей, которые использовали предыдущую версию незарегистрированным или даже нецелесообразным способом.
Обзор
Функции, предоставляемые Windows API, могут быть представлены следующим образом:
Взаимодействие программ
Версии Windows API
Почти каждая новая версия Microsoft Windows представила свои собственные дополнения и изменения в Windows API.
Мультимедиа
Microsoft также предоставляет несколько интерфейсов API для кодирования медиа и воспроизведения:
Пошаговое руководство. Вызов API Windows (Visual Basic)
преимуществом использования api Windows в коде является то, что они могут сэкономить время разработки, поскольку они содержат десятки полезных функций, которые уже написаны и ожидают использования. недостаток заключается в том, что Windows api может быть трудно работать с и унфоргивинг в случае неправильной работы.
Отображаемые на компьютере имена или расположения некоторых элементов пользовательского интерфейса Visual Studio могут отличаться от указанных в следующих инструкциях. Это зависит от имеющегося выпуска Visual Studio и используемых параметров. Дополнительные сведения см. в разделе Персонализация среды IDE.
Вызовы API с помощью Declare
наиболее распространенным способом вызова Windows api является использование Declare инструкции.
Объявление процедуры DLL
Определите имя функции, которую необходимо вызвать, а также ее аргументы, типы аргументов и возвращаемое значение, а также имя и расположение библиотеки DLL, содержащей ее.
полные сведения об api-интерфейсах Windows см. в документации по пакету sdk для Win32 в пакете sdk платформы Windows API. дополнительные сведения о константах, используемых Windows api, см. в файлах заголовков, таких как Windows. h, поставляемых с пакетом Platform SDK.
выберите Windows приложение из списка шаблонов проектов Visual Basic. Отобразится новый проект.
Добавьте следующую Declare функцию либо в класс, либо в модуль, в котором требуется использовать библиотеку DLL:
Части инструкции DECLARE
Declare Инструкция включает следующие элементы.
Модификатор Auto
Auto Модификатор указывает среде выполнения преобразовать строку на основе имени метода в соответствии с правилами среды CLR (или именем псевдонима, если оно указано).
Ключевые слова lib и Alias
Имя, следующее за Function ключевым словом, — это имя, которое программа использует для доступа к импортируемой функции. Оно может совпадать с реальным именем вызываемой функции, или можно использовать любое допустимое имя процедуры, а затем применить Alias ключевое слово, чтобы указать реальное имя вызываемой функции.
Укажите Lib ключевое слово, а затем имя и расположение библиотеки DLL, содержащей вызываемую функцию. не нужно указывать путь для файлов, расположенных в системных каталогах Windows.
используйте Alias ключевое слово, если имя вызываемой функции не является допустимым Visual Basic именем процедуры или конфликтует с именами других элементов в приложении. Alias Указывает на истинное имя вызываемой функции.
Объявления аргументов и типов данных
Объявите аргументы и их типы данных. эта часть может быть сложной, поскольку типы данных, которые Windows используются, не соответствуют Visual Studioным типам данных. Visual Basic выполняет большой объем работы, преобразуя аргументы в совместимые типы данных, процесс, называемый упаковкой. Можно явно управлять упаковкой аргументов с помощью MarshalAsAttribute атрибута, определенного в System.Runtime.InteropServices пространстве имен.
Windows Константы API
Некоторые аргументы являются сочетаниями констант. Например, API, MessageBox показанный в этом пошаговом руководстве, принимает целочисленный аргумент Typ с именем, который управляет отображением окна сообщения. Можно определить числовое значение этих констант, изучив #define инструкции в файле WinUser. h. Числовые значения обычно отображаются в шестнадцатеричном виде, поэтому для их добавления и преобразования в десятичный формат может потребоваться калькулятор. Например, если вы хотите объединить константы для стиля с восклицательным знаком MB_ICONEXCLAMATION 0x00000030, а стиль «да/нет MB_YESNO », можно добавить числа и получить результат 0x00000034 или 52 Decimal. Хотя вы можете использовать десятичный результат непосредственно, лучше объявить эти значения как константы в приложении и объединить их с помощью Or оператора.
объявление констант для вызовов API Windows
обратитесь к документации по функции Windows, которую вы вызываете. Определите имена констант, которые он использует, и имя h файла, содержащего числовые значения для этих констант.
используйте текстовый редактор, например Блокнот, для просмотра содержимого файла заголовка (. h) и поиска значений, связанных с используемыми константами. Например, MessageBox API использует константу MB_ICONQUESTION для отображения вопросительного знака в окне сообщения. Определение для MB_ICONQUESTION находится в файле WinUser. h и выглядит следующим образом:
#define MB_ICONQUESTION 0x00000020L
Добавьте эквивалентные Const операторы в класс или модуль, чтобы сделать эти константы доступными для приложения. Пример:
Вызов процедуры DLL
Добавьте кнопку с именем Button1 в форму запуска проекта, а затем дважды щелкните ее, чтобы просмотреть код. Появится обработчик событий для кнопки.
Добавьте код в Click обработчик событий для добавленной кнопки, чтобы вызвать процедуру и предоставить соответствующие аргументы:
Маршалирование данных
Visual Basic автоматически преобразует типы данных параметров и возвращаемые значения для вызовов API Windows, но можно использовать MarshalAs атрибут, чтобы явно указать неуправляемые типы данных, которые ожидает API. Дополнительные сведения о маршалинге взаимодействия см. в разделе Маршалинг взаимодействия.
Использование Declare и MarshalAs в вызове API
Определите имя функции, которую необходимо вызвать, а также ее аргументы, типы данных и возвращаемое значение.
Чтобы упростить доступ к MarshalAs атрибуту, добавьте Imports оператор в начало кода для класса или модуля, как показано в следующем примере:
Добавьте прототип функции для импортированной функции в класс или модуль, который вы используете, и примените MarshalAs атрибут к параметрам или возвращаемому значению. В следующем примере вызов API, который принимает тип, void* маршалируется как AsAny :
Вызовы API с помощью DllImport
DllImport Атрибут предоставляет второй способ вызова функций в библиотеках DLL без библиотек типов. DllImport примерно эквивалентно использованию оператора, Declare но обеспечивает более полный контроль над вызовом функций.
можно использовать DllImport с большинством вызовов API Windows, если вызов ссылается на общий (иногда называемый статическим) метод. Нельзя использовать методы, для которых требуется экземпляр класса. В отличие от Declare инструкций DllImport вызовы не могут использовать MarshalAs атрибут.
вызов API Windows с помощью атрибута DllImport
выберите Windows приложение из списка шаблонов проектов Visual Basic. Отобразится новый проект.
Добавьте кнопку с именем Button2 в форму запуска.
Дважды щелкните, Button2 чтобы открыть представление кода для формы.
примените Public Shared модификаторы и к объявлению функции и задайте параметры в MoveFile зависимости от аргументов, используемых Windowsной функцией API:
Функция может иметь любое допустимое имя процедуры; DllImport атрибут указывает имя в библиотеке DLL. он также обрабатывает упаковку взаимодействия для параметров и возвращаемых значений, поэтому можно выбрать Visual Studio типов данных, которые похожи на типы данных, используемые API.
Добавьте код в Button2_Click обработчик событий для вызова функции:
Создайте файл с именем Test.txt и поместите его в каталог К:\тмп на жестком диске. При необходимости создайте каталог tmp.
Нажмите клавишу F5 для запуска приложения. Откроется Главная форма.
Нажмите кнопку Button2. Если файл можно переместить, отображается сообщение «файл перемещен успешно».
наборы API Windows
сведения в этом разделе применимы ко всем версиям Windows 10 и Windows 11. мы будем называть эти версии «Windows», вызывая любые исключения, если это необходимо.
все версии Windows совместно используют общую основу компонентов операционной системы, которая называется основной ос (в некоторых контекстах этот общий базовый метод также называется OneCore). В основных компонентах ОС API Win32 организованы в функциональные группы, которые называются наборами API.
Целью набора API является предоставление архитектурного разделения от библиотеки DLL узла, в которой реализован данный API Win32, и функционального контракта, к которому принадлежит API. Разделение, предоставляемое наборами API между реализацией и контрактами, предоставляет разработчикам множество преимуществ для инженеров. в частности, использование наборов API в коде может улучшить совместимость с Windows устройствами.
Наборы API специально предназначены для следующих сценариев:
хотя все возможности api win32 поддерживаются на компьютерах, на других Windows 10 и (или) Windows 11 таких устройств, как HoloLens, Xbox и другие устройства, доступно только подмножество api win32. Имя набора API предоставляет механизм запросов, позволяющий четко определить, доступен ли API на любом конкретном устройстве.
некоторые реализации API Win32 существуют в библиотеках dll с разными именами на разных Windows устройствах. Использование имен наборов API вместо имен библиотек DLL при обнаружении API доступности и отложенной загрузки API обеспечивает правильный маршрут к реализации независимо от того, где фактически реализован API.
Связывание с библиотеками «тег»
Чтобы упростить ограничение кода интерфейсами API Win32, которые поддерживаются в основной ОС, мы предоставляем ряд библиотек-кодов. например, библиотека с именем-псевдонимом OneCore.lib предоставляет экспорты для подмножества api-интерфейсов Win32, которые являются общими для всех Windows устройств.
API-интерфейсы в библиотеке-области могут быть реализованы в разных модулях. библиотека «тег» абстрагирует эти сведения от вас, делая код более переносимым по сравнению с Windows версиями и устройствами. Вместо связывания с библиотеками, такими как Kernel32. lib и advapi32. lib, просто Свяжите свое классическое приложение или драйвер с библиотекой-символами-разработчиками, которая содержит набор основных API ОС, которые вас интересуют.
дополнительные сведения см. в разделе библиотеки Windowsных библиотек.
Имена контрактов набора API
Наборы API идентифицируются строгим именем контракта, которое соответствует стандартным соглашениям, распознаваемым загрузчиком библиотеки.
Ниже приведены некоторые примеры имен контрактов для наборов API.
За исключением добавления строки .dll в операции загрузчика имена контрактов набора API должны рассматриваться как неизменяемые идентификаторы, соответствующие определенной версии контракта.
Определение наборов API для API-интерфейсов Win32
Чтобы определить, принадлежит ли конкретный API Win32 набору API, ознакомьтесь с таблицей требований в справочной документации по API. если api принадлежит к набору api, в таблице требований в статье перечислены имя набора api и версия Windows, в которой api впервые появился в наборе api. Примеры API-интерфейсов, принадлежащих набору API, см. в следующих статьях:
Окна на чистом 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.