Начинал программировать под Delphi. Потом перебрался на Builder. Имею небольшой опыт программирования под X Window. Под Windows все в основном писал на Builder-e. Там где нужно было чего-то особенное, но не связанное с GUI, писал на Visual C++ и оформлял в виде dll. Но вот возникло требование (слава богу временное) - GUI на MFC. У меня шок... Открываю учебники и вижу помимо всяких там иерархий классов (это все понятно вроде) набор шаманских действий. Вопросы по существу:

1. Основная идеология с практической точки зрения (Пример для Builder-a: Создаете форму, кидаете на нее компоненты, назначаете свойства в инспекторе, описываете Events. Все названия свойств четко соответствуют именам членов класса)
2. Как получить доступ к конкретному объекту. Например кинул я на форму Button (класс CButton или наследник), вижу его ID типа IDC_Button1 (всего-навсего число). У класса CButton есть определенные поля, методы, свойства и пр. Как к ним достучаться? Или здесь как-то все по иному? Я например не моу пока даже поместить текст в Edit (CEdit) (Кроме как методом тыка - SetDlgItemText(...) - это ваще чё?)

Пока все. Прошу помоч.

Если речь идет про Dialog-и .
в VC6 : заходишь в View/Class Wizard... / Member Variables, там для твоего IDC_Button1 (IDC_Edit1) жмешь AddVariable дальше думаю все понятно.

в VC 2005 намного проще: для нужного Button-а(Edit-а) жмеш правой кнопкой и AddVariable ...

Про остальные VC не знаю

Спасибо. Я до этого уже допер. Вот только не понятно 2 момента:

1. Доступных свойств и методов там очень мало. Не верю что это все - MS че-то шифруется.
2. Это че такая политика для каждого объекта лазить создавать переменную? Как нормальные люди пишут?

В борланде усё просто, если нужна надпись на заборе то пишем(в зависимости от объекта) Имя_объекта->caption(или text или ещё чего, в справке смотреть надо) = "qwerty". И всё.

Это я и сам знаю. А вот вижак...

Я сам с вижулом работал мало и использовал Visual Studio .NET версию не помню. Там в объектах вообще ни у одного не было свойства Caption, вместо него у ВСЕХ было свойство Text, если я правильно все помню. А так внешне не сильно отличается от Borlandа Особенно если взять Developer Studio, так там вообще все слизано с MS Visual Studio, так что ты нарой где-нибудь BDS, посмотри ее, может - поможет...

Диалог создаеться из ресурса, и для нормального функционирования стандартных системных контролов поддержка кодом в виде экземпляра класса (иметься ввиду C++ классы, а не оконные) не нужна.
Зачем к примеру для кнопки заводить переменную (расходовать дополнительные ресурсы) если нам нужно только получить от нее сообщение BN_CLICKED ?

А вот здесь поподробнее. События то ладно, я на кнопку кликну он мне сам функцию создаст. А вот как например в программе в Edit чего-нить запихать?

Я не знаю, какая версия, но в Edit строка текста заносилась по-моему так же, как и в Buildere

Edit1->Text = "qwerty";

Я может чего туплю, но можно попробовать вместо "->" использовать ".", но вряд ли. Я точно помню у Edita было свойство Text. Или Caption не помню. Главное оно у всех надписей одно и то же. Вообще, посмотри свойства объектов в инспекторе объектов. Он почти такой же, как и в Борланде, может, называется как-то по-другому, но он там есть.

Мои пять копеек:
если гуй можно реализовать не только на MFC, то имеет смысл посмотреть в сторону Windows.Forms или QT. Последнее привлекает кроссплатформенностью и собственным прекомпилятором, добавляющим несколько удобных интерфейсов вроде сигналов, а первое - скоростью разработки, гибкостью и удобством. А MFC - это, имхо, ужос, летящий на крыльях ночи. Убивать надо за такую модель.
Еще, кстати, можно свой набор классов написать. Если компонентов будет не очень много, то это, скорее всего, окажется быстрее разбирательств с MFC.

