У меня вопрос, немного на свободную тему, просто интересно услышать мнения специалистов. Я раньше, когда еще не было управляемого кода и CLR-проектов — задавался вопросом — почему от Borland есть УДОБНЕЙШАЯ среда для разработки — C++ Builder (она аналогична Delphi, только язык Паскаль), а от Microsoft НИЧЕГО удобного не было. (недаром Delphi и C++ Builder стали тогда настолько знамениты). От Microsoft был тогда Visual C++ 6, и если делать обычные оконные Windows-приложения, то выбор был из 2-х типов проектов — либо Win32 Application, либо MFC Application. С типами проектов Win32 Application — неудобно работать, надо писать вручную оконную функцию, задавать ручками все параметры типа "wcex.hIcon = ..." и т.д. Там нельзя было в дизайнере бросать на форму кнопки, элементы и т.д. Значит, от Microsoft оставалось использовать только проеты типа MFC Application, но работать с ними намного менее удобно, чем с C++ Builder (почему, напишу ниже). Поэтому, я программировал исключительно на C++ Builder и был рад.

Но теперь мне нужно перевести свои приложения под 64-разрядную платформу. Это обязательно, т.к. 32-разрядное приложение не может адресовать 5 ГБ оперативной памяти, а именно столько сейчас нужно. Чтобы создать 64-разрядное приложение, нужен 64-разрядный компилятор, который появился в MS Visual Studio 2005, а от фирмы Borland он почему-то до сих пор так и не появился (я читал описания C++ Builder 2006, и даже 2007). Значит, переходить по-любому придется на эту майкрософтовскую среду.

Известно, что управляемый код работает медленнее, чем неуправляемый, т.к. там проводится куча всяких дополнительных проверок, обеспечивающих безопасность кода, работает сборка мусора и т.д. Если очень важно быстродействие программы, если работаем с WinAPI-функциями, то управляемый код, проекты типа CLR не подходят. У меня как раз такой случай. Что же тогда остается? Выбирать проект типа CLR, на C++ и "насильственно" делать его неуправляемым — как-то некрасиво, должны же быть стандартные средства. А из стандартных средств для такого моего случая Microsoft предоставила, как я сказал выше, только MFC-проекты, и несмотря на все неудобство, так ничего удобнее там и не сделали...

У меня просто слов нет!!! Может я чего не понимаю в ихней логике работы, т.к. с MFC-проектами не работал... Скажите хотя бы прав ли я в своем понимании... Когда в Delphi или в C++Builder-e создаешь окно — кидай туда что хочешь — и таймеры, и меню и тулбар и кнопки... У MFC — разделили на типы — для диалоговых окон почему-то нельзя создать меню, записывать в файлы, мало компонентов (даже таймера нет). Зато можно кидать кнопки. А если создать приложение типа Document (Single или Multiple) — есть меню, и т.д., но нельзя кидать кнопки!

Зачем нужно это идиотское разделение? А если я хочу создать окно со всем — и с кнопками и с меню и с таймерами и т.д. ?? Да и я много приложений встречал, где и кнопки есть на форме, и меню и много чего другого... Возможно, и в MFC- проектах можно это все подключить, если помучаться но зачем? Я хочу просто с палитры компонентов накидать все, что нужно и работать со своим функционалом, а не париться, как подключить то, что не предусмотрено для такого типа приложения.

Неужели выход один — если хочу юзать удобный UI , и нужен именно такой тип приложения как у меня, то использовать тип проекта CLR (там действительно удобный UI для разработчика) для C++ WinForms -- и делать весь код там неуправляемым?

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

S_N> Неужели выход один — если хочу юзать удобный UI , и нужен именно такой тип приложения как у меня, то использовать тип проекта CLR (там действительно удобный UI для разработчика) для C++ WinForms -- и делать весь код там неуправляемым?

Там был такой class-wizard...

Но тебе возможно было бы проще и удобнее заботать RPC и разделить свою прогу на две -- сервер и оболочку. Оболочку оставить текущую, а сервер переписать на 64-битный компилер...

