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

W>Пишу программу (интерфейсные дела составляют2/3 от объема программы). Активно использую MFC. Вспомнил, что периодически слышу высказывания "MFC го**но", "на MFC ни кто не пишет". Задумался чем его можно заменить в VC. Ответ не нашел.

W>Так почему оно го**но, и чем его можно заменить?

А зачем тебе его заменять? Если ты владеешь в совершенстве MFC, если пишешь только под Windows, то что тебе ещё нужно от оболочек? У MFC и коды открыты, и поддержка производителя ОС, и она уже доведена до совершенства. И стоит вместе с компилятором $100. Что может быть лучше? Не знаю...

А заменить можно: WinAPI, Qt, WTL, можно свою обёртку написать.

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


Ovl>>к тому же MS вроде как уже не будет поддерживать mfc....

L_L>Так она вроде как и wtl не поддерживает больше
Дык она вообще и не поддерживала

Здравствуйте, Слава Шевцов, Вы писали:

СШ>Здравствуйте, Wind, Вы писали:

W>>Пишу программу (интерфейсные дела составляют2/3 от объема программы). Активно использую MFC. Вспомнил, что периодически слышу высказывания "MFC го**но", "на MFC ни кто не пишет". Задумался чем его можно заменить в VC. Ответ не нашел.

W>>Так почему оно го**но, и чем его можно заменить?

СШ>А зачем тебе его заменять? Если ты владеешь в совершенстве MFC, если пишешь только под Windows, то что тебе ещё нужно от оболочек?
согласен

> и она уже доведена до совершенства.
смелое утверждение

СШ>А заменить можно: WinAPI, Qt, WTL, можно свою обёртку написать.
согласен

от себя:
ничего не делай просто так
если многие говорят что MFC говно, то что же мне идти теперь и переделывать свои проекты?
кто за это будет платить?

MFC далека от идеала, а идеала как известно вообще не существует, везде есть какой-то компромисс между плюсами и минусами.
Если тебе надо разрабатывать GUI для win, то я бы тебе посоветовал смотреть в сторону WTL.
WTL классная библиотека. На RSDN есть хорошие статьи по WTL для начинающих.
Или вообще уходить в .NET и WinForms.

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

W>Пишу программу (интерфейсные дела составляют2/3 от объема программы). Активно использую MFC. Вспомнил, что периодически слышу высказывания "MFC го**но", "на MFC ни кто не пишет". Задумался чем его можно заменить в VC. Ответ не нашел.

W>Так почему оно го**но, и чем его можно заменить?

Реализация концепции Документ-Вид в MFC не является строго ОО ориентированной. Так, например, Вид для отображения информации документа, обращается к методам Документа, хотя, для уменьшения зависимотей, он (Вид) не должен ничего знать о Документе. То есть:

вместо

CView::Display()
{
   Display(m_pDocument->GetData());
}

лучше уж

СView::Display()
{
   m_pDocument->DisplayView(this);
}

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

Ovl>>Я уже встречал в требованиях некоторых продуктов, что 98-ая не поддерживается. Не вижу причин, чтобы не отказаться от использования MFC.
S>Это называется ленивый программисты имхо. Незнаю, куча компиков фурычат на win98 (я ж не говарю, что win95), и софт (если он рассчитан на массы) без поддержки win98 — фиговый нуль.

Имхо — ты не прав. Если пишется прога для конкретной работы с БД например, причём исключительно на локальном компе , то мне интересно посмотреть на камикадзе, который с этим добром под 98 работать будет Одно посягательство на исп. память — и всё, прога упала, прихватив с собой вместе всю систему. Лол, одним словом.

Пишу программу (интерфейсные дела составляют2/3 от объема программы). Активно использую MFC. Вспомнил, что периодически слышу высказывания "MFC го**но", "на MFC ни кто не пишет". Задумался чем его можно заменить в VC. Ответ не нашел.

Так почему оно го**но, и чем его можно заменить?

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

W>Пишу программу (интерфейсные дела составляют2/3 от объема программы). Активно использую MFC. Вспомнил, что периодически слышу высказывания "MFC го**но", "на MFC ни кто не пишет". Задумался чем его можно заменить в VC. Ответ не нашел.

W>Так почему оно го**но, и чем его можно заменить?
WTL — но я не пробовал
привык к MFC

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

