Заметки о работе с Microsoft Visual C++ 6.0

Для программного выбора радиокнопки используйте функцию

BOOL CheckRadioButton(
    HWND hDlg,          // handle to dialog box
    int nIDFirstButton, // identifier of first radio button in group
    int nIDLastButton,  // identifier of last radio button in group
    int nIDCheckButton  // identifier of radio button to select
);

Вообще-то, MFC, имеет встроенный механизм обмена данным с группами радиокнопок (кнопок выбора - Radio Buttons). Для того, чтобы им воспользоваться, необходимо для первой кнопки в группе добавить свойство "Group" в диалоге свойств этого элемента управления в редакторе ресурсов. После чего этот элемент появится в списке доступных для обмена данными. Нажимаем Ctrl и делаем двойной щелчок на этой кнопочке. В открывшемся окне "Add Member Variable" задаем имя переменной. Больше задать ничего и не получится, так как там можно задать только имя и только переменную типа int. После этого выбор в группе Radio Buttons определяется значением этой переменной - порядковым номером кнопки в группе, считая с 0.

Однако, при использовании этого механизма в чуть более сложном диалоге я столкнулся с проблемой. Точнее, с "особенностью работы". Дело в том, что я реализовал доступность некоторых кнопок выбора в зависимости от еще одной группы Radio Buttons. При этом появилась возможность возникновения "потерянного выбора" - это когда кнопка в группе выбрана, но недоступна. Пользователь не может изменить состояние такой кнопки - она остается выбранной, даже если выбрана другая, доступная кнопка. И при передаче данных от элементов управления в переменные (DoDataExchange) функция DDX_Radio(...) выбрасывает исключение. Очевидно, что необходимо позаботиться о "правильном выборе" самостоятельно, например, с помощью принудительного программного выбора одной из доступных кнопок посредством функции CheckRadioButton(...).

Если вам необходимо описать набор каких-то значений, используемый для представления нескольких состояний чего-либо и передачи этого в диалог etc., используйте enum в маленьком заголовочном файле типа:

#if !defined(AFD_YOURVALNAME_H__INCLUDED_)
#define AFD_YOURVALNAME_H__INCLUDED_

enum eYourValName
{
    VAL_UNDEFINE = 0,
    VAL_FIRST = 1,
    VAL_SECOND,
    ...
};

#endif // !defined(AFD_YOURVALNAME_H__INCLUDED_)

что позволяет включать его по необходимости куда угодно, не беспокоясь об ошибке переопределения, и использовать единые символические имена на протяжении всего проекта.

Кстати, AFD_... - это просто от названия моей компании. Так MS Visual C++ использует на этом месте AFX_... Позволяет неявно так несколько подчеркнуть авторство.

В процессе разработки программного комплекса, включающего несколько приложений, я столкнулся с проблемой "не работает и все тут!" Правда решение проблемы я нашел довольно быстро: типы объектов представлялись с помощью enum и при добавлении нового типа в середину последоватальности возникло расхожение в значениях второй половины. Вам понятно, что я имею в виду? Решение: либо явно указывать значения перечисления:

enum eYourValName
{
    VAL_UNDEFINE = 0,
    VAL_FIRST = 1,
    VAL_SECOND = 2,
    VAL_THIRD = 3,
    ...
};

enum eYourValName
{
    VAL_UNDEFINE = 0,
    VAL_FIRST,
    VAL_SECOND,
    ...,
    VAL_NEW
};

Для получения немодального диалога можно добавить указатель на необходимый класс в какое-нибудь место, например класс родительского окна, и инициализировать его один раз. Это можно сделать либо в конструкторе родителя, либо в функции, предназначенной для отображения данного диалога. Для отображения вызывается функция Create(), которую для удобства работы необходимо перегрузить. Для повторных вызовов Create вызывать не надо, необходимо использовать ShowWindow(SW_SHOW). Функция вызова этого диалога может быть такой:

void CYourOwner::OnProjectSettings() 
{
    if(m_pDlg == NULL)
    {
        m_pDlg = new CProjectDlg;
        m_pDlg->Create();
    }else
        m_pDlg->ShowWindow(SW_SHOW);
}

При этом на все время существования родителя открывается один диалог. Для каждого экземпляра родителя (или хозяина). Да, и не забудте в деструкторе хозяина удалить указатель на класс диалога.

...
delete m_pDlg;
...

Но вообще-то пожалуй удобнее в конструкторе хозяина инициализировать указатель не NULL, а создавать диалог. Это позволит избавиться от повсеместной проверки наличия отличия указателя от NULL во всех возможных местах использования.

Несколько запутавшись в создании нового окна для вывода параметров модели во время работы программы, я создал диалог, назначил тип рамки Resizing и стиль Overlapped, добавил элемент списка и заставил его отслеживать размеры диалога - список на 8 чего-бы-там-ни-было уже клиентской области диалога. Т.е.:

void COutputDlg::OnSize(UINT nType, int cx, int cy) 
{
    CDialog::OnSize(nType, cx, cy);

    CRect rect;
    GetClientRect(&rect);
    rect.DeflateRect(8, 8);
    m_cListOut.MoveWindow(rect);
}

Здесь я натолкнулся на одну, пока невыясненную мною, ошибку (точнее "глюк"): если оставить у диалога стиль Popup - при первоначальном запуске попытка изменить размеры окна списка выбрасывает исключение, которое тем не менее можно проигнорировать, и в дальнейшем все работает без каких-либо эксцессов.

void COutputDlg::OnSize(UINT nType, int cx, int cy) 
{
    CDialog::OnSize(nType, cx, cy);

    if(m_bInit)
    {
        CRect rect;
        GetClientRect(&rect);
        rect.DeflateRect(8, 8);
        m_cListOut.MoveWindow(rect);
    }
}

В элементе управления MFC (ну и Win32 API соответственно) CListCtrl почему-то нет метода для удаления всех столбов (а может я не нашел?). Есть только метод для удаления одного столбца:

BOOL DeleteColumn( int nCol );

Получая исключения в случаях неудачи удаления, я довольно быстро сообразил, что для удаления всех столбхов необходимо, пока это возможно, удалять столбец номер 0:

while(m_cListOut.DeleteColumn(0));

Странно, что это не реализовано разработчиками, но, наверное, не так часто возникает необходимость удалить все столбцы сразу.

Если предполагается изменение пользователем параметров сколь бы то ни было сложного объекта лучше сразу предположите для этого специальный метод в классе самого объекта. При малейшем расширении программы вы "неожиданно" сталкиваетесь с потребностью вызывать диалог свойств объекта в одной-двух тысячах мест...

Древовидный (иерархический - как кому нравиться) список - удивительно удобное средство для отображения какой-либо структуры! В его реализации в Win32 есть очень полезная вещь: каждый элемент списка имеет в своем составе поле типа DWORD. Естественно, сразу же приходит на ум прописать туда указатель на объект, соответствующий элементу списка на экране.
Кстати в Delphi это работает не менее эффективно (и эффектно)...

Для получения такого элемента управления, как мигающая лампочка-пимпочка, можно воспользоваться тем, что елемент Static позволяет подставлять вместо текста (а может и не только вместо) иконку или битмапчик. Просто меняя иконки функцией SetIcon того же CStatic мы получим возможность динамического отображения режима работы чего-бы-то-ни-было, например, светофора.
А вот для хранения списка иконок или изображений я не придумал ничего лучше, чем организовать масив для ряда хэндлов иконок/битмапов, инициализировать этот массив перед использованием изображений. А надо ли его деинициализовать? Хм...