Графический интерфейс пользователя в приложениях на языке C++

[D_KEY]

Цитата B.V. @ 02.09.10, 09:05

D_KEY, чем спорить, предложи свое видение плюсов и минусов
Если несогласных не будет, его и добавим

Хорошо, но не раньше выходных. И я не спорю, просто высказал свое мнение по одному отдельновзятому минусу

[Повстанець]

2 слова на счёт WTL. Во первых там таки есть конструктор форм. Не знаю, что подразумевается под словом "собственный", но он такой же не "собственный" как и у MFC. И функционал предоставляет такой же. И вообще это конструктор не MFC, а встроенный в студию. И адаптируется он под конкретную либу посредством набора скриптов и шаблонов кода. Так что либо в MFC надо убрать из плюсов, либо в WTL убрать из минусов. Ну это ИМХО. Так же смутила строка

Цитата B.V. @ 28.08.10, 09:21

Весьма незначительно упрощает работу, по сравнению с "голым" Win32 API

Тут как бы всё относительно. Если брать относительно мощности хотя бы MFC, то таки да. Незначительно. А если взять в сыром виде WTL vs WinApi, то WTL способен экономить десятки человекочасов. А если брать связку WTL+ATL для работы с СОМ (собственно для чего это всё и затеивалось), то тут вообще сплошная прибыль идёт. Так что в корне не согласен я с такой постоновкой. Ну это так... не холивара ради, а просто к слову.

[B.V.]

Цитата Повстанець @ 13.09.10, 18:12

Не знаю, что подразумевается под словом "собственный", но он такой же не "собственный" как и у MFC.

Начнем с того, что в студии не предусмотрено шаблонов проектов WTL. А именно на это будет смотреть любой начинающий пользователь
И шаблоны MFC непосредственно перед созданием проекта предоставляют настройки для GUI, на базе шаблонов диалогов. В случае с WTL, все диалоги придется настраивать вручную. Второй момент -- я в статье подчеркнул, что конструктор диалогов не относится к MFC и IDE вообще, его функции выполняет редактор ресурсов

Цитата Повстанець @ 13.09.10, 18:12

А если взять в сыром виде WTL vs WinApi, то WTL способен экономить десятки человекочасов

Сэкономить на чем? Он не оборачивает окна уровнем выше MFC, он не предоставляет даже классов для рисования, и он не упрощает работу с COM. COM'ом занимается ATL, библиотека, являющаяся неотъемлемой частью MFC

Добавлено 13.09.10, 20:21

Цитата Повстанець @ 13.09.10, 18:12

Ну это так... не холивара ради, а просто к слову.

Конструктивная критика приветствуется, только в меру А то, сколько людей, столько и мнений

По Qt как, возражений более нет?

[Повстанець]

Цитата B.V. @ 13.09.10, 20:20

Начнем с того, что в студии не предусмотрено шаблонов проектов WTL. А именно на это будет смотреть любой начинающий пользователь

Если начинающий пользователь ставит на студию стороннюю GUI библиотеку, то он наверняка прочтёт инструкцию к установке и заинсталлит шаблоны проектов из пакета.

Цитата B.V. @ 13.09.10, 20:20

Сэкономить на чем?

Во первых на рутине. Очень много в винапи рутины. И очень много из неё берёт на себя WTL. Во вторых сам по себе WTL можно сказать в чём то гениален, как сферическая библиотека в вакууме, я имею в виду. До примитивного простая архитектура, но при этом она очень гибка и очень удобна. Расширяемость делается в два счёта. Реюзабельность расширений полная. Гибкость тех же расширений на высоте. Единственное, что омрачает использование WTL -- так это то, что она не абстрагирует тебя от корявости и тупости архитектуры самого WinApi.

Цитата B.V. @ 13.09.10, 20:20

COM'ом занимается ATL, библиотека, являющаяся неотъемлемой частью MFC

ATL к MFC вообще никакого отношения не имеет. Это полностью самостоятельная библиотека. Напротив, WTL написан на основе ATL. Во первых, в WTLе ATLная архитектура. Во вторых, все базовые классы WTL есть базовыми классами ATL, что делает эти библиотеки совместимыми. Ну и в третьих WTL собственно и делали легковесной надстройкой над ATL специально, чтобы при работе с СОМ, при необходимости использовать GUI не заморачиватся с WinApi и не подтягивать такую лошадь, как MFC.

[Qraizer]

Цитата Повстанець @ 13.09.10, 20:39

Единственное, что омрачает использование WTL -- так это то, что она не абстрагирует тебя от корявости и тупости архитектуры самого WinApi.

А мне Win32 нравится. На нём и пишу, родимом. Гибче не встречал.

[Повстанець]

Цитата Qraizer @ 13.09.10, 23:34

А мне Win32 нравится. На нём и пишу, родимом. Гибче не встречал.