>>Там был такой class-wizard... >>

class-wizard для какого проекта? Для проекта типа Document?

Здравствуйте, Skipper_N.

1. У MFC весьма строгая архитектура. Правила такое — хочешь писать под MFC хорошо — следуй правилам, иначе имей проблемы.

2. Меню на диалог кладется без пробелм. Если проблемы есть — могу подсказать.

3. Как и ты, я тоже начинал с билдера, и как и ты первое мое знакомство с MFC было отталкивающим. Но зато второе, третье и сто третье были позитивными, и теперь я бы не стал касаться билдера и 3-х метровой палкой.

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

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

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

[]

MFC в топку. Есть огромное количество более других библиотек GUI. Да и других языков, зачем GUI на C++ делать?

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

S_N> class-wizard для какого проекта? Для проекта типа Document?
Я MFC давно не пользовался, и что в новой студии не знаю. Но раньше было для любого MFC-based проекта возможно воспользоваться calss-wizard'ом. В принципе какая ему разница? Он же всего лишь связь окошечных ресурсов кода поддерживает...

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

RO>MFC в топку. Есть огромное количество более других библиотек GUI. Да и других языков, зачем GUI на C++ делать?

А зачем его делать не на С++ и не на MFC. Никогда непосредственно с MFC проблем не имел. У него есть своя ниша, он в ней неплохо себя чувствует.

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

RO>>MFC в топку. Есть огромное количество более других библиотек GUI. Да и других языков, зачем GUI на C++ делать?

W>А зачем его делать не на С++ и не на MFC. Никогда непосредственно с MFC проблем не имел. У него есть своя ниша, он в ней неплохо себя чувствует.

Имел сколько угодно проблем с MFC, такая антикварная гадость. К тому же, основные библиотеки GUI еще и кроссплатформенные, тоже преимущество.

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

в MFC можно делать нормальный гуй. Используя сторонние библиотеки =).

Меня например от борланда тошнит.

Может тебе QT подойдет?

Тут уже обсуждалась тема почему Delphi (C++ Builder) – мертвая среда разработки. Не знаю чем все кончилось но IMHO, стиль Борланд (его визарды и пр.) стимулирует писать винегрет-код где формы мешаются с логикой приложения и со всеми файлами проекта. Если вы это понимаете, вы начинаете борьбу со средой (причем успешную) и пишите хороший код, если нет – берегитесь.
Насчет MFC после VCL у меня создалось впечатление, что Microsoft сделало вид что написало оболочку для WinApi и назвало это MFC, т.е. после VCL Вы будете в шоке от объектной модели.

