Здравствуйте, AndrewJD, Вы писали:
А>>>>>Если программа состоит из 4-6 диалогов какой смысл тащить wxWindows.
T>>Для обсуждаемых объёмов и задачь, эта "низкоуровневость" ни как не скажеться на скорости и сложности реализации. Разве что на суммарном объёме получившегося продукта.
AJD>Скажеться на скорости реализации. Хотя бы за счет биндинга котролов к переменным
Ну и представь отношение этого выигрыша хотя бы к времени рисования тех же самых диалогов в редакторе ресурсов — несущественно.
А уж к общему времени — так и говорить не о чем.

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

AJD>>Скажеться на скорости реализации. Хотя бы за счет биндинга котролов к переменным
T>Ну и представь отношение этого выигрыша хотя бы к времени рисования тех же самых диалогов в редакторе ресурсов — несущественно.
T>А уж к общему времени — так и говорить не о чем.

Если мы говорим про 4-6 диалогов то есть о чем.

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

S_N> У MFC — разделили на типы — для диалоговых окон почему-то нельзя создать меню, записывать в файлы, мало компонентов (даже таймера нет). Зато можно кидать кнопки.
Можно
S_N> А если создать приложение типа Document (Single или Multiple) — есть меню, и т.д., но нельзя кидать кнопки!
Нужно делать базовым классом CFormView, а не тот, который стоит по дефолту

Здравствуйте, AndrewJD, Вы писали:
AJD>>>Скажеться на скорости реализации. Хотя бы за счет биндинга котролов к переменным
T>>Ну и представь отношение этого выигрыша хотя бы к времени рисования тех же самых диалогов в редакторе ресурсов — несущественно.
T>>А уж к общему времени — так и говорить не о чем.
AJD>Если мы говорим про 4-6 диалогов то есть о чем.
Можешь дать примерную раскладку по времени с биндингом и без, чтобы было наглядно видно?
Общее время на приложение состоит из:

1. время на создание классов логики.
   
2. время на дизайн диалога.
   
3. время на логику работы диалога.
   
4. время на логику приложения.

Пункт 1 повторён столько раз, сколько классов.
Пункты 2 и 3 повторены столько, сколько диалогов.

Биндинг переменных, как мне кажеться, влияет только на п3.
В общем виде он состаит из подпунктов:

1. инициализация
   
2. логика редактирования (отключение/включение, скрытие/показ, и. т.д. для групп контролов)
   
3. валидация
   
4. сохранение

Если я правильно понимаю, биндинг здесь может заменить пп1,4 на пункт "написание биндинга"

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

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

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

W>5. Проблема MFC — его базовая комплектация, поставляемая с вижуалом, по внешнему виду отстала лет так на 5. Меня это дико бесит. Например, вижуал 2005 сам по себе дико гламурный и многоцветный, но почему-то создать ту же красоту на MFC — геморрой дикий. Читал, что исправят в скором будущем.

Visual C++ 2008 Feature Pack Beta

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

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

S>>под MFC написано кучу классов под разные случаи, другое дело что используются они не перетаскиванием иконок на формочку (хотя есть и такие, например ActiveX компоненты), а добавлением соотв. объектов в члены классов итд, на мой взгляд так даже правильнее, потому что думать надо больше головой и писать руками, да и больше понимать как все работает...


S_N> По-моему, удобство разработки — очень важная вещь. Иначе, зачем же делали, чтобы все было так удобно в проектах типа CLR, так же как в C++Builder-e ? А в MFC все неудобство оставили, как есть. Недаром кто-то (уже не помню) писал, что MFC "отстала лет на 5".

S_N> Головой надо думать, работая со своим функционалом, а не с тем, что и как подключается и работает. Если уж так хочется понять, "как все работает" то можно предложить и на ассемблере оболочку писать. Поэтому я, как и большинство разработчиков думаю, что могли бы и создать стандартные вещи способом перетаскивания компонент. На дворе 2007 год...

S_N> Ну да, ладно, можно без перетаскивания, меня убивает другое. Как можно было не предусмотреть совмещения таких стандартных вещей, как меню и контролы! Вот это самое поразительное. УДОБНОГО совмещения. А в книге написано прямым текстом — "В диалоговых приложениях НЕЛЬЗЯ создавать меню, записывать в файл и т.п."