Если нравится Win32, то должен понравится и WTL. Если, конечно, на нём уже не пишешь.

[B.V.]

Цитата Повстанець @ 13.09.10, 20:39

Если начинающий пользователь ставит на студию стороннюю GUI библиотеку, то он наверняка прочтёт инструкцию к установке и заинсталлит шаблоны проектов из пакета.

Только ведь WTL идет в комплекте со студией

Цитата Повстанець @ 13.09.10, 20:39

ATL к MFC вообще никакого отношения не имеет. Это полностью самостоятельная библиотека.

Да ладно?

Цитата Повстанець @ 13.09.10, 20:39

Во первых на рутине. Очень много в винапи рутины. И очень много из неё берёт на себя WTL.

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

Цитата Повстанець @ 13.09.10, 20:39

Напротив, WTL написан на основе ATL. Во первых, в WTLе ATLная архитектура. Во вторых, все базовые классы WTL есть базовыми классами ATL, что делает эти библиотеки совместимыми.

Об архитектуре знал, а вот о том, что классы WTL наследуются от базовых ATL, каюсь, не знал. Сказывается малый опыт работы с библиотекой. Ок, этот момент я поправлю, спасибо за подсказку

[Повстанець]

Цитата B.V. @ 14.09.10, 12:20

Только ведь WTL идет в комплекте со студией

Нет, не идёт. Даже не является официальным продуктом майкрософт.

Цитата B.V. @ 14.09.10, 12:20

Да ладно?

Там только список совместимых классов.

Цитата B.V. @ 14.09.10, 12:20

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

Создание пользовательского окна, с регистрацией класса:

class CCustomWindow : public CWindowImpl<CCustomWindow, CWindow>
{
private:
    DECLARE_WND_CLASS_EX("CCustomWindow", CS_HREDRAW | CS_VREDRAW, COLOR_WINDOW)
 
private:
    BEGIN_MSG_MAP(CCustomWindow)
    END_MSG_MAP()
};

Сабклассинг:

class CCustomButton : public CWindowImpl<CCustomButton, CButton>
{
private:
    BEGIN_MSG_MAP(CCustomButton)
    END_MSG_MAP()
};

Овнердрав:

class CCustomWindow : public CWindowImpl<CCustomWindow, CWindow>,
                                   public COwnerDraw<CCustomWindow>
{
private:
    DECLARE_WND_CLASS_EX("CCustomWindow", CS_HREDRAW | CS_VREDRAW, COLOR_WINDOW)
 
private:
    BEGIN_MSG_MAP(CCustomButton)
        CHAIN_MSG_MAP(COwnerDraw<CCustomWindow>)
    END_MSG_MAP()
 
private:
    void DrawItem(LPDRAWITEMSTRUCT pDIS)
    {
    };
};

Но я так овнердрав не юзал никогда, ибо этот способ диктуется кривизной апи. Я обычно сабклассил кнопку, подключал к ней COwnerDraw, реализовывал его прямо в обработчике сообщений кнопки. Потом вставлял в карту сообщений родительского окна кнопки REFLECT_NOTIFICATIONS(), так чтобы овнердрав-сообщение возвращалось обратно к кнопке и получал абсолютно самодостаточную пользовательскую кнопку. Для переноса и повторного использования которой не приходилось бы методом копипаста выдирать код из портянки-функции обработки сообщений родительского окна, как в винапи.

[B.V.]

Цитата Повстанець @ 14.09.10, 13:13

Нет, не идёт. Даже не является официальным продуктом майкрософт.

Надо же. Выходит, я WTL совсем не знаю
До сих пор думал, что она ставится при полной установке студии. Сейчас сходил на сайт проекта, и почитал о положении вещей
Однако Что ж, буду знать.

Цитата Повстанець @ 14.09.10, 13:13

Там только список совместимых классов.

Не совместимых, а совместных

Цитата Повстанець @ 14.09.10, 13:13

Создание пользовательского окна, с регистрацией класса:

Положим, создание окна сводится не к 10 строчкам, как в случае с WinAPI, а к двум-трем. Но, во-первых, окна в проекте не так уж и часто приходится создавать. Во-вторых, все это упрощение нивелируется необходимостью прописывать рутинные конструкции для ООП. Два остальных примера не убедили. Сабклассинг в WinAPI выполняется в две строчки, а OD, в зависимости от э.у., представляет собой или простую обработку двух сообщений, или обработку WM_PAINT в сабклассинге

[Повстанець]

Цитата B.V. @ 14.09.10, 13:36

Не совместимых, а совместных

Не. Совместимых. Хотя, как с MFC я не знаю, не особо то владею этой библиотекой. Может она и юзает ATL где-то в своих недрах. Но вот то, что у ATL точно никаких зависимостей от MFC нет, это 100%.

