Реализации независимых элементов GUI под винду - C/C++. Прикладные вопросы

Кто какие знает реализации независимых (вне фреймворков) элементов GUI под винду, сделанных наподобие встроенных виндовых controls, и доступных в виде библиотек с произвольным выбором отдельных элементов?

Иногда хочется добавить какие-нибудь интеллектуальные элементы вроде настроек в стиле VS, но самому делать лень, а подключать для этого фреймворки — слишком накладно.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Кто какие знает реализации независимых (вне фреймворков) элементов GUI под винду, сделанных наподобие встроенных виндовых controls, и доступных в виде библиотек с произвольным выбором отдельных элементов?

ЕМ>Иногда хочется добавить какие-нибудь интеллектуальные элементы вроде настроек в стиле VS, но самому делать лень, а подключать для этого фреймворки — слишком накладно.
Я как-то делал "умный" HotKeyCtrl, в который добавлял разные возможности: настроить как двойное нажатие клавиши, выбор сочетаний клавиш из контекстного меню, всякие нотификации добавлял на предмет настройки горячей клавишы изменены, или он занята и все такое.

Реализовывал на чистом C++ и только WinAPI-стиле. То бишь саму суть вышеперечисленную. Ну и реализации в стиле WinAPI: управление этим HotKey-контролом через сообщения, нотификации в стиле WinAPI (получили парент, отослали ему WM_NOTIFY с указателем на наследника от структуры NMHDR).

А потом уж добавил классы-обвязки для MFC, и WTL… Чисто для удобства и только — внутрях эти обвязки дергают это самое pure WinApi ядро.
Ибо абсолютно старые проекты — и переписывать саму суть заново для каждого фреймворка как-то заломало.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Кто какие знает реализации независимых (вне фреймворков) элементов GUI под винду, сделанных наподобие встроенных виндовых controls, и доступных в виде библиотек с произвольным выбором отдельных элементов?

ЕМ>Иногда хочется добавить какие-нибудь интеллектуальные элементы вроде настроек в стиле VS, но самому делать лень, а подключать для этого фреймворки — слишком накладно.

Что-то типа грида.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Кто какие знает реализации независимых (вне фреймворков) элементов GUI под винду, сделанных наподобие встроенных виндовых controls, и доступных в виде библиотек с произвольным выбором отдельных элементов?

Посмотри на WTL. Помимо самого WTL-я есть куча отдельных контролов на WTL-е в инете.

Здравствуйте, gwg-605, Вы писали:

G6>Посмотри на WTL. Помимо самого WTL-я есть куча отдельных контролов на WTL-е в инете.

ATL/WTL я давно смотрел, но они оба фреймворки (подразумевают, что весь мой код строится вокруг них, и вызывается оттуда). В частности, не нравится (как и в MFC) идея делать отдельную функцию для обработки каждого сообщения — получается слишком громоздко, во многих случаях банальный switch записывается в несколько раз компактнее и яснее.

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

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>...
ЕМ>Хочется именно автономных контролов, как стандартные виндовые, которые можно встроить в код любой парадигмы и структуры.

А вы пример можете привести? Делать полностью абстрактные контролы очень тяжело — нужно очень много писать руками, в том числе логику.
Фреймворки как раз призваны упростить разработку контролов. Сравните, к примеру, сложность реализации пользовательской логики для дерева из Qt (QTreeView) и винапишного.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>ATL/WTL я давно смотрел, но они оба фреймворки (подразумевают, что весь мой код строится вокруг них, и вызывается оттуда).
Что-то ты не туда смотрел. ATL/WTL просто шаблонные обмотки вокруг разных аспектов WinAPI и процедур окна. Они ничего не требуют от тебя больше. MFC — да, монстр фрейворк. ATL/WTL — нет.

