Сообщение Re[5]: Реализации независимых элементов GUI под винду от 10.03.2021 16:07
Изменено 10.03.2021 16:08 Videoman
Re[5]: Реализации независимых элементов GUI под винду
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>В частности, смотрел сюда
Названия такие же или похожи, но принцип совершенно другой. Это другой CMainWindow и другой CWindow. В WTL ты спокойно можешь прицепиться к WinAPI окну которое о нем знать не знает и спокойно с ним работать.
ЕМ>И зачастую громоздко. Вместо одной функции на пару страниц с простым switch и частью общего кода, приходится писать несколько независимых функций, в которых этот общий код повторяется, или выносить его в дополнительную функцию. В итоге логика очень сильно размазывается.
Странно считать что разделение связанной логики по разным функция что-то там "размазывает". Сейчас в программировании это наоборот тренд: все становится функциональным. Кругом маленькие "чистые" функции на каждый чих. Все равно что заявить: что для вызова любой функции нужен только указатель и AX, BX, CX, DX... все остальное это размазывание. (шучу
)
ЕМ>Какая связь между сабклассингом и способом передачи сообщений в мой код? Оно точно так же могло бы сразу вызывать у меня что-то вроде OnMessage (Msg, WP, LP). А там бы я либо использовал if/switch по Msg, либо вызывал какой-нибудь CrackMessage, который бы все разбирал и вызывал мои OnXxx. Это и раздражает, что вместе с полезным/удобным непременно навязывается что-нибудь бесполезное/неудобное.
Такая что к каждому окну по умолчанию привязана функция обработчик, и если ты хочешь хоть на миллиметр отклониться от дефолтного поведения, то ты должен сабкласить функцию окна. Другими словами ты должен подставить свою функцию, где ты будешь менять только то поведение, которое отличается от стандартного. С С++ под эту основу один в один ложатся классы обертки и их наследование друг от друга. И да, в WinAPI эта аналогия не до конца такая же. Если проводить аналогию с классами С++, то там можно подменить таблицу виртуальных функций у отдельного экземпляра класса.
ЕМ>И как там избавиться от "канонических" компоновки кода и передачи управления, чтобы максимум того управления оставить себе?
Ну класс окна определяет чем его поведение отличается от стандартного. Просто делаешь Attach к хендлу нужного окна. Сама процедура окна, на сколько я помню, сабкласится, но тутже вызывает старую, и ты спокойно можешь переопределять только то что нужно.
Я, например, у себя никакого event-loop не создаю. Я вообще не знаю кто и как его создает, т.к. меня вызывает стороннее приложение и все замечательно работает. Поверь, ATL/WTL это не MFC, хотя MFC используют их если нужно.
ЕМ>В частности, смотрел сюда
Автор(ы): Александр Шаргин
Дата: 21.04.2001
Первая часть статьи посвящена основам WTL. Автор даёт краткий обзор WTL, описывает процесс её установки, а затем объясняет базовые средства поддержки оконного интерфейса: иерархию оконных классов, циклы сообщений и карты сообщений.
. Там, как и в MFC, все через CMainWindow/CMessageLoop — управление сразу же отдается WTL, который вызывает перекрытые методы своих классов.Дата: 21.04.2001
Первая часть статьи посвящена основам WTL. Автор даёт краткий обзор WTL, описывает процесс её установки, а затем объясняет базовые средства поддержки оконного интерфейса: иерархию оконных классов, циклы сообщений и карты сообщений.
Названия такие же или похожи, но принцип совершенно другой. Это другой CMainWindow и другой CWindow. В WTL ты спокойно можешь прицепиться к WinAPI окну которое о нем знать не знает и спокойно с ним работать.
ЕМ>И зачастую громоздко. Вместо одной функции на пару страниц с простым switch и частью общего кода, приходится писать несколько независимых функций, в которых этот общий код повторяется, или выносить его в дополнительную функцию. В итоге логика очень сильно размазывается.
Странно считать что разделение связанной логики по разным функция что-то там "размазывает". Сейчас в программировании это наоборот тренд: все становится функциональным. Кругом маленькие "чистые" функции на каждый чих. Все равно что заявить: что для вызова любой функции нужен только указатель и AX, BX, CX, DX... все остальное это размазывание. (шучу
)ЕМ>Какая связь между сабклассингом и способом передачи сообщений в мой код? Оно точно так же могло бы сразу вызывать у меня что-то вроде OnMessage (Msg, WP, LP). А там бы я либо использовал if/switch по Msg, либо вызывал какой-нибудь CrackMessage, который бы все разбирал и вызывал мои OnXxx. Это и раздражает, что вместе с полезным/удобным непременно навязывается что-нибудь бесполезное/неудобное.
Такая что к каждому окну по умолчанию привязана функция обработчик, и если ты хочешь хоть на миллиметр отклониться от дефолтного поведения, то ты должен сабкласить функцию окна. Другими словами ты должен подставить свою функцию, где ты будешь менять только то поведение, которое отличается от стандартного. С С++ под эту основу один в один ложатся классы обертки и их наследование друг от друга. И да, в WinAPI эта аналогия не до конца такая же. Если проводить аналогию с классами С++, то там можно подменить таблицу виртуальных функций у отдельного экземпляра класса.
ЕМ>И как там избавиться от "канонических" компоновки кода и передачи управления, чтобы максимум того управления оставить себе?
Ну класс окна определяет чем его поведение отличается от стандартного. Просто делаешь Attach к хендлу нужного окна. Сама процедура окна, на сколько я помню, сабкласится, но тутже вызывает старую, и ты спокойно можешь переопределять только то что нужно.
Я, например, у себя никакого event-loop не создаю. Я вообще не знаю кто и как его создает, т.к. меня вызывает стороннее приложение и все замечательно работает. Поверь, ATL/WTL это не MFC, хотя MFC используют их если нужно.
Re[5]: Реализации независимых элементов GUI под винду
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>В частности, смотрел сюда
Названия такие же или похожи, но принцип совершенно другой. Это другой CMainWindow и другой CWindow. В WTL ты спокойно можешь прицепиться к WinAPI окну которое о нем знать не знает и спокойно с ним работать.
ЕМ>И зачастую громоздко. Вместо одной функции на пару страниц с простым switch и частью общего кода, приходится писать несколько независимых функций, в которых этот общий код повторяется, или выносить его в дополнительную функцию. В итоге логика очень сильно размазывается.
Странно считать что разделение связанной логики по разным функция что-то там "размазывает". Сейчас в программировании это наоборот тренд: все становится функциональным. Кругом маленькие "чистые" функции на каждый чих. Все равно что заявить: что для вызова любой функции нужен только указатель и AX, BX, CX, DX... все остальное это размазывание. (шучу )
ЕМ>Какая связь между сабклассингом и способом передачи сообщений в мой код? Оно точно так же могло бы сразу вызывать у меня что-то вроде OnMessage (Msg, WP, LP). А там бы я либо использовал if/switch по Msg, либо вызывал какой-нибудь CrackMessage, который бы все разбирал и вызывал мои OnXxx. Это и раздражает, что вместе с полезным/удобным непременно навязывается что-нибудь бесполезное/неудобное.
Такая что к каждому окну по умолчанию привязана функция обработчик, и если ты хочешь хоть на миллиметр отклониться от дефолтного поведения, то ты должен сабкласить функцию окна. Другими словами ты должен подставить свою функцию, где ты будешь менять только то поведение, которое отличается от стандартного. С С++ под эту основу один в один ложатся классы обертки и их наследование друг от друга. И да, в WinAPI эта аналогия не до конца такая же. Если проводить аналогию с классами С++, то в WinAPI можно подменить таблицу виртуальных функций у отдельного экземпляра класса.
ЕМ>И как там избавиться от "канонических" компоновки кода и передачи управления, чтобы максимум того управления оставить себе?
Ну класс окна определяет чем его поведение отличается от стандартного. Просто делаешь Attach к хендлу нужного окна. Сама процедура окна, на сколько я помню, сабкласится, но тутже вызывает старую, и ты спокойно можешь переопределять только то что нужно.
Я, например, у себя никакого event-loop не создаю. Я вообще не знаю кто и как его создает, т.к. меня вызывает стороннее приложение и все замечательно работает. Поверь, ATL/WTL это не MFC, хотя MFC используют их если нужно.
ЕМ>В частности, смотрел сюда
Автор(ы): Александр Шаргин
Дата: 21.04.2001
Первая часть статьи посвящена основам WTL. Автор даёт краткий обзор WTL, описывает процесс её установки, а затем объясняет базовые средства поддержки оконного интерфейса: иерархию оконных классов, циклы сообщений и карты сообщений.
. Там, как и в MFC, все через CMainWindow/CMessageLoop — управление сразу же отдается WTL, который вызывает перекрытые методы своих классов.Дата: 21.04.2001
Первая часть статьи посвящена основам WTL. Автор даёт краткий обзор WTL, описывает процесс её установки, а затем объясняет базовые средства поддержки оконного интерфейса: иерархию оконных классов, циклы сообщений и карты сообщений.
Названия такие же или похожи, но принцип совершенно другой. Это другой CMainWindow и другой CWindow. В WTL ты спокойно можешь прицепиться к WinAPI окну которое о нем знать не знает и спокойно с ним работать.
ЕМ>И зачастую громоздко. Вместо одной функции на пару страниц с простым switch и частью общего кода, приходится писать несколько независимых функций, в которых этот общий код повторяется, или выносить его в дополнительную функцию. В итоге логика очень сильно размазывается.
Странно считать что разделение связанной логики по разным функция что-то там "размазывает". Сейчас в программировании это наоборот тренд: все становится функциональным. Кругом маленькие "чистые" функции на каждый чих. Все равно что заявить: что для вызова любой функции нужен только указатель и AX, BX, CX, DX... все остальное это размазывание. (шучу
)ЕМ>Какая связь между сабклассингом и способом передачи сообщений в мой код? Оно точно так же могло бы сразу вызывать у меня что-то вроде OnMessage (Msg, WP, LP). А там бы я либо использовал if/switch по Msg, либо вызывал какой-нибудь CrackMessage, который бы все разбирал и вызывал мои OnXxx. Это и раздражает, что вместе с полезным/удобным непременно навязывается что-нибудь бесполезное/неудобное.
Такая что к каждому окну по умолчанию привязана функция обработчик, и если ты хочешь хоть на миллиметр отклониться от дефолтного поведения, то ты должен сабкласить функцию окна. Другими словами ты должен подставить свою функцию, где ты будешь менять только то поведение, которое отличается от стандартного. С С++ под эту основу один в один ложатся классы обертки и их наследование друг от друга. И да, в WinAPI эта аналогия не до конца такая же. Если проводить аналогию с классами С++, то в WinAPI можно подменить таблицу виртуальных функций у отдельного экземпляра класса.
ЕМ>И как там избавиться от "канонических" компоновки кода и передачи управления, чтобы максимум того управления оставить себе?
Ну класс окна определяет чем его поведение отличается от стандартного. Просто делаешь Attach к хендлу нужного окна. Сама процедура окна, на сколько я помню, сабкласится, но тутже вызывает старую, и ты спокойно можешь переопределять только то что нужно.
Я, например, у себя никакого event-loop не создаю. Я вообще не знаю кто и как его создает, т.к. меня вызывает стороннее приложение и все замечательно работает. Поверь, ATL/WTL это не MFC, хотя MFC используют их если нужно.