W>Пишу программу (интерфейсные дела составляют2/3 от объема программы). Активно использую MFC. Вспомнил, что периодически слышу высказывания "MFC го**но", "на MFC ни кто не пишет". Задумался чем его можно заменить в VC. Ответ не нашел.

W>Так почему оно го**но, и чем его можно заменить?

Qt,
wxWindows сам не пробовал.
Обе псевдо-кроссплатформенные

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

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

W>>Пишу программу (интерфейсные дела составляют2/3 от объема программы). Активно использую MFC. Вспомнил, что периодически слышу высказывания "MFC го**но", "на MFC ни кто не пишет". Задумался чем его можно заменить в VC. Ответ не нашел.

W>>Так почему оно го**но, и чем его можно заменить?

M>Qt,
M>wxWindows сам не пробовал.
M>Обе псевдо-кроссплатформенные
А почему псевдо?
Qt насколько я знаю, нормально в Линух себя чувствует...

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

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

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

W>>>Пишу программу (интерфейсные дела составляют2/3 от объема программы). Активно использую MFC. Вспомнил, что периодически слышу высказывания "MFC го**но", "на MFC ни кто не пишет". Задумался чем его можно заменить в VC. Ответ не нашел.

W>>>Так почему оно го**но, и чем его можно заменить?

M>>Qt,
M>>wxWindows сам не пробовал.
M>>Обе псевдо-кроссплатформенные
CS>А почему псевдо?
CS>Qt насколько я знаю, нормально в Линух себя чувствует...

Потому что под каждую из платформ надо собирать отдельно.

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

W>Пишу программу (интерфейсные дела составляют2/3 от объема программы). Активно использую MFC. Вспомнил, что периодически слышу высказывания "MFC го**но", "на MFC ни кто не пишет". Задумался чем его можно заменить в VC. Ответ не нашел.

W>Так почему оно го**но, и чем его можно заменить?

я пробовал wtl
нормально. на довольно низком уровне работает, все прозрачно, не так закамуфлировано как mfc.
в принципе похоже на mfc, но wtl легче, там проще работать с COM.

к тому же MS вроде как уже не будет поддерживать mfc....

Ovl>к тому же MS вроде как уже не будет поддерживать mfc....

Так она вроде как и wtl не поддерживает больше

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

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

W>>Пишу программу (интерфейсные дела составляют2/3 от объема программы). Активно использую MFC. Вспомнил, что периодически слышу высказывания "MFC го**но", "на MFC ни кто не пишет". Задумался чем его можно заменить в VC. Ответ не нашел.

W>>Так почему оно го**но, и чем его можно заменить?

Кстати, а кто-нибудь ответит человеку на первую часть вопроса? Я уже весь заждался....

Ovl>я пробовал wtl
Ovl>нормально. на довольно низком уровне работает, все прозрачно, не так закамуфлировано как mfc.
Ovl>в принципе похоже на mfc, но wtl легче, там проще работать с COM.

Ovl>к тому же MS вроде как уже не будет поддерживать mfc....

Да что Вы говорите. Вот так возьмёт и кинет своё детище, на котором сидит куча компаний? Это же вроде не IBM

Здравствуйте, Слава Шевцов, Вы писали:

СШ>Здравствуйте, Ovl, Вы писали:

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

W>>>Пишу программу (интерфейсные дела составляют2/3 от объема программы). Активно использую MFC. Вспомнил, что периодически слышу высказывания "MFC го**но", "на MFC ни кто не пишет". Задумался чем его можно заменить в VC. Ответ не нашел.

W>>>Так почему оно го**но, и чем его можно заменить?

СШ>Кстати, а кто-нибудь ответит человеку на первую часть вопроса? Я уже весь заждался....

Я не сказал бы, что MFC — го**но. 95% моих программ написано именно на MFC. Минусы есть, идеальной библиотеки не существует, но до такой характеристики этих минусов явно недостаточно. Основной минус, как мне кажется — сложность выхода за рамки стандартного подхода, предлагаемого MFC. Пока делаешь то, что в ней предусмотрено, всё отлично. Но как только пытаешься сделать что-то своё...

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


К>Основной минус, как мне кажется — сложность выхода за рамки стандартного подхода, предлагаемого MFC. Пока делаешь то, что в ней предусмотрено, всё отлично. Но как только пытаешься сделать что-то своё...

К примеру ?

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

К>... Но как только пытаешься сделать что-то своё...
????

