У меня вопрос, немного на свободную тему, просто интересно услышать мнения специалистов. Я раньше, когда еще не было управляемого кода и 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 надо прочитать иначе будете ходить по граблям и за каждой херней лезть на форум.