Цитата B.V. @ 14.09.10, 13:36

Положим, создание окна сводится не к 10 строчкам, как в случае с WinAPI, а к двум-трем. Но, во-первых, окна в проекте не так уж и часто приходится создавать. Во-вторых, все это упрощение нивелируется необходимостью прописывать рутинные конструкции для ООП. Два остальных примера не убедили. Сабклассинг в WinAPI выполняется в две строчки, а OD, в зависимости от э.у., представляет собой или простую обработку двух сообщений, или обработку WM_PAINT в сабклассинге

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

template <typename wnd_class>
class color_control
{
private:
    BEGIN_MSG_MAP(color_control<wnd_class>)
        MESSAGE_RANGE_HANDLER(OCM_CTLCOLORMSGBOX, OCM_CTLCOLORSTATIC, _on_ctlcolor_xxx)
    END_MSG_MAP()
 
private:
    LRESULT _on_ctlcolor_xxx(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL &bHandled)
    {
        CDCHandle dc((HDC)wParam);
        dc.SetBkMode(TRANSPARENT);
        dc.SetTextColor(_text_color);
 
        return (LRESULT)(HBRUSH)_bckgnd_brush;
    };
 
private:
    WTL::CBrush _bckgnd_brush;
    COLORREF _text_color;
 
public:
    color_control()
    {
        _bckgnd_brush.CreateSolidBrush(RGB(255, 255, 255));
        _text_color = RGB(0, 0, 0);
    }
 
    COLORREF set_bckground_color(COLORREF color)
    {
 
        LOGBRUSH lbrush;
        _bckgnd_brush.GetLogBrush(&lbrush);
 
        _bckgnd_brush.DeleteObject();
        _bckgnd_brush.CreateSolidBrush(color);
 
        static_cast<wnd_class*>(this)->RedrawWindow();
 
        return lbrush.lbColor;
    }
 
    COLORREF set_text_color(COLORREF color)
    {
        COLORREF old = _text_color;
 
        _text_color = color;
 
        static_cast<wnd_class*>(this)->RedrawWindow();
 
        return old;
    }
};
 
template<typename base_control_class>
class color_common_control : public CWindowImpl<color_common_control<base_control_class>, base_control_class>,
                             public color_control<color_common_control<base_control_class>>
{
private:
    BEGIN_MSG_MAP(color_common_control<base_control_class>)
        CHAIN_MSG_MAP(color_control<color_common_control<base_control_class>>)
    END_MSG_MAP()
};
 
typedef color_common_control<CStatic> colored_static;
typedef color_common_control<CEdit> colored_edit;
typedef color_common_control<CButton> colored_button;
//ну и так далее

А на винапи как это сделать?

Сообщение отредактировано: Повстанець - 15.09.10, 11:18

[B.V.]

Цитата Повстанець @ 15.09.10, 11:14

Не. Совместимых. Хотя, как с MFC я не знаю, не особо то владею этой библиотекой. Может она и юзает ATL где-то в своих недрах.

Ты хоть не поленись почитать MSDN по моей ссылке
Классы ATL используются в MFC

Цитата Повстанець @ 15.09.10, 11:14

Но вот то, что у ATL точно никаких зависимостей от MFC нет, это 100%.

Кто-то где-то с этим спорил?

Цитата Повстанець @ 15.09.10, 11:14

В корне не устраивает нас (меня, во всяком случае) такое положение вещей

А меня устраивает. Еще раз: все преимущества по удобству в WTL нивелируются необходимостью прописывания ООП-конструкций. Ты посмотри, сколько ООП-каши в твоем коде. Если подсчитать буковки на WinAPI и твоего кода, боюсь, на WinAPI может выйти даже меньше.
У WTL в этом отношении только одно преимущество: более элегантный код за счет применения ООП. И это преимущество я упомянул
Быть может, в масштабах очень большого проекта все эти мелочи действительно помогут избежать написания лишних нескольких десятков строк кода, но если брать каждую отдельно взятую задачу (из приведенных, по крайней мере), то WTL или не перекрывает, или крайне незначительно перекрывает WinAPI-код в плане упрощения

Цитата Повстанець @ 15.09.10, 11:14

А на винапи как это сделать?

Ничто не мешает выписать в небольшой namespace набор перегруженных функций OnCtlColor и использовать их по всему проекту, если говорить по практической части. Выйдет короче и удобнее

[Повстанець]

Цитата B.V. @ 15.09.10, 11:45

Ничто не мешает выписать в небольшой namespace набор перегруженных функций OnCtlColor и использовать их по всему проекту, если говорить по практической части. Выйдет короче и удобнее

Никто не мешает. И может даже это будет короче. Но никак не удобнее. Это программирование свалкой. Тебе всегда необходимо будет помнить как работает эта система. В то время, как у меня будет просто контрол colored_static, у которого есть два расширяющих обычный статик метода. Как он работает я могу забыть сразу же, как только написал. Тем более дальнейшее расширение системы только усугубит свалку, в то время, как в WTL ничего особо и придумывать не придётся:

class next_generation_static : public CWindowImpl<next_generation_static, colored_static>,
                                    public some_other_ext_1<next_generation_static>,
                                    public some_other_ext_2<next_generation_static>,
                                    public some_other_ext_3<next_generation_static>
{
private:
    BEGIN_MSG_MAP(next_generation_static)
        CHAIN_MSG_MAP(some_other_ext_1<next_generation_static>)
        CHAIN_MSG_MAP(some_other_ext_2<next_generation_static>)
        CHAIN_MSG_MAP(some_other_ext_3<next_generation_static>)
    END_MSG_MAP()
};

Цитата B.V. @ 15.09.10, 11:45

А меня устраивает. Еще раз: все преимущества по удобству в WTL нивелируются необходимостью прописывания ООП-конструкций. Ты посмотри, сколько ООП-каши в твоем коде. Если подсчитать буковки на WinAPI и твоего кода, боюсь, на WinAPI может выйти даже меньше.

Ну... количество буковок не показатель простоты системы. Но хорошие ООП-конструкции (хорошая архитектура) может и приводят к бОльшему количеству работы и Большей писанины в начале проекта, но уже ближе к середине и даже раньше идут чистые бонусы, как в удобстве работы с ней, так и в количестве буковок.

Цитата B.V. @ 15.09.10, 11:45

Быть может, в масштабах очень большого проекта все эти мелочи действительно помогут избежать написания лишних нескольких десятков строк кода, но если брать каждую отдельно взятую задачу (из приведенных, по крайней мере), то WTL или не перекрывает, или крайне незначительно перекрывает WinAPI-код в плане упрощения

Крайне несогласен. Уверен, даже на маленьких проектах использование ООП (в частности WTL) сделает код много проще и лаконичнее.

Добавлено 15.09.10, 13:01
Кстати, ведь последнее утверждение всегда можно и проверить. Как на счёт реализации тех же самых цветных контролов на винапи ну и немного погонять их в действии. Скажем один эдит, два радио баттона, немного текста и кнопка. В эдите набираешь цвет, в радиобатонами выбираешь цвет фона, или текста менять, а баттоном собственно меняешь эти показатели у всех контролов. Простенько и со вкусом.

Сообщение отредактировано: Повстанець - 15.09.10, 13:01

[B.V.]

Мне есть чем заняться. Повстанець
Но я бы с удовольствием почитал твой спор с каким-нибудь "функциональщиком" на тему полезности WTL, в Холиварах

[MinLexx]

wxWidgets
Кроссплатформенная библиотека, в основном, для GUI, хотя и консольные приложения делать есть возможность. Позволяет создавать приложения для Windows, OS X, Linux/Unix, также для Win Mobile, iPhone SDK. Очень похожа на WinAPI (названия функций, констант, легко привыкаешь после WinAPI). Также есть классы для работы с сетью, файловой системой, итд. Билдится в 2х вариантах - с поддержкой Unicode и без (это кроме вариантов с Debug/Release). Легко строится из сырцов. Имеются сторонние дизайнеры UI (мне нравится wxFormBuilder, например). Как утверждают разработчики, wxWidgets приложения выглядят как родные на каждой платформе, потому что используют нативные элементы управления, а не занимаются эмуляцией GUI (отсюда, в частности, следует минус, что не все элементы ведут себя одинаково на разных платформах).

Плюсы

• достаточно маленькая (таки меньше Qt)
• соединения событий и обработчиков напоминает систему из MFC со статической таблицей (BEGIN_MESSAGE_MAP / DECLARE_MESSAGE_MAP), равно как и есть возможность динамических соединений
• есть возможность создавать собственные элементы управления
• есть возможность локализации
• Свободное распространение с исходными кодами

Минусы

• все-таки недостаточно кроссплатформенная - некоторые функции не работают под Lin/Mac, или наоборот, под Win, или работают по-разному - это надо будет учесть
• документация не всегда внятная - иногда приходится лезть курить примеры или даже ковырять сырцы wxWidgets =)
• LGPL таки не совсем свободная лицензия
• статически слинкованные с либой бинарники, все-таки, маленькими не назовешь

чего бы ещё такое вспомнить, с ходу...

Сообщение отредактировано: MinLexx - 04.10.10, 07:50

[B.V.]

Цитата MinLexx @ 03.10.10, 05:17

достаточно быстрая (нет такого механизма сигналов/слотов, metacall'ов, как в Qt)

Ну, это довольно расплывчатое преимущество
Можешь его как-нибудь раскрыть? Например, "библиотека проявляет себя быстрее таких-то и таких-то в таких-то задачах (за счет ..)"