Здравствуйте, Слава Шевцов, Вы писали:

СШ>Да что Вы говорите. Вот так возьмёт и кинет своё детище, на котором сидит куча компаний? Это же вроде не IBM
А что это за шпилька? (просто интерестно )

Здравствуйте, Слава Шевцов, Вы писали:

СШ>Да что Вы говорите. Вот так возьмёт и кинет своё детище, на котором сидит куча компаний? Это же вроде не IBM

а почему бы и нет. MFC делался очень давно, и все попытки сохранить поддержку вылились в массивный гроб на колесах.
Я уже встречал в требованиях некоторых продуктов, что 98-ая не поддерживается. Не вижу причин, чтобы не отказаться от использования MFC.

Конечно, MS не в силах запретить писать на MFC
Я имел ввиду, что если кто-то найдет в нем новые баги, то исправлять будет сам, писать об этом в МС бесполезно.

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


Ovl>>к тому же MS вроде как уже не будет поддерживать mfc....

L_L>Так она вроде как и wtl не поддерживает больше

по крайней мере последний релиз wtl был этим летом.. а когда он был у mfc?

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

Ovl>по крайней мере последний релиз wtl был этим летом.. а когда он был у mfc?
Я имел ввиду официально

Ovl>по крайней мере последний релиз wtl был этим летом.. а когда он был у mfc?

Дак я ерунду написал.

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

AJD>Здравствуйте, Константин, Вы писали:


К>>Основной минус, как мне кажется — сложность выхода за рамки стандартного подхода, предлагаемого MFC. Пока делаешь то, что в ней предусмотрено, всё отлично. Но как только пытаешься сделать что-то своё...

AJD>К примеру ?

Сходу смог вспомнить такую задачу. Требуется сделать SDI с поддержкой нескольких типов файлов, но одинакового шаблона. Т.е., например, сделать текстовый редактор, с которым автоматически ассоциируются TXT-, LOG- и, скажем, INI-файлы, у каждого своя иконка, своё название типа в реестре, но открываться и обрабатываться в редакторе они должны совершенно одинаково. Т.е. делать несколько DocTemplate'ов нет смысла. Как я это сделал — можно почитать в этой статейке. Может, это и изврат, но я другого способа просто не нашёл.

Пока писал, вспомнил другой пример — всем известная проблема дизейбла пункта меню или кнопки тулбара. Ну почему бы не сделать просто EnableMenuItem(FALSE)? Так нет, берёт, самостоятельно внутри устанавливает обратно стиль Enabled. Да, проблема решается. Да, довольно просто решается. Но как её решить тому, кто не знает готового решения?..

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

Ovl>Я уже встречал в требованиях некоторых продуктов, что 98-ая не поддерживается. Не вижу причин, чтобы не отказаться от использования MFC.
Это называется ленивый программисты имхо. Незнаю, куча компиков фурычат на win98 (я ж не говарю, что win95), и софт (если он рассчитан на массы) без поддержки win98 — фиговый нуль.

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

Ovl>по крайней мере последний релиз wtl был этим летом.. а когда он был у mfc?

В марте 2003. Вместе с VS 7.1

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


К>Сходу смог вспомнить такую задачу. Требуется сделать SDI с поддержкой нескольких типов файлов, но одинакового шаблона. Т.е., например, сделать текстовый редактор, с которым автоматически ассоциируются TXT-, LOG- и, скажем, INI-файлы, у каждого своя иконка, своё название типа в реестре, но открываться и обрабатываться в редакторе они должны совершенно одинаково. Т.е. делать несколько DocTemplate'ов нет смысла. Как я это сделал — можно почитать в этой статейке. Может, это и изврат, но я другого способа просто не нашёл.

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

К>Пока писал, вспомнил другой пример — всем известная проблема дизейбла пункта меню или кнопки тулбара. Ну почему бы не сделать просто EnableMenuItem(FALSE)? Так нет, берёт, самостоятельно внутри устанавливает обратно стиль Enabled.

А можно подробней про эту проблему? ( всем известная, а я не знаю ). Если ты имеешь ввиду, что меню дизеблится если нет обработчика — то это везде документированная фича (никак не проблема)

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

СШ>>Да что Вы говорите. Вот так возьмёт и кинет своё детище, на котором сидит куча компаний? Это же вроде не IBM
S>А что это за шпилька? (просто интерестно )

