Visual C++. Основа основ., Требуется помощь новичку Опции

[InvisibleFed]

Начинал программировать под 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(...) - это ваще чё?)

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

[Илья Игоревич]

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

[Demeny]

Мои пять копеек:
если гуй можно реализовать не только на 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 - там - как в Греции - есть всё.

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

1. Основная идеология с практической точки зрения

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

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

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

Код

.........................
CButton* pMyButton1 = GetDlgItem(IDC_Button1);
pMyButton1->SetWindowText("My New Button");
.........................

[shasik]

И что немаловажно - хорошо задокументированы. Читайте MSDN - откроете много интересного...

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