Как сделать оконный менеджер?

Создание собственного менеджера окон — непростая задача. Я знаю это, потому что я тоже делаю один;)

Вы можете использовать существующее, хотя, возможно, и не самое лучшее решение, например, Nuclex.UI, который я лично отверг, когда впервые увидел, но если вы не настроены на создание собственного WM, я предлагаю использовать его или гибридный подход WinForms-XNA.

Но если вы действительно твердо настроены на реализацию собственного оконного менеджера, вы должны понимать, как работает любой другой WM. Поскольку мы говорим о XNA, это означает Windows, а это означает Windows Explorer, у которого есть чему поучиться.

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

• Чтобы отслеживать все окна, я использую Dictionary<string, Window>, где Window — это пользовательский класс, а string — его уникальное имя для редких случаев, когда мне приходится вызывать окна по имени. Думайте об этом как о GUID или дескрипторе окна. Но вы можете просто сделать так, чтобы «Форма» появлялась только один раз и сохраняла все ссылки в статических переменных.

• Чтобы WM понял, какой элемент управления вы нажимаете, я использую прямоугольники и проверяю, содержат ли они Point, который находится в координатах курсора и имеет размер {1; 1} пикселей, что, вероятно, примерно так же, как это делается в проводнике Windows. Для этого ваш WM должен знать, в каком порядке обновлять активные окна. Обычно вы хотите начать с самого верхнего окна и продолжить к концу списка активных окон. Для этого вы можете просто перебрать список с помощью цикла foreach.

• Но это еще не все, потому что каждое окно само по себе является Container, что означает, что оно содержит другие элементы управления, некоторые из которых могут быть сами Container, например класс WinForms Panel. Это означает, что вам нужно выполнить итерацию по каждому из элементов управления Children Windows. Порядок обновления также должен иметь смысл — обновление от самого верхнего дочернего элемента к самому нижнему, рекурсивно для элементов управления Container, если в них также есть элементы Container. По сути, это означает, что вы захотите реализовать рекурсивный метод GetAllControls() для вашего класса WindowManager, который перебирает все Containers и возвращает список всех Control.

• Отрисовка всех этих Control должна выполняться в порядке, обратном их обновлению, поэтому вы можете просто GetAllControls().Reverse() и перебирать его в цикле foreach.

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

• Когда вы щелкаете где-нибудь на экране, и щелчок регистрируется на Control, заставьте WindowManager помнить об этом (bool clickRegistered) и не запускайте никакие события OnClick на каких-либо базовых Control.

• Проводник Windows запоминает элемент управления, на который вы нажали, и активирует его событие OnRelease, если затем отпустить курсор в области обновления того же элемента управления. Таким образом, в основном диспетчер Windows делает что-то только тогда, когда вы отпускаете кнопку мыши. Вы можете настроить WindowManager и Control для обработки событий щелчка по-разному, например, запускать событие сразу после нажатия кнопки мыши, то есть OnMouseDown. Но помните, что Microsoft не нубы, и есть причина такого поведения в проводнике Windows, и это потому, что если вы случайно нажмете кнопку мыши не там, где вы собирались, вы все равно можете исправить это, переместив курсор за пределы обновления нажатого элемента управления. область и не запускать ее действие.

В этот момент вы можете подумать: «Действительно ли стоит все это реализовывать?» Для меня ответ был «может быть», потому что я был полным нубом в C# и XNA в то время, когда я начинал, и теперь я знаю, что моя игра, которая изначально должна была использовать некоторый оконный менеджер, выиграет от моего собственного Внедрения WM гораздо больше, чем от готовых сторонних решений. Кроме того, это отличное упражнение в логике и программировании.

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

Вместо того, чтобы иметь структуру с 4 булевыми значениями (аналогично xna), как насчет того, чтобы указать, где «находится» мышь. Таким образом, в некотором смысле мышь находится в окне номер 5, который является Paint, и пользователь удерживает мышь на интерфейсе /control номер 2, который является кнопкой. Похоже, это может сработать.