ЕМ>В частности, не нравится (как и в MFC) идея делать отдельную функцию для обработки каждого сообщения — получается слишком громоздко, во многих случаях банальный switch записывается в несколько раз компактнее и яснее.
Зря ты, как раз очень удобно. Все параметры сообщений уже разобраны. Ты просто перекрываешь нужный метод и меняешь только то что нужно. Так тебе придется сабкласить окна и прокидывать все не нужные тебе сообщения пока ты сделаешь что-то нужное.

ЕМ>Хочется именно автономных контролов, как стандартные виндовые, которые можно встроить в код любой парадигмы и структуры.
Я использую WTL именно так как ты говоришь. Конкретнее в DirectShow Property Page-ах, которые вообще хрен знает кем создаются и вообще COM.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Хочется именно автономных контролов, как стандартные виндовые, которые можно встроить в код любой парадигмы и структуры.
Вы хотите невозможного: любые контролы должны иметь свой event loop, цикл обрабоки сообщений или что-то подобное, вся логика программы будет плясать от этого. Можно по максимому разделить ГУЙ и бизнес-логику, разбить их на 2 приложения.

А в чем проблема встроится, например, в Qt-шный event loop? Религия, квалификация?

Здравствуйте, Skorodum, Вы писали:

ЕМ>>Хочется именно автономных контролов, как стандартные виндовые, которые можно встроить в код любой парадигмы и структуры.
S>Вы хотите невозможного: любые контролы должны иметь свой event loop, цикл обрабоки сообщений или что-то подобное,

Чего?

S>А в чем проблема встроится, например, в Qt-шный event loop? Религия, квалификация?

Какой кутишный ивент-луп в виндовом приложении?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>ATL/WTL я давно смотрел, но они оба фреймворки (подразумевают, что весь мой код строится вокруг них, и вызывается оттуда). В частности, не нравится (как и в MFC) идея делать отдельную функцию для обработки каждого сообщения — получается слишком громоздко, во многих случаях банальный switch записывается в несколько раз компактнее и яснее.

ЕМ>Хочется именно автономных контролов, как стандартные виндовые, которые можно встроить в код любой парадигмы и структуры.

А вы на голом винапи пишете?

Здравствуйте, SaZ, Вы писали:

SaZ>А вы пример можете привести?

Да хоть нечто подобное таблице параметров, что в правой части диалога настроек MS VS. Где у каждого параметра есть тип, умолчание, возможные варианты значений и т.п.

SaZ>Делать полностью абстрактные контролы очень тяжело — нужно очень много писать руками, в том числе логику.

Что такое "полностью абстрактные"? Хочется, как в WinAPI, создать такой элемент, последовательными вызовами методов набить его данными, задать какие-то особенности поведения, и активировать, задав при этом объект callback-класса (или просто функцию), через которые он будет сообщать о событиях и просить уточнений.

SaZ>Фреймворки как раз призваны упростить разработку контролов. Сравните, к примеру, сложность реализации пользовательской логики для дерева из Qt (QTreeView) и винапишного.

Там разница не в том, что Qt — фреймворк, а в том, что соответствующий элемент Qt уже набит логикой (как нужной мне, так и напрочь не нужной), а винапишный — примитивная заготовка.

Здравствуйте, Videoman, Вы писали:

V>Что-то ты не туда смотрел. ATL/WTL просто шаблонные обмотки вокруг разных аспектов WinAPI и процедур окна.

В частности, смотрел сюда. Там, как и в MFC, все через CMainWindow/CMessageLoop — управление сразу же отдается WTL, который вызывает перекрытые методы своих классов.

V>Зря ты, как раз очень удобно.

И зачастую громоздко. Вместо одной функции на пару страниц с простым switch и частью общего кода, приходится писать несколько независимых функций, в которых этот общий код повторяется, или выносить его в дополнительную функцию. В итоге логика очень сильно размазывается.

V>Все параметры сообщений уже разобраны. Ты просто перекрываешь нужный метод и меняешь только то что нужно. Так тебе придется сабкласить окна и прокидывать все не нужные тебе сообщения пока ты сделаешь что-то нужное.