ОДНАКО
Я не, если честно не понимаю, как связаны быстродействие и методы представления пользовательского интерфейса или же вы сообщаете пользователю о прогрессе расчета со скоростью 50 сообщений в секунду? (если да, то используйте DirectX и не мучайтесь) Поэтому, на мой взгляд, тут вопрос в архитектуре – критические алгоритмы и функционал пишется на С++ & STL (если угодно на core C), а пользовательская морда – на всем чем удобно (MFC, С++.NET (кстати учите, что здесь С++ просто проходило мимо, это вообще другой язык). В этом случае “медленный” “управляемый” код будет исполнятся только при взаимодействием с пользователем – существом еще более медленным и вообще неупровлемым.

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

>... MFC, такая антикварная гадость.

Тежду прочим, такая же, как и Windows GDI / Windows USER, но от нее никуда не денешся.

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

[]

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

S_N>Зачем нужно это идиотское разделение? А если я хочу создать окно со всем — и с кнопками и с меню и с таймерами и т.д. ?? Да и я много приложений встречал, где и кнопки есть на форме, и меню и много чего другого... Возможно, и в MFC- проектах можно это все подключить, если помучаться но зачем? Я хочу просто с палитры компонентов накидать все, что нужно и работать со своим функционалом, а не париться, как подключить то, что не предусмотрено для такого типа приложения.

От себя добавлю, что любители борланда обычно делали винегрет-ui — на окна кидали обычные кнопки, на диалоги менюхи и вообще был полный бардак и безвкусица. +дурацкая IDE, +дебильный компилятор

S_N> Неужели выход один — если хочу юзать удобный UI , и нужен именно такой тип приложения как у меня, то использовать тип проекта CLR (там действительно удобный UI для разработчика) для C++ WinForms -- и делать весь код там неуправляемым?

То, что managed языки намного медленнее нативных уже давно не так. Они медленнее в специфичных областях. Так что если у тебя нету зубодробительных вычислений и кучи legacy (тут может помочь c++/cli), то можно попробовать. Кроме того, для MFC есть куча third parties, которые не уступают аналогам от DevExpress etc — e.g. CodeJoke.com

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

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

КЛ>Кроме того, у меня есть ощущение, что пора бы остановить наращивание крутости UI. Это часто мешает. UI должен быть простой, лаконичный, интуитивный и не пестрый. Погоня за навороченностью должна остановиться.
+1

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

W>3. ... Меню на диалог кладется без пробелм. Если проблемы есть — могу подсказать.

Подскажите пожалуйста, какие действия нужно совершить с проектом MFC, чтобы у меня в одном окне было —

1. button-ы, edit-ы, combobox-ы и т.п. (для этого, очевидно, надо выбирать, когда создаем проект в самом начале — тип проекта Dialog based, А НЕ Single(Multiple) Document, иначе там вообще палитры компонентов не будет — чтобы их сразу можно было бросить на форму).

2. Меню в этом же окне, т.е. типа File -> Open, Save, Save as, и т.д. В C++ Builder-e можно было на одно окно бросить и контролы (button-ы и т.д.) и такое меню. А в MFC меню для диалоговых типов приложений не предусмотрено (читал в книге). И вообще, полистав много книг по MFC-проектам, я нигде почему-то не видел окошка, где были бы и контролы и меню!!

3. Если меню уже создано, то чтобы оно не было пустым, а выбрав например File -> Open, появилось окошко с возможностью выбрать файл. В C++ Builder-e был такой специальный компонент прямо на палитре компонентов, OpenDialog назывался, его нужно было просто бросить на форму, а в обработчике нажатия на меню — просто вызвать, а в MFC, как я уже писал — компонентов раз-два и обчелся, и такого компонента нет. (В C++ Builder-e OpenDialog после работы выдавал путь (в string) к выбранному файлу, а уж что мне с ним делать, я сам решу — может это save-файл компьютерной игры или еще что-нибудь.)

4. Как запустить в MFC-проекте (тип проекта Dialog based) — таймерную функцию, которая будет выполняться N раз в секунду. В C++ Builder-e был такой специальный компонент Timer, который просто бросаешь на форму, ставишь в окне Properties — Enabled, и пиши собственно функцию Timer1_Timer, которая и будет выполняться N раз в секунду.

5. Нажатием какой-нибудь кнопки — запустить отдельный поток, который начинает выполнять какую-нибудь функцию.

Вот и всё! Больше мне ничего не нужно, кроме этой описанной "пустышки" из 5 пунктов, останется только работать со своим функционалом. Никаких других окон быть не должно. Если это можно сделать в MFC — так же удобно как в C++ Builder-e, тогда действительно можно сказать, что MFC лучше. Чтобы сделать эту "пустышку" из 5-ти описанных выше пунктов в C++ Builder — мне понадобилось когда-то всего 10 минут. Лучшие специалисты по MFC, могут сделать то же самое в MFC-проекте? Мне почему-то кажется, что эти вещи там просто не предусмотрены.

Went. Заранее, огромное спасибо.

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

S_N>Подскажите пожалуйста, какие действия нужно совершить с проектом MFC, чтобы у меня в одном окне было —

S_N>1. button-ы, edit-ы, combobox-ы и т.п. (для этого, очевидно, надо выбирать, когда создаем проект в самом начале — тип проекта Dialog based, А НЕ Single(Multiple) Document, иначе там вообще палитры компонентов не будет — чтобы их сразу можно было бросить на форму).

не очевидно. Можно сделать SDI на основе CFomView, который использует диалоговый ресурс.

S_N>2. Меню в этом же окне, т.е. типа File -> Open, Save, Save as, и т.д. В C++ Builder-e можно было на одно окно бросить и контролы (button-ы и т.д.) и такое меню. А в MFC меню для диалоговых типов приложений не предусмотрено (читал в книге). И вообще, полистав много книг по MFC-проектам, я нигде почему-то не видел окошка, где были бы и контролы и меню!!

см. выше. будет тебе меню. В книгах по MFC обычно самые простые, стандартные вещи рассматривают.

S_N>3. Если меню уже создано, то чтобы оно не было пустым, а выбрав например File -> Open, появилось окошко с возможностью выбрать файл. В C++ Builder-e был такой специальный компонент прямо на палитре компонентов, OpenDialog назывался, его нужно было просто бросить на форму, а в обработчике нажатия на меню — просто вызвать, а в MFC, как я уже писал — компонентов раз-два и обчелся, и такого компонента нет. (В C++ Builder-e OpenDialog после работы выдавал путь (в string) к выбранному файлу, а уж что мне с ним делать, я сам решу — может это save-файл компьютерной игры или еще что-нибудь.)

В Doc/View уже есть File-Open, File-Close итд. Плюс есть MFC класс для этого CFileDialog (да, о ужас, в тулбоксе дизайнера его нету =), плюс все тоже самое можно сделать средствами WIN API.

S_N>4. Как запустить в MFC-проекте (тип проекта Dialog based) — таймерную функцию, которая будет выполняться N раз в секунду. В C++ Builder-e был такой специальный компонент Timer, который просто бросаешь на форму, ставишь в окне Properties — Enabled, и пиши собственно функцию Timer1_Timer, которая и будет выполняться N раз в секунду.

=) SetTimer тебе в помощь. Естественно, в MFC надо больше "ручками" делать. Но ничего сложного нету (во всяком случае то, что ты описываешь — тривиальные вещи)

