Как приложения win32, использующие sigc и glib, реализуют цикл сообщений

Question

Если приложение Win32 имеет свой пользовательский интерфейс, разработанный с использованием sigc и glibmm, как он реализует свои циклы сообщений? он все еще использует Win32 API, такой как GetMessage, DispatchMessage, TranslateMessage и т. д.? или они используют другие функции, чтобы закончить это? А WinProc по умолчанию все еще там?

Answer 1

sigc + glibmm - это уровень C ++ поверх цикла обратных вызовов / основного цикла GTK C Framework, который находится поверх собственного цикла обратного вызова / основного цикла (NSRunLoop для MacOSX и GetMessage в Windows).

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

TranslateMessage не требуется, поскольку клавиши акселератора обрабатываются собственной реализацией GTK.

SendMessage используется очень редко, большинство вызовов, которые требуют SendMessage, являются вызовами клиентского элемента управления, такого как виджет кнопки или текстового поля. В GTK они реализованы как GtkButton и GtkEntry, и GTK может напрямую использовать реализацию C без прохождения диспетчеризации сообщений Windows.

Answer 2

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

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