К сожалению, уже стало общим местом поругивать Microsoft за "дыры" в "окнах", за громоздкость GUI, за MFC и Visual Studio в придачу. Как правило, такое брюзжание слышно от программистов, привыкших в своё время писать под DOS, но так и не разобравшихся до конца с эстетикой объектно-ориентированного программирования, нашедшей воплощение, в частности, в C++.

Да, можно, конечно, попытаться создать свою иерархию классов. Сколько времени у вас уйдёт на то, чтобы создать, к примеру, диалог сохранения файла с иерархией папок на Вашем компьютере ? Не рухнет ли Ваш ГУИ, если пользователь, скажем, поменяет разрешение экрана или растянет окно ?

Пишу программное обеспечение под Windows, как пресловутый GUI, так и драйвера уровня ядра. И чем больше познаю операционную систему - тем большее удовольствие я получаю. Такой пакет, как MFC (а есть ещё и STL, ATL и т д) позволяет забыть о реализации рутинных задач, перетекающих из проекта в проект - а сосредоточиться на главном , на ТВОРЧЕСТВЕ, то есть... Все стандартные задачи, и графического интерфейса в том числе - уже решены и реализованы. И что немаловажно - хорошо задокументированы. Читайте MSDN - откроете много интересного

Был вопрос - основа основ в Visual C++ . Не смейтесь - основа основ здесь C++ - объекты, классы, конструкторы/деструкторы, виртуальные функции. Весь Windows построен на философии объектов. Каждый объект принадлежит своему классу, с каждым объектом можно работать только строго определённым набором функций (методов). И неуместно спрашивать, почему же не выводится текст в окно CEdit, пока Вы кожей не чувствуете наследование классов, иерархию объектов вашей программы, отличие виртуальной функции от обычной, отличие объекта и указателя на него (это к вопросу Edit1.Text или Edit1->Text) и т. д. и т. п.

И не надо ничего учить наизусть - ставим и читаем MSDN - там - как в Греции - есть всё.

Теперь автору.

В ресурсах рисуете всё, что Вам нужно для GUI. Далее идёте в "Class wizard" - и там создаёте все классы, какие Вам нужны, функции обработки сообщений и действий пользователя и ... собственно всё. ГУИ начинает работать сразу после компиляции. Далее наполняете функции Вашим содержанием по требуемым задачам.

В основном, эти идентификаторы нужны для внутренних нужд системы (они пересылаются между окнами в параметрах сообщений). При идеологически правильном подходе в MFC они вам, скорее всего, не понадобятся, во всяком случае для простых стандартных интерфейсов. Ваш пример.
1) Если Вы создали кнопку IDC_Button1 в ресурсах - заходите в "Класс визард" и определите для этой кнопки функцию, которую вызовет система, если кнопка будет нажата (OnButton1Clicked) - и визард сам в нужном месте услужливо создаст функцию в классе (метод) и покажет, куда вставить свой код для обработки.
2) Если всё же захотелось "достучаться" до объекта по идентификатору, например, установить другой текст кнопки на летy...

Уважаемый Demeny. Я честно очень благодарен Вам за ответ. Вторая половина - то самое. Но. Я же написал, что я прогал долго под билдер. Я отлично знаю идеологию объектной-ориентированности не на словах, а на деле.



Так я и хотел это себе видеть. Так я это видел в билдере. Цитата



Это противоречие Вашим собственным словам и моя проблема на первом этапе пользования вижака. Чтобы достучаться до объекта, который уже создан, я должен зачем-то вызывать какую-то непонятную функцию по идентификатору! С ОО это не имеет ничего общего и с пониманием ОО тоже.

Во вторых, Вы обращали внимание, что среди членов того или иного класса в основном одни только функции (SetWindowText, AddString, и пр.)? Как таковых свойств или полей-переменных нет почти. Я лично не верю, что их нет на самом деле. Почему бы не сделать, например