Какая связь между сабклассингом и способом передачи сообщений в мой код? Оно точно так же могло бы сразу вызывать у меня что-то вроде OnMessage (Msg, WP, LP). А там бы я либо использовал if/switch по Msg, либо вызывал какой-нибудь CrackMessage, который бы все разбирал и вызывал мои OnXxx. Это и раздражает, что вместе с полезным/удобным непременно навязывается что-нибудь бесполезное/неудобное.

V>Я использую WTL именно так как ты говоришь.

И как там избавиться от "канонических" компоновки кода и передачи управления, чтобы максимум того управления оставить себе?

Здравствуйте, Skorodum, Вы писали:

S>любые контролы должны иметь свой event loop, цикл обрабоки сообщений

С чего вдруг? Они должны иметь свои оконные процедуры, которые будут вызываться из основного (и часто единственного) цикла обработки. А там они или могут все делать сами, если знают, как, или заранее оговоренным способом дергать мой код.

S>А в чем проблема встроится, например, в Qt-шный event loop? Религия, квалификация?

Qt меня отвращает прежде всего своей монстроидальностью. Типовые варианты готовых DLL, заточенные на изготовление красивых и броских интерфейсов, очень тяжелы. Простейших, минимальных сборок, без украшений, с разумной функциональностью не дают. Чтобы их собрать, нужно вдумчиво разбираться в структуре, правилах настройки, сборки и т.п. Ну и Qt все строит вокруг себя. Он, как и MFC, должен господствовать в приложении, а мой код — быть подчиненным. Чтобы отобрать эту страсть к господству, нужно опять же вдумчиво разбираться. Когда нужно изготовить сложный и развесистый UI к приложению хотя бы на десяток мегабайт кода, Qt весьма неплох. В сочетании с моим кодом в сотню-другую килобайт оно будет смотреться по-дурацки.

Здравствуйте, Михaил, Вы писали:

М>А вы на голом винапи пишете?

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

Здравствуйте, Евгений Музыченко, Вы писали:

V>>Что-то ты не туда смотрел. ATL/WTL просто шаблонные обмотки вокруг разных аспектов WinAPI и процедур окна.

ЕМ>В частности, смотрел сюда. Там, как и в MFC, все через CMainWindow/CMessageLoop — управление сразу же отдается WTL, который вызывает перекрытые методы своих классов.

А какая связь между MessageLoop и твоим контролом? И какая разница, кто, где, и как реализован?

ЕМ>И зачастую громоздко. Вместо одной функции на пару страниц с простым switch и частью общего кода, приходится писать несколько независимых функций, в которых этот общий код повторяется, или выносить его в дополнительную функцию. В итоге логика очень сильно размазывается.

Я писал и на на одном switch, и на WTL. На WTL гораздо проще, там зачастую всё уже написано, надо только дёрнуть подходящее

ЕМ>Какая связь между сабклассингом и способом передачи сообщений в мой код? Оно точно так же могло бы сразу вызывать у меня что-то вроде OnMessage (Msg, WP, LP). А там бы я либо использовал if/switch по Msg, либо вызывал какой-нибудь CrackMessage, который бы все разбирал и вызывал мои OnXxx. Это и раздражает, что вместе с полезным/удобным непременно навязывается что-нибудь бесполезное/неудобное.

Ну и кто тебе мешает писать на чистом WinAPI?

V>>Я использую WTL именно так как ты говоришь.

ЕМ>И как там избавиться от "канонических" компоновки кода и передачи управления, чтобы максимум того управления оставить себе?

Тащем-то, в WTL есть "карта" сообщений, которая строиться из макросов, которые на самом деле есть if'ы с message cracker'ами. И тебе никто не мешает туда запендюрить свои if'ы и делать в них всё, что твоей душе угодно

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>С чего вдруг? Они должны иметь свои оконные процедуры, которые будут вызываться из основного (и часто единственного) цикла обработки. А там они или могут все делать сами, если знают, как, или заранее оговоренным способом дергать мой код.
В Qt можно и так, явно вызвать обработку сообщений когда тебе удобно.
QEventLoop::processEvents

