Здравствуйте, 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. Т.е. не так уж и давно

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

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

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

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

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

вместо

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

лучше уж

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

Здравствуйте, 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, но и частично — её документации.