?

Это конечно может придирки, но мое мнение, что закрытие этих членов, доступ к ним только через функции - долбанутая политика MS по части безопасного кода. От кого их скрывать? От разработчика? А то что их якобы как бы вовсе нет (все реализуется через функции) - я не верю - в таком случае, чтобы сделать банальную перерисовку надо на ежа сесть.



Не все. Почитайте, например, в нем о том как назначить группу RadioButton-у (CRadioButton, если не запамятовал). Я смеялся и плакал.

Я вот тут попробовал на С# чего написать... Вот это то что надо! Все прозрачно и понятно. Мое мнение, что MS наконец-то реализовали то, что в борланде не формально было сделано еще тыщу лет назад. Это модная "компоненто-ориентированность" (наследие ОО). И теперь они это как нечто новое преподносят. ХЗ.

А за вторую часть сообщения спасибо. Если желаете, есть место для дискуссии - в ней того гляди родиться истина.

InvisibleFed,
1. В стандарте C++ нет понятия свойств и событий - это приблуда билдера.
2. MFC по большей части это просто надстройка над API винды. Архитектурные косяки в ней есть, но не сильно мешают.
3. Все, что можно сделать под виндой, можно сделать в VC++, причем достаточно эффективно.
4. То, что вы увидели в редакторе ресурсов - это стандартные виндовские объекты, поддерживаемые на уровне системы, если нужны другие - разрабатывайте свои классы используя в качестве базовых MFC-шные или используйте ActiveX.
5. Если нужен совсем навороченный интерфейс в стиле VS2005 - есть WTL и открытые GUI библиотеки под нее.
6. Ну и наконец, можно перейти на .NET и WindowsForms

В стандарте может и нет, не знаю. Но всем понятно о чем реч ведь так? Речь шла о ПОЛЯХ-ЧЛЕНАХ КЛАССА (по научному еще более я не знаю как). И это не приблуда билдера / не только билдера - вижак ничем не отличается, просто реализовано криво, мое мнение.



Да... эффективнее чем обычный АПИ, согласен.



А чегo такое WTL?
Спасибо.

_http://www.codeproject.com/wtl/#Beginners

_http://www.rsdn.ru/
-- раздел WTL
ну, и
_http://sourceforge.net/projects/wtl
-- собственно, библиотека.

Вещь хорошая для написания небольших программок со стандартным интерфейсом. Минус -- нет упорядоченной и строгой документации. Плюс -- исходники под рукой.

Спасибо.

Никакого противоречия ! Функция GetDlgItem(...) - это тоже метод класса Вашего диалога, из которого Вы её вызываете! Перепишем для ясности

И ещё. Я же писал, что идентификаторами можно и не пользоваться. Заведите себе в классе Вашего диалога кнопку

и общайтесь с ней без всяких идентификаторов

Это вопрос стиля программирования. Мне, например, удобнее заводить идентификаторы для объектов, и если им раздать осмысленные имена - программа становится удобочитаемой...


Вот. Это и есть образ мышления программиста, привыкшего к статическому программированию ! Так было, когда программисты хранили данные в структурах и обращались к ним по имени полей. И опять летят камни в адрес Microsoft ...
На самом деле MS тут ни при чём. Вы затронули один из краеугольных камней ООП, именуемый инкапсуляцией - это не только объединение кода и данных внутри объекта, как думают многие начинающие программеры. Это ещё и разделение интерфейса и реализации объекта (public, protected, private), а также сокрытие реализации, но не от разработчика, а от ошибок. Рассмотрим Ваш пример внимательнее.

Это аварийный код по определению. Объясню почему.
1. Что за поле Text ? Если это указатель на строку, то его содержание будет утеряно, как только будет разрушена константа "My New Button" - и это произойдёт по выходу из локальной функции. Будет ошибка доступа к памяти.
2. Если это объект класса CString, то не надо заниматься самообманом - за оператором присваивания = стоит работа тех же методов класса CString, которые скопируют Вашу константу к себе в "недра".
3. А как Вы узнали при присваивании, что хватит памяти для Вашей строки ?
4. А Вы уверены, что поле Text есть внутри ?