Да ведь дело-то не столько в MFC. Есть стандарты разработки оконного интерфейса для Windows (за подробностями милости прошу в MSDN). И именно эти стандарты, по-меньшей мере не одобряют использование меню в диалогах. Кроме того эти стандарты определяют как должны выглядеть главное окно приложения, меню, окна сообщений.... Другое дело, что сама MS зачастую не следует этим стандартам, но — "жираф большой ему видней".

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

T>Общее время на приложение состоит из:
T>

T>
1. время на создание классов логики.
   T>
2. время на дизайн диалога.
   T>
3. время на логику работы диалога.
   T>
4. время на логику приложения.
   T>

T>Пункт 1 повторён столько раз, сколько классов.
T>Пункты 2 и 3 повторены столько, сколько диалогов.

Правильно. Только для WTL это все тоже необходимо сделать.

T>Биндинг переменных, как мне кажеться, влияет только на п3.
Ага

T>В общем виде он состаит из подпунктов:
T>

T>
1. инициализация
   T>
2. логика редактирования (отключение/включение, скрытие/показ, и. т.д. для групп контролов)
   T>
3. валидация
   T>
4. сохранение
   T>

T>Если я правильно понимаю, биндинг здесь может заменить пп1,4 на пункт "написание биндинга"

Забыл про третий пункт — валидация. Она тоже есть в МFC. Т.е. на WTL необходимо руками реализовать пункты 1,3,4.

T>P.S. Я не сколько не умоляю достоинства биндинга, просто мне кажеться, что он начинает играть заметную роль хотя бы на нескольких десятках диалогов...

Я всего лишь хочу сказать, что посколку WTL еще более низкоуровневая библиотека, чем MFC — затраты будут больше.

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

AJD>Забыл про третий пункт — валидация. Она тоже есть в МFC. Т.е. на WTL необходимо руками реализовать пункты 1,3,4.
В WTL тоже есть — на CodeProject'е точно видел.

T>>P.S. Я не сколько не умоляю достоинства биндинга, просто мне кажеться, что он начинает играть заметную роль хотя бы на нескольких десятках диалогов...
AJD>Я всего лишь хочу сказать, что посколку WTL еще более низкоуровневая библиотека, чем MFC — затраты будут больше.
Необязательно. WTL более гибкая, чем MFC.

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

AJD>Забыл про третий пункт — валидация. Она тоже есть в МFC.

в WTL — такая же как в MFC

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

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

AJD>>Забыл про третий пункт — валидация. Она тоже есть в МFC. Т.е. на WTL необходимо руками реализовать пункты 1,3,4.
C>В WTL тоже есть — на CodeProject'е точно видел.
Возможно в последних версиях добавили

AJD>>Я всего лишь хочу сказать, что посколку WTL еще более низкоуровневая библиотека, чем MFC — затраты будут больше.
C>Необязательно. WTL более гибкая, чем MFC.
Более низкоуровневая — более гибкая.

AJD>Забыл про третий пункт — валидация. Она тоже есть в МFC. Т.е. на WTL необходимо руками реализовать пункты 1,3,4.

Валидация в MFC реализована настолько погано, что ее все равно приходится переделывать.

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

S>Валидация в MFC реализована настолько погано, что ее все равно приходится переделывать.

Для простых случаев работает вполне

> S>Валидация в MFC реализована настолько погано, что ее все равно приходится переделывать.
>
> Для простых случаев работает вполне

Простые случаи — это когда в диалоге ровно один валидируемый контрол? Потому что если их хотя бы два, фиг юзер догадается, чего именно у него там за дипазон вылезло.

Здравствуйте, AndrewJD, Вы писали:
T>>Если я правильно понимаю, биндинг здесь может заменить пп1,4 на пункт "написание биндинга"
AJD>Забыл про третий пункт — валидация. Она тоже есть в МFC. Т.е. на WTL необходимо руками реализовать пункты 1,3,4.
Я, собственно больше про "логическую" валидацию — когда значение одного контрола зависит от значения в другом — всяческие диапазоны, или например когда от текущего выбора радиокнопки зависит может поле ввода быть пустым или нет...
Или это тоже в биндинге декларативно можно написать?

AJD>Я всего лишь хочу сказать, что посколку WTL еще более низкоуровневая библиотека, чем MFC — затраты будут больше.
Да я как бы и не спорю, просто приведи свою раскладку по времени выполнения каждой задачи из списка, и посмотри, на каком количестве диалогов наличие биндинга даст выигрыш хотя бы в 5%