S_N>5. Нажатием какой-нибудь кнопки — запустить отдельный поток, который начинает выполнять какую-нибудь функцию.

AfxBeginThread. Совет — если работаешь с MFC, не пожалей, купи книжку какую-нибудь например
А. Мешков, Ю. Тихомиров "Visual C++ и MFC", там основные вопросы разобраны. Плюс на codeproject.com довольно богатый раздел по VC++/MFC там можно найти кучу примеров по разным темам.

S_N>Вот и всё! Больше мне ничего не нужно, кроме этой описанной "пустышки" из 5 пунктов, останется только работать со своим функционалом. Никаких других окон быть не должно. Если это можно сделать в MFC — так же удобно как в C++ Builder-e, тогда действительно можно сказать, что MFC лучше. Чтобы сделать эту "пустышку" из 5-ти описанных выше пунктов в C++ Builder — мне понадобилось когда-то всего 10 минут. Лучшие специалисты по MFC, могут сделать то же самое в MFC-проекте? Мне почему-то кажется, что эти вещи там просто не предусмотрены.

Я далеко не лучший специалист по MFC, но такую штуку делать... Ну полчаса, может час, не особо напрягаясь. Если особо припрет можно и за 10 минут.

S_N>Went. Заранее, огромное спасибо.

Да пожалуйста.

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

S>не очевидно. Можно сделать SDI на основе CFomView, который использует диалоговый ресурс.

Вот это место меня и интересует. Открыл MS Visual Studio 2005, File-New Project, выбрал тип проекта — НЕ Dialog Based, а Single Document. Где можно выбрать "на основе CFomView" ? Нету такой опции, перепробавал разные — нигде после создания проекта не вижу окна с меню, и чтобы можно было кнопки и контролы с панельки кидать на форму... Напишите подробнее, какие действия для этого нужно совершить?

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