В том то и дело, что прямой доступ к данным внутри объекта всегда чреват разрушением объекта из-за несоответствия данных размерам памяти. И вообще, динамическое программирование подразумевает, что память под данные (возможно, гигантского объёма) выделяется и освобождается динамически, и никогда "снаружи" класса неизвестно, сколько памяти и для чего уже выделено внутри объекта. Об этом "знает" только сам объект и поэтому он сам рулит менеджментом внутри, а снаружи только интерфейс из функций. Так что это не "бага" - это "фича", это надо прочувствовать, прелесть того, что ты не обязан помнить, какой длины массив у тебя, и ты всегда можешь безопасно добавить в него ещё один элемент !!!


Я всегда это делал путём установки галочки прямо в редакторе ресурсов.

Demeny,
здесь
судя по всему подразумевалось "свойство", а не просто переменная-член, так что с точки зрения ООП тут все путем - это просто "сокращенная" форма записи вызова метода , активно используемая сугубо борландовским компилятором, как расширение в C++.
IMHO польза от такого расширения минимальна, зато вред (в плане переносимости) очевиден.

Спасибо, разъяснили.



Спасибо за обстоятельное пояснение.



Понимаю: разработчик - причина ошибок.

Со строковым полем это я конечно загнул - последствия борланда, но с переменными типа int, например, ситуация не лучше. А что касается безопасного кода, это конечно словоблудие, философия, но кто ответит за баг в мое программе, возникающий по причине того, что MS чего-то там намутили? Любая кажущаяся простота упирается как правило в расслабленность программиста. Тем не менее, фичу прочувствовал! Вот только ирония в мозгах возникает (это не про Вас) - многие из тех кто програмят на MFC они еще про динамические структуры дальше указателя на переменную чего-нибудь помнят\знают?



Согласен, так оно и есть.



IMHO в случае написания под конкретный GUI в конкретной среде разработки не о какой переносимости речи вообще не может идти.

Тогда зачем связываться с VC++? Чем билдер не устроил?
Что вы понимаете под "динамической структурой"?

Сам VC вестчь полезная, не спорю. Можно писать очень элегантные проги, многие поймут о чем говорю. На их система справки - кал. По объему - библия программирования для винды, по по удобству работу - кал и еще раз кал. Мне однажды даже пришлось установить Билдер, чтобы работать с их хелпером, который является во многих местах очень удобной копией, причем рабоей копией. А в MSDN я находил дыры - элементарные ссылки, на несуществующие страницы (msdn апрель 2001 года), причем по законам Мерфи эти несуществующие страницы были самыми нужными, а VC6.0 была лицензионной софтиной . Стыдно! А еще добавьте объем их chm-файлов, можно и поудобнее было выбрать. А если попробуете спорить, то вот вам туз из рукава - пункт контекстного меню "Закрыть". Сама Microsoft сделала почти стандартом, что этот пункт последний в меню (кликните правой кнопкой на програмке в панели задачь), а у этих гребаных chm-ов - там хелп (about). И только ни говорите мне, что никто на автопилоте не выбирал этот пункт вместо желанного "Закрыть"

Можно работать так же как и в Билдере. Тока менее удобно получается (писанины больше, ошибок может быть больше, проверок надо больше).

MFC. Допустим, есть ListBox, Button и Edit. По клику на Button берем то что в Edit и добавляем в ListBox (при этом ListBox скроллим вниз доконца).
Обработчик нажатия на кнопку генерится в VS, и код может выглядеть так:


При этом не заводятся переменные, и не нужен этот нанавистный UpdateData(). Собстно, пишу почти все так (без добавленяи каких-либо переменных для рбаоты через DDX). Все отлично работает и ИМХО удобнее, но длинно....

Хелп замечательно сделан. Тока пользоваться надо уметь