ЕМ>Qt меня отвращает прежде всего своей монстроидальностью. Типовые варианты готовых DLL, заточенные на изготовление красивых и броских интерфейсов, очень тяжелы.
Что значит тяжелы? ~20 мегабайт.
vc_redist.x64.exe — 16 мегабайт.

ЕМ>Простейших, минимальных сборок, без украшений, с разумной функциональностью не дают.
Специальная сборка не нужна. qtwindeployqt устанавливает только то, что нужно.

ЕМ>Чтобы их собрать, нужно вдумчиво разбираться в структуре, правилах настройки, сборки и т.п.
Да не нужно все это в 99% случаев.

ЕМ>Ну и Qt все строит вокруг себя. Он, как и MFC, должен господствовать в приложении, а мой код — быть подчиненным.
Это какая-то религия пошла... ГУЙ — он событийно-управляемый, кто-то должен запускать обработчик сообщений. Хочешь сам, хочешь используй стандартный Qt-шный подход:

int main(int argc, char *argv[])
{
    Application application(argc, argv);
    return application.exec();
}

ЕМ>Чтобы отобрать эту страсть к господству, нужно опять же вдумчиво разбираться.
И никакого выигрыша ты не получишь.

ЕМ>Когда нужно изготовить сложный и развесистый UI к приложению хотя бы на десяток мегабайт кода, Qt весьма неплох. В сочетании с моим кодом в сотню-другую килобайт оно будет смотреться по-дурацки.
А какая разница, какого размера у тебя бизнес-логика? В чем проблема, если в дистрибутиве большая часть это гуёвая библиотека?
Думаешь кто-то будет смотреть процентное соотношение размеров разныех длл-ек после установки?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Кто какие знает реализации независимых (вне фреймворков) элементов GUI под винду, сделанных наподобие встроенных виндовых controls, и доступных в виде библиотек с произвольным выбором отдельных элементов?

Такое IMHO может сделать только сама Microsoft. Зачем кому-то еще такое делать.
Это же не будет ни интелисенса нормального, ни поддержки фреймворков, может быть будет использоваться 0.01% разработчиков.

ЕМ>Иногда хочется добавить какие-нибудь интеллектуальные элементы вроде настроек в стиле VS, но самому делать лень, а подключать для этого фреймворки — слишком накладно.

Я когда под винду писал, такие вещи на чем-то типа codeproject искались. Вот например PropertyGrid на чистом WinAPI
https://www.codeproject.com/Articles/77957/Win-SDK-PropertyGrid-Made-Easy

Я сам не пробовал. Поскольку самиздат, скорее всего будут глюки, с которыми придется героически бороться.

Не рассматривал вариант перейти на HTML? Плюс несколько мегабайт, и практически неограниченные возможности для UI. Под винду сейчас еще WebView2 появился.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>В частности, смотрел сюда. Там, как и в MFC, все через CMainWindow/CMessageLoop — управление сразу же отдается 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 используют их если нужно.

Здравствуйте, удусекшл, Вы писали:

У>А какая связь между MessageLoop и твоим контролом? И какая разница, кто, где, и как реализован?

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

У>Ну и кто тебе мешает писать на чистом WinAPI?

Его недостаточная функциональность.

А как только пытаюсь использовать что-то стороннее — оно или навязывает свою парадигму, или тянет за собой слишком много зависимостей, или еще что.

У>в WTL есть "карта" сообщений, которая строиться из макросов, которые на самом деле есть if'ы

Хм, я считал, что в WTL оно табличное, как и в MFC. В последовательность if'ов влезть гораздо проще, чем в таблицу.

Еще меня много лет тормозило в использовании сторонних средств то, что я когда-то давно сделал себе небольшое подмножество CRT, чтобы не тащить в EXE лишние зависимости, и заодно лучше контролировать ошибки памяти. На мелких утилитах это давало трех-пятикратное уменьшение размера EXE, вместе с ранней ловлей распространенных ляпов. А потом настолько привык работать внутри этого подмножества, что вылезать за его пределы стало даже как-то некомфортно.