КЛ>От себя добавлю, что любители борланда обычно делали винегрет-ui — на окна кидали обычные кнопки, на диалоги менюхи и вообще был полный бардак и безвкусица


Я встречал много приложений, в которых было такое окно -> "ЕСТЬ МЕНЮ" и "ЕСТЬ КНОПКИ, КОНТРОЛЫ". Например, шахматная программа. На окне нарисована доска и кнопки для управления игрой. И что там не должно быть меню? Если нужно открыть сохраненную игру например, или изменить настройки. Можно конечно специальную кнопку для этого на форму бросить — вот тогда действительно УБОЖЕСТВО получится...


Окно с меню и кнопками, контролами что, чему-то противоречит, каким-то концепциям или как? Где закон, который запрещает так делать? И по-вашему, любое такое окно можно расценивать как "винегрет-ui" ?

По-моему ЭТО как раз не делает "винегрет-ui", а если какие-то разработчики доводят дело до бардака и до винегрета, то это не значит, что так хочу делать я. И не значит, что нужно запрещать так делать. Дайте мне все возможности (меню и кнопки на одну форму например), а я сам решу как ими распоряжаться.

S_N>1. button-ы, edit-ы, combobox-ы и т.п. (для этого, очевидно, надо выбирать, когда создаем проект в самом начале — тип проекта Dialog based, А НЕ Single(Multiple) Document, иначе там вообще палитры компонентов не будет — чтобы их сразу можно было бросить на форму).

Да, есди хочется набросать контролы одним движением мышки — то делай Dialog based. И не стоит удивляться, что Single(Multiple) Document не позволяет этого делать — достаточно посмотреть любое приложение. Контролы должны быть на своем месте, а не разбросанными где попало по окну приложения — именно это довольно часто позволяет отличить приложение, написанное на бидере или делфи от других.

S_N>2. Меню в этом же окне, т.е. типа File -> Open, Save, Save as, и т.д. В C++ Builder-e можно было на одно окно бросить и контролы (button-ы и т.д.) и такое меню. А в MFC меню для диалоговых типов приложений не предусмотрено (читал в книге). И вообще, полистав много книг по MFC-проектам, я нигде почему-то не видел окошка, где были бы и контролы и меню!!

Меню в диалоговом окне встречается очень редко не только в книжках по МФЦ, но и в реально жизни. Именно поэтому не предусмотренно отельной кнопки для него — но это не значит, что "в MFC меню для диалоговых типов приложений не предусмотрено". Делается это очень просто: рисуеш отдельно меню, затем открываеш ресурс диалога, клачаеш на ствойствах и находиш там пункт выбора меню, где указывается идентификатор нарисованного тобой меню (кажись так ).

S_N>3. Если меню уже создано, то чтобы оно не было пустым, а выбрав например File -> Open, появилось окошко с возможностью выбрать файл. В C++ Builder-e был такой специальный компонент прямо на палитре компонентов, OpenDialog назывался, его нужно было просто бросить на форму, а в обработчике нажатия на меню — просто вызвать, а в MFC, как я уже писал — компонентов раз-два и обчелся, и такого компонента нет. (В C++ Builder-e OpenDialog после работы выдавал путь (в string) к выбранному файлу, а уж что мне с ним делать, я сам решу — может это save-файл компьютерной игры или еще что-нибудь.)

Для этого есть класс CFileDialog. В обработчике Open добавляется 2 строчки

CFileDialog dlg(true);
dlg.DoModal();

S_N>4. Как запустить в MFC-проекте (тип проекта Dialog based) — таймерную функцию, которая будет выполняться N раз в секунду. В C++ Builder-e был такой специальный компонент Timer, который просто бросаешь на форму, ставишь в окне Properties — Enabled, и пиши собственно функцию Timer1_Timer, которая и будет выполняться N раз в секунду.

Для таймера в нужном месте (нужным местом может быть обработчик кнопки "Старт" или функция OnInitDialog) вызывается SetTimer(ID_TIMER1,10,NULL); и обрабатывается OnTimer. Когда он больше не нужен вызывается KillTimer(ID_TIMER_1);