Ну IBM мастера на такие вещи. Неоднократно создавали/покупали крупные программные продукты и вдруг забивали на них. Вот типичный пример. Создали OS/2 и практически плюнули на неё (помомему, она работает только в кассовых аппаратах).

Здравствуйте, Слава Шевцов, Вы писали:

СШ>Ну IBM мастера на такие вещи. Неоднократно создавали/покупали крупные программные продукты и вдруг забивали на них. Вот типичный пример. Создали OS/2 и практически плюнули на неё (помомему, она работает только в кассовых аппаратах).

Ага, часто наблюдал (я про os/2 в кассовых)

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

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

Ovl>>по крайней мере последний релиз wtl был этим летом.. а когда он был у mfc?

AJD>В марте 2003. Вместе с VS 7.1

афайк, вместе с 7.1 дали wtl7.0, wtl7.1 появился позже

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

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

S>Это называется ленивый программисты имхо.
всякое бывает. иногда просто дрова под 98 не пишут, потому что тяжело очень. а проги не пишут, потому что дров нет.

S> Незнаю, куча компиков фурычат на win98 (я ж не говарю, что win95), и софт (если он рассчитан на массы) без поддержки win98 — фиговый нуль.

это не так. если придумаю хороший аргумент — отвечу почему

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

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

AJD>>Здравствуйте, Константин, Вы писали:


К>>>Основной минус, как мне кажется — сложность выхода за рамки стандартного подхода, предлагаемого MFC. Пока делаешь то, что в ней предусмотрено, всё отлично. Но как только пытаешься сделать что-то своё...

AJD>>К примеру ?

К>Сходу смог вспомнить такую задачу. Требуется сделать SDI с поддержкой нескольких типов файлов, но одинакового шаблона. Т.е., например, сделать текстовый редактор, с которым автоматически ассоциируются TXT-, LOG- и, скажем, INI-файлы, у каждого своя иконка, своё название типа в реестре, но открываться и обрабатываться в редакторе они должны совершенно одинаково. Т.е. делать несколько DocTemplate'ов нет смысла. Как я это сделал — можно почитать в этой статейке. Может, это и изврат, но я другого способа просто не нашёл.

К>Пока писал, вспомнил другой пример — всем известная проблема дизейбла пункта меню или кнопки тулбара. Ну почему бы не сделать просто EnableMenuItem(FALSE)? Так нет, берёт, самостоятельно внутри устанавливает обратно стиль Enabled. Да, проблема решается. Да, довольно просто решается. Но как её решить тому, кто не знает готового решения?..

Что же здесь сложного? выруби обработку WM_UPDATE_COMMAND_UI, и будет тебе счастье. Вот только я целиком согласен с МС что с этим сообщением гораздо удобнее, и код понятнее. Единственная недоработка МС в этом плане, это что диалоги автоматом это не тянут, но пришивается в течении 3 минут.

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


Ovl>>>по крайней мере последний релиз wtl был этим летом.. а когда он был у mfc?

AJD>>В марте 2003. Вместе с VS 7.1

Ovl>афайк, вместе с 7.1 дали wtl7.0, wtl7.1 появился позже

Я имеюю ввиду, что в марте 2003 вышло последнее обновление к MFC. Т.е. не так уж и давно

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

AJD>Я имеюю ввиду, что в марте 2003 вышло последнее обновление к MFC. Т.е. не так уж и давно

буду знать, а раньше — не знал

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

Ovl>я пробовал wtl

Ovl>к тому же MS вроде как уже не будет поддерживать mfc....

MS и WTL не поддерживает (и не поддерживала). А теперь это OpenSource проект.

Что самое интересное, что MS давно заикается о том, что поддержка MFC будет прекращена, но в VS.NET MFC стало теснее интегрирована с ATL (и наоборот).

W>Так почему оно го**но, и чем его можно заменить?

Смотря для чего используется MFC. Если как каркас приложения, то вроде нечем. Таких монстров, "всё-в-одном", больше нет. WTL лишь отчасти может заменить MFC.

Кстати есть такой замечательный сайт: http://codeguru.com/ — не знаю как сейчас, но раньше там была туча проектов на MFC — насчёт того, что MFC — Г.

А считается она таковым потому, что по дурацки построена — она является по большей части всего лишь обёрткой вокруг WinAPI. Причём дико нарушает принципы инкапсуляции C++.

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

