Конструирование оснастки для обработки оконных сообщений Windows

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

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

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

Перед созданием окна необходимо создать свой класс. В структуре WNDCLASS есть поле WNDPROC lpfnWndProc, которое содержит ссылку на процедуру обработки сообщений, поступающих от окон данного класса.

Требования у Windows к данной процедуре несложные:

1) Если сообщение не обрабатывается процедурой, необходимо вызвать функцию DefWindowProc
2) Сохранить содержимое регистров rdi rsi rbx

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


Логика данного куска понятна без лишних комментариев.

1) Сохраним параметры в переменные
2) Вызовем высокоуровневую процедуру
3) Вызовем DefWindowProc, если получен не ноль

Теперь займемся высокоуровневой частью

Слово Форта само по себе является процедурой.


Какое something мы должны do, сейчас и будем выяснять.

В ассемблерной вставке мы видим использование переменной wmsg. Она принимает параметр uMsg — номер сообщения Windows. Нам необходимо сравнить содержимое wmsg с номером нужного нам сообщения, и если это тот номер, обработать сообщение. Вернуть ноль, чтобы DefWindowProc не вызывалась.


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


Всего два сообщения, а приходится напрягаться чтобы быть уверенным что написано правильно.
К счастью, конструкция Case… Of… EndOf… EndCase реализуется довольно легко и существенно украшает код.


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

Во-первых, здесь постоянно повторяется wmsg @ и =.

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

Пусть WM_LBUTTONDOWN, WM_LBUTTONUP и т.п. будут константами.


Стало гораздо красивее и понятнее. Но все равно слишком много лишних слов в листинге.


Решим эту задачу.
Самое простое — это реализовать слово }}. Оно — почти эквивалент слова EndOf, просто к нему мы присовкупим слово 0.


А вот и нет. Слово EndOf немедленного исполнения. Вместо того, чтобы скомпилироваться, оно будет исполнено. Исполнено во время компиляции слова }}. А нам надо, чтобы оно исполнялось во время компиляции модуля обработки сообщений.


Воспользуемся его Величеством Копипастом и напишем… Но для начала учтем, что слово }} должно быть немедленного исполнения.


Вставим слово }} на место 0 EndOf, и убедимся в его работоспособности.

Разберемся со словом }}Messages

Оно должно:

1) компилировать не ноль
2) выполнять EndCase
3) заканчивать компиляцию, аналогично ;WORD

Заметим, это слово немедленного исполнения.


А сейчас сконструируем открывающие слова. Начнем с Messages{{

Что оно должно делать?

4) запускать компиляцию
3) компилировать Case
2) делать адрес начала процедуры доступным вставке winproc
1) отмечать адрес, с которого начнется процедура обработки сообщений

Автоматическая компиляция запускается словом immediator. Оно заполняет поле параметров компилируемого слова соответственно исходному тексту. Полю параметров предшествует поле кода, которое в случае высокоуровневого определения должно содержать ссылку на адресный интерпретатор. Её нам дает константа interpret#. Слово Case суть синоним слова 0. Просто Case — немедленного исполнения, а 0 — обычное компилируемое слово.


Вызов inWinProc мы встречаем в ассемблерной вставке. Это так называемое векторное слово. Оно почти обычная константа, но вместо того, чтобы положить значение на стек, исполняет его.

Теперь самое интересное


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

На наше счастье в Форте существует понятие определяющего слова. Которые и предназначены для таких случаев.



Эээ… А зачем мы повторяем один и тот же текст слева и справа? И даже трижды. (Мы же определили ранее константы). Может быть стоит не определять константы, а сразу определять слова?


И… Не работает. Посмотрим повнимательнее. Во-первых, все эти слова должны быть немедленного исполнения. То-есть они должны скомпилировать код после DOES> в тело Messages{{.

Эта часть: COMPILE (?wm) COMPILE ?OF HERE COMPILE 0 все делает правильно. Но сразу после DOES> мы получаем значение, скомпилированное во время создания слова WM_L… А оно нам нужно во время исполнения слова Messages{{.

Нам надо всего-лишь скомпилировать это значение как литерал уже в тело Messages{{.


Подытожим. Удобно выделить общую, заголовочную часть в отдельный файл.


Файл

Послесловие

Заметьте, несмотря на использования языка Форт, мы ни разу не вспомнили про стек и не встретили ни одного слова манипуляции со стеком. А еще мы спрятали не самую кошмарную структуру управления. Её не видно, хоть она и есть. код получился более описательный, чем процедурный. Ко всему прочему, код не требует комментариев, он сам читается как комментарий. Форт-система, написанная на Форте является сама себе справочником. Еще один нюанс. Для разработки своей программы вы можете использовать средства любого уровня. От встроенного ассемблера, даже ниже, вы можете внести во встроенный ассемблер недостающие опкоды и мнемоники и до создания высокоуровневых, обобщающих инструментов, позволяющих создавать компактный выразительный код.