S_N>5. Нажатием какой-нибудь кнопки — запустить отдельный поток, который начинает выполнять какую-нибудь функцию.

В обработчике кнопки вызываеш AfxBeginThread(ThreadProc,NULL,THREAD_PRIORITY_NORMAL,0,0,NULL); где ThreadProc — какая-нибудь функция.

Have a lot of fun

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

КЛ>От себя добавлю, что любители борланда обычно делали винегрет-ui — на окна кидали обычные кнопки, на диалоги менюхи и вообще был полный бардак и безвкусица.

Я добавлю, что в проектах типа CLR, которые сейчас самые часто встречающиеся, UI для разработчика почти как в C++Builder-e. Т.е. там — пожалуйста — вот вам окно, и вот вам МНОГО-ПРЕМНОГО компонентов. Хотите — кидайте кнопки на форму, меню, таймеры и т.д. все что угодно. (Компонент же в MFC-проектах раз-два и обчелся) А почему мне CLR не совсем подходит, я уже писал.

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

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

S>>не очевидно. Можно сделать SDI на основе CFomView, который использует диалоговый ресурс.

S_N>Вот это место меня и интересует. Открыл MS Visual Studio 2005, File-New Project, выбрал тип проекта — НЕ Dialog Based, а Single Document. Где можно выбрать "на основе CFomView" ? Нету такой опции, перепробавал разные — нигде после создания проекта не вижу окна с меню, и чтобы можно было кнопки и контролы с панельки кидать на форму... Напишите подробнее, какие действия для этого нужно совершить?

Там в визарде есть пункт Generated Classes, в котором можно выбрать класс который будет у тебя использоваться как View, надо выбрать CFormView.

кнопки и контролы чтоб кидать надо открыть дизайнер ресурсов (Resource View), там выбрать диалоговый ресурс, там же можно и меню редактировать и тулбар. Тулбокс с контролами у меня выезжает справа по кнопачке, а ваще View->Toolbox.

В самом деле, купите/скачайте книжку. Хотя бы немного теории по MFC надо прочитать иначе будете ходить по граблям и за каждой херней лезть на форум.

S>В самом деле, купите/скачайте книжку. Хотя бы немного теории по MFC надо прочитать иначе будете ходить по граблям и за каждой херней лезть на форум.
Для начала, можно глянуть и здесь MFC шаг за шагом

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

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

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

КЛ>>От себя добавлю, что любители борланда обычно делали винегрет-ui — на окна кидали обычные кнопки, на диалоги менюхи и вообще был полный бардак и безвкусица.

S_N> Я добавлю, что в проектах типа CLR, которые сейчас самые часто встречающиеся, UI для разработчика почти как в C++Builder-e. Т.е. там — пожалуйста — вот вам окно, и вот вам МНОГО-ПРЕМНОГО компонентов. Хотите — кидайте кнопки на форму, меню, таймеры и т.д. все что угодно. (Компонент же в MFC-проектах раз-два и обчелся) А почему мне CLR не совсем подходит, я уже писал.

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

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

S>>>не очевидно. Можно сделать SDI на основе CFomView, который использует диалоговый ресурс.

Вы имеете в виду 2005-ю студию с типом проектов MFC Application? Я смотрю именно ее.

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

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


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

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

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

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

S_N>Подскажите пожалуйста, какие действия нужно совершить с проектом MFC, чтобы у меня в одном окне было —

S_N>1. button-ы, edit-ы, combobox-ы и т.п. (для этого, очевидно, надо выбирать, когда создаем проект в самом начале — тип проекта Dialog based, А НЕ Single(Multiple) Document, иначе там вообще палитры компонентов не будет — чтобы их сразу можно было бросить на форму).

Да, проще всего для этого использовать Dialog Based. Есть еще вариант с Document-View Architecture, где в типе класса вида указать CFormView, тогда в ресурсах появится такой же диалог, как и в первом варианте. Но этот вариант немного мутантский, не люблю CFromView