>Реализация концепции Документ-Вид в MFC не является строго ОО ориентированной. Так, например, Вид для >отображения информации документа, обращается к методам Документа, хотя, для уменьшения зависимотей, >он (Вид) не должен ничего знать о Документе.

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

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


_>Скорее, наоборот. Для одного документа может быть множество представлений (графическое, текстовое, аккустическое). Поэтому проще будет всех их снабдить информацией о документе, чем заставлять единственный документ помнить о всех его представлениях.

так документу их помнить и не надо, ведь представление передается как параметр

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


FAD>Реализация концепции Документ-Вид в MFC не является строго ОО ориентированной. Так, например, Вид для отображения информации документа, обращается к методам Документа, хотя, для уменьшения зависимотей, он (Вид) не должен ничего знать о Документе. То есть:

FAD>вместо

FAD>

FAD>   Display(m_pDocument->GetData());
FAD>

FAD>лучше уж

FAD>

FAD>   m_pDocument->DisplayView(this);
FAD>

Вот это да. С каких это пор источники данных должны знать про свои представления.

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


AJD>Вот это да. С каких это пор источники данных должны знать про свои представления.

он и незнает почти ничего о представлениях а видит специализированный узкий интерфейс. а DisplayView есть template method. IMHO в определенных случаях довольно интерестно можно разрулить

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

ssm>так документу их помнить и не надо, ведь представление передается как параметр

Тогда следует предполагать, что всеми представлениями документ будет пользоваться одинаково.
Например, есть документ музыкального редактора. Пусть в списке содержатся указатели на структуры нот (с полями, скажем, высота, длительность).
Представление №1 (графическое) даёт в пользование документу графический контекст: "Вот, пожалуйте, можете рисовать; поставить перо, провести линию..."
Представление №2 (звуковое) предлагает набор команд МИДИ (возбудить ноту, заглушить)
Вопрос: что общего между этими представлениями? Может, последовательность вызовов?

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

W>Пишу программу (интерфейсные дела составляют2/3 от объема программы). Активно использую MFC. Вспомнил, что периодически слышу высказывания "MFC го**но", "на MFC ни кто не пишет". Задумался чем его можно заменить в VC. Ответ не нашел.

W>Так почему оно го**но, и чем его можно заменить?

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

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

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

W>>Пишу программу (интерфейсные дела составляют2/3 от объема программы). Активно использую MFC. Вспомнил, что периодически слышу высказывания "MFC го**но", "на MFC ни кто не пишет". Задумался чем его можно заменить в VC. Ответ не нашел.

W>>Так почему оно го**но, и чем его можно заменить?

B>как увидишь человека, который говорит это (или похожее) не употребляя фразы "по сравнению с...", то быстро кинь в него чем-нибудь
имхо, абослютно верно, есть старое правило — "не нравиться? сделай лучше", а все эти гуру нос воротят "мол не царское это дело" а так и я могу... я как-то пытался критичное по скорости приложение перенести на втл (скажем просто я на мфц по молодости криво написал просто, но уж переделывать так переделывать) вот тут то я все и ощутил сплиттеры (1 оргазм, три фразы матом), полное отстусвие Doc-View (вообще как идеи) (2 оргазма, 4 матом), полное отсуствие сериализации (без мата, без оргазмов, просто началась горькая пьянка) — а ведь ни слова не было об вининет, инкапусуляцции обьектов синхронизации.... Кто то из мудрых сказал "ни что ни есть ни хорошо, ни плохо — все зависит от того как мы смотрим на вещи"! МФЦ не только ГУИ, и потом для шибко грамотных ведь никто не мешает вписать в свой проект винапишный код, и делать все ручками самому там где надо (собственно мне никто не помешал расковырять CToolBar+CToolBatCtrl так, что и выпадающие менюшки, и сами помнят состояния, и опции какие кнопки дефолтом при первом запуске убрать — и все что надо при инициализации передается парочка-троечка параметров, типа айди меню, да ключи реестра где хранить). Так что я думаю старая истина "оптимизация — фунция целевая", в том смысле что оптимизация чего, скорости разработки? скорости работы? надежности? отсутствия копирайтов микрософта? портируемость?

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

AJD>Здравствуйте, Константин, Вы писали:


