Цитата(InvisibleFed @ Apr 19 2007, 04:16)
Код
CButton* pMyButton1 = GetDlgItem(IDC_Button1);
pMyButton1->SetWindowText("My New Button");
Это противоречие Вашим собственным словам и моя проблема на первом этапе пользования вижака. Чтобы достучаться до объекта, который уже создан, я должен зачем-то вызывать какую-то непонятную функцию по идентификатору! С ОО это не имеет ничего общего и с пониманием ОО тоже.
Никакого противоречия ! Функция GetDlgItem(...) - это тоже метод класса Вашего диалога, из которого Вы её вызываете! Перепишем для ясности
Код
CButton* pMyButton1 = this->GetDlgItem(IDC_Button1);
pMyButton1->SetWindowText("My New Button");
И ещё. Я же писал, что идентификаторами можно и не пользоваться. Заведите себе в классе Вашего диалога кнопку
Код
CButton MyButton;
и общайтесь с ней без всяких идентификаторов
Код
MyButton.SetWindowText("My first button");
Это вопрос стиля программирования. Мне, например, удобнее заводить идентификаторы для объектов, и если им раздать осмысленные имена - программа становится удобочитаемой...
Цитата(InvisibleFed @ Apr 19 2007, 04:16)
Во вторых, Вы обращали внимание, что среди членов того или иного класса в основном одни только функции (SetWindowText, AddString, и пр.)? Как таковых свойств или полей-переменных нет почти. Я лично не верю, что их нет на самом деле. Почему бы не сделать, например
Код
pMyButton1->Text = "My New Button";
?
Это конечно может придирки, но мое мнение, что закрытие этих членов, доступ к ним только через функции - долбанутая политика MS по части безопасного кода. От кого их скрывать? От разработчика? А то что их якобы как бы вовсе нет (все реализуется через функции) - я не верю - в таком случае, чтобы сделать банальную перерисовку надо на ежа сесть.
Вот. Это и есть образ мышления программиста, привыкшего к
статическому программированию ! Так было, когда программисты хранили данные в структурах и обращались к ним по имени полей. И опять летят камни в адрес Microsoft ...
На самом деле MS тут ни при чём. Вы затронули один из краеугольных камней ООП, именуемый
инкапсуляцией - это не только объединение кода и данных внутри объекта, как думают многие начинающие программеры. Это ещё и разделение интерфейса и реализации объекта (public, protected, private), а также
сокрытие реализации, но не от разработчика, а от ошибок. Рассмотрим Ваш пример внимательнее.
Код
pMyButton1->Text = "My New Button";
Это аварийный код по определению. Объясню почему.
1. Что за поле Text ? Если это указатель на строку, то его содержание будет утеряно, как только будет разрушена константа "My New Button" - и это произойдёт по выходу из локальной функции. Будет ошибка доступа к памяти.
2. Если это объект класса CString, то не надо заниматься самообманом - за оператором присваивания = стоит работа тех же методов класса CString, которые скопируют Вашу константу к себе в "недра".
3. А как Вы узнали при присваивании, что хватит памяти для Вашей строки ?
4. А Вы уверены, что поле Text есть внутри ?
В том то и дело, что прямой доступ к данным внутри объекта всегда чреват разрушением объекта из-за несоответствия данных размерам памяти. И вообще, динамическое программирование подразумевает, что память под данные (возможно, гигантского объёма) выделяется и освобождается
динамически, и никогда "снаружи" класса неизвестно, сколько памяти и для чего уже выделено внутри объекта. Об этом "знает" только сам объект и поэтому он сам рулит менеджментом внутри, а снаружи только интерфейс из функций. Так что это не "бага" - это "фича", это надо прочувствовать, прелесть того, что ты не обязан помнить, какой длины массив у тебя, и ты всегда можешь безопасно добавить в него ещё один элемент !!!
Цитата(InvisibleFed @ Apr 19 2007, 04:16)
Почитайте, например, в нем о том как назначить группу RadioButton-у (CRadioButton, если не запамятовал). Я смеялся и плакал.
Я всегда это делал путём установки галочки прямо в редакторе ресурсов.
Сделано в Китае. Упаковано в России.
Visual C++. Основа основ., Требуется помощь новичку
Apr 16 2007, 12:18