S_N>2. Меню в этом же окне, т.е. типа File -> Open, Save, Save as, и т.д. В C++ Builder-e можно было на одно окно бросить и контролы (button-ы и т.д.) и такое меню. А в MFC меню для диалоговых типов приложений не предусмотрено (читал в книге). И вообще, полистав много книг по MFC-проектам, я нигде почему-то не видел окошка, где были бы и контролы и меню!!

Проблем никаких. В ресурсах создаешь новое меню. Устанавливаешь ему айдишник, например, IDM_MY_MENU. Потом в свойствах ресурса диалога находишь поле "Menu" и там указываешь свою менюху. Вуаля.

S_N>3. Если меню уже создано, то чтобы оно не было пустым, а выбрав например File -> Open, появилось окошко с возможностью выбрать файл. В C++ Builder-e был такой специальный компонент прямо на палитре компонентов, OpenDialog назывался, его нужно было просто бросить на форму, а в обработчике нажатия на меню — просто вызвать, а в MFC, как я уже писал — компонентов раз-два и обчелся, и такого компонента нет. (В C++ Builder-e OpenDialog после работы выдавал путь (в string) к выбранному файлу, а уж что мне с ним делать, я сам решу — может это save-файл компьютерной игры или еще что-нибудь.)

В MFC подоход не такой. Компоненты там играют более узкую роль, и называются "Элементы Управления". Чтобы прикрутить открытие файла к Dialog-Based приложению нужно:

1. Создать меню как я сказал выше.
2. В это меню добавить пункт "Файл", в него подпункт "Открыть". Прописать у этого пункта айдишник ID_FILE_OPEN, например.
3. Теперь зайти в ClassView, там найти класс твоего диалога "Ctest_1Dlg", например, правой кнопкой "свойства", в окне свойств найти молнию, щелкнуть на нее, выбрать из списка ID_FILE_OPEN, раскрыть плюсик, выбрать COMMAND и в выпадающем списке выбрать "Add". У нас появился обработчик.
4. В коде обработчика пишем что-то вроде:

  CFileDialog dlg(TRUE, "draft", NULL, OFN_HIDEREADONLY, "Draft files (*.draft)|*.draft|All files (*.*)|*.*|");
  if (dlg.DoModal() != IDOK)
    return;
  CString path = dlg.GetPathName();

В переменную path получили путь к файлу.
Вообще, в Document-View архитектуре это уже все сделано за тебя, но, как я понял, тебе она пока что не нужна.

S_N>4. Как запустить в MFC-проекте (тип проекта Dialog based) — таймерную функцию, которая будет выполняться N раз в секунду. В C++ Builder-e был такой специальный компонент Timer, который просто бросаешь на форму, ставишь в окне Properties — Enabled, и пиши собственно функцию Timer1_Timer, которая и будет выполняться N раз в секунду.

Поищи в MSDN по

CWnd::SetTimer, CWnd::KillTimer.

Там все просто.

S_N>5. Нажатием какой-нибудь кнопки — запустить отдельный поток, который начинает выполнять какую-нибудь функцию.

1. Кладешь кнопку на твою форму, прописывешь ей все свойства и ID, например, IDC_MY_BUTTON.
2. Аналогично с меню создаешь ей обработчик
3. В обработчике пишешь:

AfxBeginThread(...)

В MSDN все есть.

S_N>Вот и всё! Больше мне ничего не нужно, кроме этой описанной "пустышки" из 5 пунктов, останется только работать со своим функционалом. Никаких других окон быть не должно. Если это можно сделать в MFC — так же удобно как в C++ Builder-e, тогда действительно можно сказать, что MFC лучше. Чтобы сделать эту "пустышку" из 5-ти описанных выше пунктов в C++ Builder — мне понадобилось когда-то всего 10 минут. Лучшие специалисты по MFC, могут сделать то же самое в MFC-проекте? Мне почему-то кажется, что эти вещи там просто не предусмотрены.

