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>Для обсуждаемых объёмов и задачь, эта "низкоуровневость" ни как не скажеться на скорости и сложности реализации. Разве что на суммарном объёме получившегося продукта.

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