Теперь логика UI в некоторых приложениях разрослась настолько, что обрезание CRT уже перестало давать заметное уменьшение EXE, так что надо заставить себя использовать и сторонние средства.

Здравствуйте, Skorodum, Вы писали:

ЕМ>>Типовые варианты готовых DLL, заточенные на изготовление красивых и броских интерфейсов, очень тяжелы.

S>Что значит тяжелы? ~20 мегабайт.

У меня самые тяжелые EXE — 120-150 кило байт x86, 170-200 — x64.

Для них даже 5-10 мегабайт чистого UI — это очень много, а 20 — неимоверно, чудовищно много.

Вопрос ведь даже не в том, что они тяжелые сами по себе. Хранилища нынче большие, каналы широкие, и те 20-25 Мб даже на дохлом ADSL в 5 Мбит/с скачиваются за полминуты. Реально меня вымораживает то, насколько это все избыточно. С одной стороны нам трудолюбиво втирают, что нужно повышать повторную используемость кода, использовать компактные конструкции вместо развесистых, а с другой — столь же трудолюбиво клепают софт, избыточный на тысячи и более процентов, и подают его так, будто это нормально.

Когда на Qt делают масштабный продукт вроде VirtualBox, который по определению не может быть компактным — это вполне оправдано (хотя в итоге VBox, при функциональности, сравнимой с VMware Workstation, минимум вдвое компактнее). А когда объем кода UI, из которого больше половины никогда не используется, в несколько раз превышает объем кода логики приложения — это явный идиотизм. Когда же в систему ставится множество приложений, каждое из которых тащит с собой собственные копии одного и того же кода UI — это идиотизм в квадрате.

S>Специальная сборка не нужна. qtwindeployqt устанавливает только то, что нужно.

И какой объем UI-кода он мне установит для добавления в приложения только базовой функциональности UI, без локализации, цветовых градиентов, анимации и прочих чисто эстетических плюшек?

ЕМ>>Чтобы их собрать, нужно вдумчиво разбираться в структуре, правилах настройки, сборки и т.п.
S>Да не нужно все это в 99% случаев.

Так в этих случаях получается перевес объема кода UI над логикой в несколько раз минимум.

S>Хочешь сам, хочешь используй стандартный Qt-шный подход:

И как я могу выдрать из Qt обработчики его отдельных элементов UI, чтобы вызывать их из своего цикла обработки сообщений, и чтобы они не тянули за собой всю инфраструктуру Qt, предназначенную для организации платформенно-независимой среды? Они же внутри себя, как я понимаю, работают не с WinAPI, а с элементами этой самой среды, которая составляет изрядную часть кода.

S>В чем проблема, если в дистрибутиве большая часть это гуёвая библиотека?
S>Думаешь кто-то будет смотреть процентное соотношение размеров разныех длл-ек после установки?

Это буду смотреть я сам.

Понимаю, что большинство юзеров сглотнет и не такое, но изготавливать технически убогий шлак мне претит.

От:	Евгений Музыченко	https://software.muzychenko.net/ru
Дата:	11.02.21 07:19
Оценка:	2 (1) -1

От:	Carc	https://vk.com/gosha_mazov
Дата:	11.02.21 11:36
Оценка:

	От:	McQwerty
	Дата:	11.02.21 13:33
	Оценка:	12 (1) -1

	От:	gwg-605
	Дата:	08.03.21 23:35
	Оценка:

От:	Евгений Музыченко	https://software.muzychenko.net/ru
Дата:	09.03.21 02:45
Оценка:

От:	Videoman	https://hts.tv/
Дата:	09.03.21 16:18
Оценка:

	От:	удусекшл
	Дата:	10.03.21 08:35
	Оценка:

От:	bnk	http://unmanagedvisio.com/
Дата:	10.03.21 14:16
Оценка:	14 (2) +1