Там предумотрено достаточно всего

S_N>Went. Заранее, огромное спасибо.

Ок, спасибо, теперь все понятно. Разобрался. Но все равно, намного более геморно, чем в CLR. Могли бы и получше UI для проектов MFC сделать

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

S_N>[Snipped]

Сочетание "MFC и хороший интерфейс" как-то режет слух

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

да я согласен что в MFC много чего неудобно сделано, но у нее есть кое-какие преимущества:
— на ней можно сделать хороший гуй, используя сторонние библиотеки (в новой версии уже будет такая библиотека).
— под нее написано очень много кода, можно найти практически все, что угодно.
— она довольно "близка" к WIN API, разбираясь с MFC можно неплохо освоить WIN API.
— она входит в студию, из альтернатив, равных по функциональности, если писать на С++ — только QT, которая стоит как две студии, либо WIN API =). Остальное все скромнее по функционалу.

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

Все можно сделать, надо просто знать как =)

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

R>Сочетание "MFC и хороший интерфейс" как-то режет слух

Вот, например, AutoCAD использует MFC. Интерфейс там на уровне.

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

> А в книге написано прямым текстом — "В диалоговых приложениях НЕЛЬЗЯ создавать меню, записывать в файл и т.п."

Выкинь эту книжку.

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

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

Это Вы неправильную книжку читаете
Вот как оказывается — "не все йогурты одинаково полезны"!

Может скажете в какой это книжке такое написано?

Еще раз: добавить меню в диалог можно так — создаете в ресурсах меню, в свойствах диалога выбираете это меню — ВСЕ! Еще подробне здесь

Автор: Sashaka
Дата: 29.12.07

Что в с последних версиях студии такого нет?

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

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

Да можно их совместить! Я же тебе даже написал как!

Здравствуйте, Sashaka, Вы писали:
S>- она входит в студию, из альтернатив, равных по функциональности, если писать на С++ — только QT, которая стоит как две студии, либо WIN API =). Остальное все скромнее по функционалу.
Она входит в экспресс вариант, или только в про и выше?

При альтернативы, мне кажеться ты не прав.
Qt Open Source включает практически всё, что есть в коммерческой.
А из полностью открытых, с подобным функционалом, есть ещё wxWindows и GTK.

С моей точки зрения, выбор MFC (как и VCL) для новых проектов, может быть обусловлен полько большим количеством старых наработок и абсолютной уверенностью, что ни операционку, ни компилятор менять в дальнейшем не придётся.

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

T>С моей точки зрения, выбор MFC (как и VCL) для новых проектов, может быть обусловлен полько большим количеством старых наработок и абсолютной уверенностью, что ни операционку, ни компилятор менять в дальнейшем не придётся.

Почему вы так считаете ?

Если программа состоит из 4-6 диалогов какой смысл тащить wxWindows.
MFC вроде снова развивать начали.

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

А>Если программа состоит из 4-6 диалогов какой смысл тащить wxWindows.
А>MFC вроде снова развивать начали.

wxWidgets имеет смысл использовать хотя бы из-за сайзеров. Диалоги фиксированного размера — ацтой.

Здравствуйте, <Аноним>, Вы писали:
А>Если программа состоит из 4-6 диалогов какой смысл тащить wxWindows.
А какой тогда смысл тащить MFC? Есть же WTL? Да и на WinApi это без напрягов можно набрасать.
Смысл появляется когда нужен довольно обширный и интегрированный фреймворк — но тут, мне кажеться, MFC проигрывает более современным и развитым аналогам, или когда имеется много наработак и разработчик(и) хорошоего знают и привыкли решать все задачи на MFC.

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

Для кого и зачем MS будет развивать MFC?

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

T>А какой тогда смысл тащить MFC? Есть же WTL?
Смысл в том, что WTL еще более низкоуровневая библиотека, чем MFC.

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

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

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

Скажеться на скорости реализации. Хотя бы за счет биндинга котролов к переменным

Здравствуйте, 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%