К>>Сходу смог вспомнить такую задачу. Требуется сделать SDI с поддержкой нескольких типов файлов, но одинакового шаблона. Т.е., например, сделать текстовый редактор, с которым автоматически ассоциируются TXT-, LOG- и, скажем, INI-файлы, у каждого своя иконка, своё название типа в реестре, но открываться и обрабатываться в редакторе они должны совершенно одинаково. <skipped>

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

Просто для написания всех этих возможностей приходится лезть очень и очень глубоко. В частности — пришлось открывать некоторые исходные файлы MFC и передирать оттуда кучу кусков кода. Конечно, нельзя сделать в библиотеке всё, но библиотека должна быть легко расширяемой.

К>>Пока писал, вспомнил другой пример — всем известная проблема дизейбла пункта меню или кнопки тулбара. Ну почему бы не сделать просто EnableMenuItem(FALSE)? Так нет, берёт, самостоятельно внутри устанавливает обратно стиль Enabled.

AJD> А можно подробней про эту проблему? ( всем известная, а я не знаю ). Если ты имеешь ввиду, что меню дизеблится если нет обработчика — то это везде документированная фича (никак не проблема)

Нет, не про эту. Это как раз понятно и логично. Я про обратную проблему: что если обработчик есть, то задизейблить меню через EnableMenuItem(FALSE) не удаётся — он автоматически делается активным. Приходится переопределять WM_UPDATE_COMMAND_UI. Отключать эту обработку совершенно неправильно (это я к посту JakeS). Просто раз дело обстоит таким образом, то зачем тогда вообще существует функция CMenu::EnableMenuItem, если всё определяется исключительно тем, есть у команды меню обработчик или нет? (я про ситуацию, когда WM_UPDATE_COMMAND_UI не переопределена) В MSDN чётко сказано, что эта функция делает пункт меню активным/неактивным/серым, ни о каких UPDATE_COMMAND_UI и не заикается. Ну и что должен думать порядочный программист, впервые столкнувшийся с этой проблемой?.. Я лично, когда натолкнулся на это, долго искал в чём причина, вылизывал свой код, проверял всё, что только можно, пока наконец не влез внутрь MFC, в обработку открытия подменю, где и увидел раздизейбливание пункта при наличии обработчика. Очень обиделся и вместо EnableMenuItem(FALSE) вставил вызов ModifyMenu(..., MY_COMMAND_ID_GREY), определив MY_COMMAND_ID_GREY как новую команду без обработчика. Сразу заработало, как часы
Правда, это минус не только MFC, но и частично — её документации.

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

AJD>К примеру ?

Добавить пользовательские конпки в titlebar диалога, при условии, что в Windows CE фактически нет API и сообщений для неклиентской области окна! Решение — либо переделывать все ресурсы, оставляя вверху окна место под нарсиованный вручную заголовок с кнопками (у нас так сделано сейчас), либо создание дополнительного окошка с кнопками с размещением его надо диалогом и отбработкой ресайза и перемещения (так было сделано в предыдущем проекте).
Оба варианта с точки зрения совместимости с MFC — застрелиться, причем отдельно надо поддерживать propertysheets, frames, dialogs. Мало того, что нужно разбираться в тонкостях winapi, так еще приходится продираться через убойный MFC, причем так, чтобы работало и под PC и под CE3.0/4.0 и HPC/PPC.

Опытный программист, конечно, довоьно быстро решит все эти задачи. Но только чтобы того опыта набараться, это же какой хороший кусок жизни надо загубить...


Я пробовал пару раз использовать WTL для собственных нужд, должен признать что он лучше MFC. Судя по остановке в развитии WINAPI, особенной поддержки и не нужно будет. Так что рекомендуется.

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

X>Добавить пользовательские конпки в titlebar диалога, при условии, что в Windows CE фактически нет API и сообщений для неклиентской области окна! Решение — либо переделывать все ресурсы, оставляя вверху окна место под нарсиованный вручную заголовок с кнопками (у нас так сделано сейчас), либо создание дополнительного окошка с кнопками с размещением его надо диалогом и отбработкой ресайза и перемещения (так было сделано в предыдущем проекте).
X>Оба варианта с точки зрения совместимости с MFC — застрелиться, причем отдельно надо поддерживать propertysheets, frames, dialogs. Мало того, что нужно разбираться в тонкостях winapi, так еще приходится продираться через убойный MFC, причем так, чтобы работало и под PC и под CE3.0/4.0 и HPC/PPC.

Единственное что могу сказать по этому поводу — MFC не очень подходит для PDA. Когда проектировали MFC Pocket PC еще не существовал.

