Архитектура и взаимодействие контролов между собой

#c_sharp #winforms #net

Хотелось бы литературы, описывающей архитектуру и взаимодействие контролов между
собой на немного более глубоком уровне, чем «Тут мы наследуемся от UserControl, тут
переопределяем пару методов, и это собственно всё, что вам нужно знать».
Для ясности слов «архитектура» и «взаимодействие», вот примерный список гложущих
меня вопросов:

У каждого контрола есть свой Graphics. А как и в каком порядке они складываются в
единую картинку?
Когда контрол хочет себя перерисовать, кого и как он об этом оповещает?
Где-то слышал про единый для всего приложения пулл событий. Как они расползаются
до конечных контролов?
Как правильно убивать контролы? Простым Dispose() или ещё удалять из parent.Controls?
И т. п.

Буду рад подробной статье, но и от глав из книги не откажусь.    

Ответы

Ответ 1

Если вы говорите действительно о Windows Forms, а не, например, о WPF, то вся эта
библиотека является лишь хорошо спроектированной оберткой над частью WinAPI для работы
с визуальными компонентами. 
Поскольку тема достаточно обширная, то в кратком ответе все это рассказать не удастся;
предлагаю вам начать изучение со статей по базовым принципам разработки оконных приложений
и с изучения функции SendMessage на MSDN.

Далее - конкретно по вашим вопросам:


Graphics сам по себе никуда не складывается, это лишь обертка над некоторым регионом
формы, отрисовываемой с помощью WinAPI. То есть Graphics предоставляет возможность
изменять механизм отрисовки конкретного контрола, не затрагивая при этом общей логики
этой самой отрисовки. По поводу порядка - у каждого контрола есть свой z-index, который
можно изменить, например, с помощью функции Controls.SetChildIndex и именно этот индекс
учитывается при инвалидации формы.


Все сообщения в WinAPI проходят через так называемый Message pump, при этом кто угодно
может послать сообщение о перерисовке. Здесь для понимания следует прочесть статьи
про сообщение WM_PAINT и методы инвалидации - Controls.Invalidate, который на деле
маршаллит методы типа InvalidateRect.


См. (2)


Опять же из соображений использования unmanaged кода внутри managed (при маршаллинге
вызовов WinAPI), необходимо освобождать все выделенные ресурсы типа HXXRESOURCE, это
реализуется в методе Dispose. Поскольку форма является контейнером для других контролов,
то именно она несет ответственность за их освобождение, т.е метод Form.Dispose по контракту
должен вызывать методы Dispose для всех ее контролов. Если этого не происходит, то
это плохо.


Если интересно, то можете изучить исходный код Windows.Forms и посмотреть, как именно
в нем все реализовано. Интерес представляет также альтернативная реализация mono-winforms.
Рекомендую также ознакомиться с идеологией WPF и задуматься над архитектурными решениями,
которые были приняты в ходе разработки этой библиотеки.