X>Опытный программист, конечно, довоьно быстро решит все эти задачи. Но только чтобы того опыта набараться, это же какой хороший кусок жизни надо загубить...
Просто так ничего не дается В принципе можно и на VBA писать


X>Я пробовал пару раз использовать WTL для собственных нужд, должен признать что он лучше MFC. Судя по остановке в развитии WINAPI, особенной поддержки и не нужно будет. Так что рекомендуется.

WTL хорошая либа, но она слишком низкоуровневая даже в сравнении с MFC.

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

X>Добавить пользовательские конпки в titlebar диалога, при условии, что в Windows CE фактически нет API и сообщений для неклиентской области окна! Решение — либо переделывать все ресурсы, оставляя вверху окна место под нарсиованный вручную заголовок с кнопками (у нас так сделано сейчас), либо создание дополнительного окошка с кнопками с размещением его надо диалогом и отбработкой ресайза и перемещения (так было сделано в предыдущем проекте).
X>Оба варианта с точки зрения совместимости с MFC — застрелиться, причем отдельно надо поддерживать propertysheets, frames, dialogs. Мало того, что нужно разбираться в тонкостях winapi, так еще приходится продираться через убойный MFC, причем так, чтобы работало и под PC и под CE3.0/4.0 и HPC/PPC.

Единственное что могу сказать по этому поводу — MFC не очень подходит для PDA. Когда проектировали MFC Pocket PC еще не существовал.

X>Опытный программист, конечно, довоьно быстро решит все эти задачи. Но только чтобы того опыта набараться, это же какой хороший кусок жизни надо загубить...
Просто так ничего не дается В принципе можно и на VBA писать


X>Я пробовал пару раз использовать WTL для собственных нужд, должен признать что он лучше MFC. Судя по остановке в развитии WINAPI, особенной поддержки и не нужно будет. Так что рекомендуется.

WTL хорошая либа, но она слишком низкоуровневая даже в сравнении с MFC.

Здравствуйте, Слава Шевцов, Вы писали:

СШ>Ну IBM мастера на такие вещи. Неоднократно создавали/покупали крупные программные продукты и вдруг забивали на них. Вот типичный пример. Создали OS/2 и практически плюнули на неё (помомему, она работает только в кассовых аппаратах).
гыг. видел как она красиво глючила в наших местных банкоматах lol

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

Ovl>я пробовал wtl
Ovl>нормально. на довольно низком уровне работает, все прозрачно, не так закамуфлировано как mfc.
Ovl>в принципе похоже на mfc, но wtl легче, там проще работать с COM.
гм... со7 глупый оффтоп-вопрос задам, но знать-то хоцца
Можно ли этот самый здоровский опен-сорс WTL использовать совместно с, например, minGW? а ещё точнее — с DevC++? Заранее спасибо, если кто-то ответит

Здравствуйте, Слава Шевцов, Вы писали:

... она уже доведена до совершенства. И стоит вместе с компилятором $100. Что может быть лучше? Не знаю...




Ну это не более, чем смешно!

А что в ней, собственно, есть совершенного?? Полный дубляж WinAPI функций? Причем дубляж с кучей бесполезных накруток, которые кроме тормозов ничего не делают.

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

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

W>>Пишу программу (интерфейсные дела составляют2/3 от объема программы). Активно использую MFC. Вспомнил, что периодически слышу высказывания "MFC го**но", "на MFC ни кто не пишет". Задумался чем его можно заменить в VC. Ответ не нашел.

W>>Так почему оно го**но, и чем его можно заменить?

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

Ну почему же??

Например, я работал с MFC, и считаю, что это полный отстой! Но мне для такого умозаключения ненадо его с чем-то сравнивать.
Вот если ты, например, выпил какой-нибудь новый напиток и он тебе не понравился. Ты же его не сравнивал. Аналогичная ситуация.

Здравствуйте, Слава Шевцов, Вы писали:

W>>>Так почему оно го**но, и чем его можно заменить?

СШ>Кстати, а кто-нибудь ответит человеку на первую часть вопроса? Я уже весь заждался....

По этому поводу можно посмотреть эту

Автор(ы): Александр Шаргин
Дата: 21.04.2001

Первая часть статьи посвящена основам WTL. Автор даёт краткий обзор WTL, описывает процесс её установки, а затем объясняет базовые средства поддержки оконного интерфейса: иерархию оконных классов, циклы сообщений и карты сообщений.

статью:

За 8 лет своего существования MFC прошла долгий путь развития и успела обзавестись "тяжёлой наследственностью". В ней сосуществуют (не всегда мирно) как старые классы (типа CToolBar), так и более новые (такие, как CToolBarCtrl). Для поддержки совместимости с уже существующим кодом Микрософт была вынуждена вносить в MFC всё новые и новые неоптимальные решения и "заплатки", которые сделали внутреннее устройство MFC запутанным и ненадёжным. Сейчас уже практически невозможно что-то изменить в архитектуре MFC, не получив при этом неприятных побочных эффектов. Косность и монолитность MFC порой приводит программистов в бешенство. Наконец, MFC создавалась в то время, когда Windows не поддерживала многопоточное программирование, и с тех пор остаётся недостаточно потокобезопасной. Другими словами, в своём развитии MFC зашла в тупик, и теперь её отмирание — это вопрос времени.

Там же и преимущества MFC указаны

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

W>"на MFC ни кто не пишет".

Никто не пишет?

Автор: Tolanay
Дата: 12.10.04
Вопрос: Сабж.

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

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

ага, зато WinForms просто летают, и если я ставлю свое Апп на машину на которой другая версия Framework то оно преспокойнейше запускается, так ведь?

А Microsoft может отказаться от MFC только для того что бы продвинуть Framework, при этом они плюнут в душу многим программерам!

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


W>Так почему оно го**но, и чем его можно заменить?


пиши на VCL. Он же почти один в один повторяетcя в VCL.NET

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

W>Пишу программу (интерфейсные дела составляют2/3 от объема программы). Активно использую MFC. Вспомнил, что периодически слышу высказывания "MFC го**но", "на MFC ни кто не пишет". Задумался чем его можно заменить в VC. Ответ не нашел.
W>Так почему оно го**но, и чем его можно заменить?
Погоня за модой это глупо, в коммерческом программировании неприемлимы идеи немодно поэтому го@но, всегда нужно оценивать затраты на переход на новую систему...

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

M>>>Qt,
M>>>wxWindows сам не пробовал.
M>>>Обе псевдо-кроссплатформенные
CS>>А почему псевдо?
CS>>Qt насколько я знаю, нормально в Линух себя чувствует...

M>Потому что под каждую из платформ надо собирать отдельно.

Насколько я знаю, единственный язык, которые не надо собирать под разные платформы — это HTML (но это и не язык per se), остальные надо собирать. Интерпретируемые языки не в счет, так как для каждой отдельной платформы нужно в придачу тащить заточенный под данную платформу рантайм или виртуальную машину.

А так, Qt и wxWindows(wxWidgets) именно реально кроссплатформенные, так как их код — "write once, compile everywhere"

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

M>Насколько я знаю, единственный язык, которые не надо собирать под разные платформы — это HTML (но это и не язык per se), остальные надо собирать. Интерпретируемые языки не в счет, так как для каждой отдельной платформы нужно в придачу тащить заточенный под данную платформу рантайм или виртуальную машину.
А для HTML не нужно?
наверное ты читаешь форум в html "сорцах" не пользуясь браузерами

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

W>Так почему оно го**но, и чем его можно заменить?

Может конечно и не совсем го..., все-таки на нем пишут, хотя его просто больше раскрутили. MFC не очень гибкий, уж слишком в крепкий узел завязано там все.
WTL наверно в чем-то лучше, все-таки гибче и уровень пониже, то еть легче настроить под свои нужды, полностью поддерживает СOM, так как написан на базе ATL, который используется именно для СОМ. То есть можно писать даже и на ATL, это уже ниже уровень. WTL как бы интерфейсная надстройка над ATL. Ну а если еще ниже, то старый добрый API, который все терпит

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

W>Пишу программу (интерфейсные дела составляют2/3 от объема программы). Активно использую MFC. Вспомнил, что периодически слышу высказывания "MFC го**но", "на MFC ни кто не пишет". Задумался чем его можно заменить в VC. Ответ не нашел.

W>Так почему оно го**но, и чем его можно заменить?

ИМХО, довольно часто можно мрименять связку HTML/DHTML. Это вариант не очень привязан к MFC, правда выделывать трюки ((c) кто-то из великих)
с указателями на COM-интерфейсы тоже не очень приятно.