Создать динамически окно(контрол) и привязать к нему обработчик

[Boriska]

Привет форумчане.

Подскажите пожалуйста. МFC.
Контруктор -> Нарисовал окно(контрол) ->Подцепил через визард к переменной -> Прописалось в карте сообщений
или прописал скажем ручками. Тут все понятно.
А вот как если создал окно(контрол) динамически подвязать его к обработчику ?

[Джон]

Аналогично, через однозначный ID, который передаётся в ф-ю Create.

[Boriska]

да, но тут вроде нет входного указателя на функцию обработчик

Код: (C++)

CWnd
virtual BOOL Create(
   LPCTSTR lpszClassName,
   LPCTSTR lpszWindowName,
   DWORD dwStyle,
   Const RECT& rect,
   CWnd* pParentWnd,
   UINT nID,
   CCreateContext* pContext = NULL
);

HWND WINAPI CreateWindow(
  _In_opt_ LPCTSTR   lpClassName,
  _In_opt_ LPCTSTR   lpWindowName,
  _In_     DWORD     dwStyle,
  _In_     int       x,
  _In_     int       y,
  _In_     int       nWidth,
  _In_     int       nHeight,
  _In_opt_ HWND      hWndParent,
  _In_opt_ HMENU     hMenu,
  _In_opt_ HINSTANCE hInstance,
  _In_opt_ LPVOID    lpParam
);

[Джон]

да, но тут вроде нет входного указателя на функцию обработчик

О как! А разве в варианте

->Подцепил через визард к переменной -> Прописалось в карте сообщений ...

он есть?     

Всё работает через карту сообщений. Для этого служит вот это параметр (аргумент)
   ...
   UINT nID,
   ...
, который и является связующим звеном. Поэтому ОООЧЕНЬ важно, чтобы его значение было однозначным для данной формы (диалога).

А дальше используем вариант "или" из

Прописалось в карте сообщений или прописал скажем ручками.

Даже!!! Если это один из стандартных контролов (например CEdit), то можно запросто использовать "родные" ф-ции обработки стандартных сообщений контрола.

что-то типа

дано

#define IDC_MY_EDIT 123
CEdit m_wndMyEdit;
m_wndMyEdit.Create(..., IDC_MY_EDIT, ...);

тогда можно добавить в карту

ON_EN_CHANGE(IDC_MY_EDIT, &CMyDlg::OnEnChangeMyEdit)

void CMyDlg::OnEnChangeMyEdit()
{
   ...
}

[Boriska]

Спасибо. Но Вы наверное не совсем поняли, что я хочу. В ваших объяснениях присутствует

Код: (C++)

#define IDC_MY_EDIT 123
ON_EN_CHANGE(IDC_MY_EDIT, &CMyDlg::OnEnChangeMyEdit)

это предполагает что до этапа компиляции я выберу константы, опять же ручками добавлю
макрос в карту.
А мне хочется накропать нечто вроде редактора. Зашел в режим Add добавил контролы и они должны
быть увязаны на обработчик(и). Потом режим  Add выключил и программа должна будет в следующие
разы запускаться с добавленными контролами. Аналогично и Remove.
Я же в этом случае не могу добавить запись в карту, и не могу константы выбрать.

[darkelf]

Boriska, посмотрите, как это делают, например, Qt или GTK. Оба они позволяют динамически добавлять кнопочки на форму, в смысле программно, хоть 100 штук. И у обоих у них есть редакторы, которые позволяют вообще описывать форму в каком-то формате, сохраняемом в файл, и подгружать её потом из файла динамически.

[Boriska]

Хорошо бы, но с Qt GTK не знаком вообще. А нужно на MFC

[darkelf]

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

[Джон]

Boriska, нуууу как вопрос был задан... Сорри, телепатия на нуле.

ON_EN_CHANGE я привёл в качестве примера стд. контрола. Вы же не уточнили, какие именно контролы вы собираетесь использовать.

нууу начнём с того, что нет под Виндой другого Бога, кроме Win API, а MFC, .NET, ГТК, ОТК, ИТД и иже с ними лишь жалкие оболочки. При этом MFC одна из самых "низких". Таким образом, если что-то и делается "динамически" со стандартными Диалогами и Контролами винды, то это лишь видимость.

Посмотрите, как это делается, например со Списком последних файлов (меню). Точно также резервируются ID, а потом просто некоторые из них используются. И никакого шаманства. А для динамических контролов можно даже задать дипазон ID (ключевое слово RANGE см. в MSDN)

[Boriska]

Да кстати насчет

UINT nID,
, который и является связующим звеном. Поэтому ОООЧЕНЬ важно, чтобы его значение было однозначным для данной формы (диалога).

Лазил в Resource.h какие то нелады были, добавлял при копировании ресурсов какие то ID, так там все ID идут секциями. Секция ID диалогов
секция контролов....и номера просто в порядке увеличения. Я там не видел IDхи чисто одного диалоги, потом другого. Можно по подробнее.

Я так полагаю мне надо разобраться с EnumChildWindows, каким то образом получать(пока не понял) получать HWND дочерних окон ->int WINAPI GetDlgCtrlID(_In_ HWND hwndCtl); добраться до максимального и криэйтить окна с id = max+1 ?

[Boriska]

Вот нашел для поиска id такое решение, проблема не возвращает кода и текста кнопки ОК

Код: (C++)

void func()
{
        CWnd*  pwnd;
        CString  m_str;
        CString  wndtext;
        int          ctrlId;

        pwnd = this->GetWindow(GW_CHILD);
        pwnd->GetWindowText(m_str);


        for (int j = 1; j < this->GetWindowedChildCount(); j++)
        {
                pwnd = pwnd->GetWindow(GW_HWNDNEXT);
                pwnd->GetWindowTextW(wndtext);
                ctrlId = pwnd->GetDlgCtrlID();
                CMessage dlg;
                dlg.m_text.Format( L"Wnd Text = %s ctrlId = %d", wndtext, ctrlId);
                dlg.DoModal();
        };
}

[Boriska]

Победил создание окон. Остались ДрагиДропы.Спасибо за наводки.

Объявил две константы

Код: (C++)

ON_COMMAND_RANGE(DYN_CTRL_ID_MIN, DYN_CTRL_ID_MAX, func

и сделал переменную последнего созданого контрола. Все работает.
Но возник вопрос. Окна у меня в тестовом примере разместились черепицей. И при клике
на окно которое сверху почему то приходит сообщение от окна лежащего в самом низу.

[Джон]

Boriska, дык... Однозначно могу сказать только одно, тестовый пример не выполняет поставленные ему задачи.

[Джон]

Из ЛС.

Бориска, чесслово, ну как тут не заматериться. Как можно помочь исключительно ДОГАДЫВАЯСЬ о том ЧТО и КАК сделано? И, если на первое сообщение ещё можно было хоть как-то дать общие советы, то теперь... Сорри, но не видя ЧТО и КАК сделано... А телепатия по такой жаре на нуле.
 

Жара. Сижу на даче
Ну короче я пошел по такому пути

Код: (C++)

#define         DYN_CTRL_ID_MIN                 5000
#define         DYN_CTRL_ID_MAX                 5500

ON_COMMAND_RANGE(DYN_CTRL_ID_MIN, DYN_CTRL_ID_MAX, &CDynWndCreateDlg::OnClickDynamicWnd)

// в инит диалоге
        m_currCtrlID = DYN_CTRL_ID_MIN;
        m_rect = CRect(5, 5, 140, 140);
        m_bmNormalTank.LoadBitmap(IDB_N_TANK);
        m_ctrlVec = GetCtrlsAllocs(L"MyWnd"); // беру из базы расположения

//добавляю окна-контролы так
BOOL CDynWndCreateDlg::AddNewControl()
{
        CWnd *pWnd = NULL;
        pWnd = new CStatic();
        BOOL result = FALSE;

        if (m_currCtrlID < DYN_CTRL_ID_MAX)
        {
                pWnd->Create(L"Static", L"Tank", WS_BORDER | WS_CHILD | WS_VISIBLE |    SS_BITMAP | SS_NOTIFY,
                        m_rect, this, m_currCtrlID);

                ((CStatic*)(pWnd))->SetBitmap(m_bmNormalTank);
                CCtrlParams pnt(m_rect);
                AddControl(L"Tank", m_currCtrlID, pnt);
                m_currCtrlID++;

                m_rect.left += 20;
                m_rect.top += 20;
                m_rect.right += 200;
                m_rect.bottom += 20;

                result = TRUE;
        }
       
        return result;
}

//смотрю на клик вот так

void CDynWndCreateDlg::OnClickDynamicWnd(UINT nID)
{
        CMessage dlg;
        CString text;
        GetDlgItem(nID)->GetWindowText(text);
        dlg.m_text.Format(L"Wnd Text = %s ctrlId = %d", text, nID);
        dlg.DoModal();
}
 

+ Я так понимаю, Вы начинающий в MFC, поэтому почитайте перевод статьи Блуждания по лабиринту маршрутизации сообщений и команд в MFC на RSDN

+ Всё-таки, наверное, придётся описать словами, что Вы хотите получить, ибо, сорри, но приведённые обрывки исходников этого не демонстрируют.

+ к предыдущему пункту, какие именно сообщения Вы собираетесь отлавливать, или что должен делать контрол по клику?

[Boriska]

+ Всё-таки, наверное, придётся описать словами, что Вы хотите получить, ибо, сорри, но приведённые обрывки исходников этого не демонстрируют.

Хочу сделать чтобы у программы был режим Edit. Войдя в него можно бы было создать окно, указать его параметры, оттянуть в нужную позицию и сохранить параметры в базе. При рестарте программа должна вывести окна по списку из
базы.

к предыдущему пункту, какие именно сообщения Вы собираетесь отлавливать, или что должен делать контрол по клику?

Ну в режиме работы я полагаю должен ловить левый клик, а режиме редактирования по идее (button down, button up,
ну и наверное move)

Блуждания читал как-то, но понял далеко не все, попробую еще.

Добавлено через 13 часов, 32 минуты и 4 секунды:
Вот что у меня получается.

Создаю по кнопке и и при перезапуске приложения восстанавливаю из базы.
Но остался вопрос с сообщением от перекрывающихся окон. Если они не перекрываются то все по клику
на каждом окне получаю то, что ожидал - те сообщение с его ID, а если перекрываются получаю ID
самого нижнего окна.

[Джон]

Да вроде всё нормально работает.

[Boriska]

А кде кликаете ?
Если я кликаю в красной области то получу сообщение что кликнул
на wnd id =5000
Если на зеленых областях то получу Id того окна на котором кликнул
Если на синей области то получуу Id = 5004 | 5005 | 5006 в зависимости
от того места области где кликну

[Джон]

Ну и что тут удивительного? Всё абсолютно правильно и логично. Существует определённый порядок распложения окон (т.н. Z-Order). Изначально это порядок создания окон. В Вашем случае это:

5000
5001
5002
5003
5004
5005
5006
5007

Когда Вы кликаете ГДЕ-ТО на форме, производится поиск окна, в прямоугольной области которого был произведён клик (т.н. HitTest).
Ессно, что первым откликается окно, находящееся в начале списка. Например, для синей области это 5004 5005 5006 и только совсем немного внизу 5007.

Отрисовка окон производится в этом же порядке, поэтому следующее окно находится поверх предыдущего.

[Boriska]

То бишь ловить через ON_COMMAND_RANGE не выйдет ? так как он не учитывает Z порядок
и возвращает ID первого в списке окна ?

Дочитался до PreTranslateMessage. Там возвращается структура сообщения. Но как по ней
определить кого таки кликнули не понял.(ну в смысле если они перекрываются).

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

Джон а где мона толково это почитать?

[Джон]

То бишь ловить через ON_COMMAND_RANGE не выйдет ? так как он не учитывает Z порядок
и возвращает ID первого в списке окна ?

Нет, ON_COMMAND_RANGE остаётся как есть. Этот обработчик отлавливает сообщения независимо от порядка их отправителей. Если от него отказаться, то надо будет изначально внести в карту N ON_COMMAND, где N - максимально разрешённое количество окон. В Вашем случае исходя из

Код: (C++)

#define         DYN_CTRL_ID_MIN                 5000
#define         DYN_CTRL_ID_MAX                 5500

N=501. Хотите?

По этим же соображениям PreTranslateMessage тоже не поможет.

Кстати эксперимент показал что так работают все контролы когда они перекрыты.

(см. ниже)

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

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

Джон а где мона толково это почитать?

Про что про "ЭТО"? Создание алгоритмов? Здесь проблема не системы, а архитектуры, рабочей модели. Т.е. сначала она решается с помощью нарезаных бумажек и пальца.

[Boriska]

Привет

Про что про "ЭТО"?

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

вот наваял, возвращает ID (нужного(верхнего)"правильного") кликнутого контрола.

int CWndHitTest::GetControlID(POINT scrPntClck)
{
   CWnd*   pWnd;
   CRect   wndrect;

   std::vector <HWND> wndsVect;

   HWND      hWnd = ::WindowFromPoint(scrPntClck);
   while (hWnd)
   {
      pWnd = CWnd::FromHandle(hWnd);
      pWnd->GetWindowRect(wndrect);

      if (wndrect.PtInRect(scrPntClck))
      wndsVect.push_back(hWnd);

      hWnd = ::GetWindow(hWnd, GW_HWNDNEXT);
   }

   if (wndsVect.empty())
      return 0;

   hWnd = wndsVect[wndsVect.size()-1];
   
   pWnd = CWnd::FromHandle(hWnd);
   return pWnd->GetDlgCtrlID();
}

[Джон]

статья про блуждание - это же так, отсебятина ,

Хм... даже как-то раньше не задумывался... "Но если так, без умиления взглянуть" (с), а не всё ли в этом мире "отсебятина"? Лично мне, в своё время, отсебятины корифеев, как например Paul DiLascia, очень помогли. Но Вы абсолютно правы, отсебятина остаётся отсебятиной, поэтому в этом случае могу порекомендовать справочник MSDN. Говорят, там есть АБСОЛЮТНО ВСЁ.

[Boriska]

Привет.

  Ну лады. Про отсебятину наверное перебор. Просто считаю, любая подаваемая информация информация, что бы принята была, необходимо обеспечить условия с двух сторон. Представьте ситуацию, Microsoft выпускает библиотеку, MSDN и подобную статью. И на завтра все создают супер-пупер приложения. Не получиться.
  Или они библиотеку для себя сделали?, а мы смертные, должны как куры сорные, рыться в поисках обломков кода в этой мусорке по прозвищу Сеть. (вот кстати про то, что сообщения будут пролетать через стопку окон, в этой статье от Paul DiLascia не заметил)

Джон вы как-то обмолвились

Поэтому ОООЧЕНЬ важно, чтобы его значение было однозначным для данной формы (диалога).

Можете это прокомментировать? Мы когда перетягиваем элементы с тулбара на диалоги, система(studio) просто присваивает ему ++ID и кладет по порядку в (я так понял) секцию контролов (IDC_xx). И нет там вроде никаких IDC_for somebody.

Это типа если у меня какой то диалог создает на других диалогах элементы(окна), то мне следить за последним(наибольшим?) номером созданного элементы(окна) для каждого диалога ?

[Джон]

Или они библиотеку для себя сделали?, а мы смертные, должны как куры сорные, рыться в поисках обломков кода в этой мусорке по прозвищу Сеть.

Ну так в этом аспекте особенно ценны "отсебятины" людей (типа Paul DiLascia), которые уже "порылись", разобрались в чём-то, понаступали на грабли, потом результаты (опыт) разжевали и положили в "рот".

Джон вы как-то обмолвились

Поэтому ОООЧЕНЬ важно, чтобы его значение было однозначным для данной формы (диалога).

Можете это прокомментировать? Мы когда перетягиваем элементы с тулбара на диалоги, система(studio) просто присваивает ему ++ID и кладет по порядку в (я так понял) секцию контролов (IDC_xx). И нет там вроде никаких IDC_for somebody.

Проблема заключается в том, что наличие на одной форме (диалог) контролов с одинковыми ID недопустимо, ибо именно через них осуществляется доступ к этому самому контролу.

Это типа если у меня какой то диалог создает на других диалогах элементы(окна), то мне следить за последним(наибольшим?) номером созданного элементы(окна) для каждого диалога ?

Вы можете посмотреть в файле resource.h, как этим, например, управляет редактор ресурсов Студии. Там в самом низу есть такой (или похожий, зависит от версии Студии) блок:

Код: (C++)

// Next default values for new objects
//
#ifdef APSTUDIO_INVOKED
#ifndef APSTUDIO_READONLY_SYMBOLS
#define _APS_NEXT_RESOURCE_VALUE        958
#define _APS_NEXT_COMMAND_VALUE         33801
#define _APS_NEXT_CONTROL_VALUE         1964
#define _APS_NEXT_SYMED_VALUE           117
#endif

В Вашем случае, когда АБСОЛЮТНО ВСЕ (если я правильно понял) элементы будут создаваться динамически, Вы можете сами взять на себя управление След. Свободным ID (например Ваше ++ID). Если же некоторые контролы присутствуют изначально (были созданы в редакторе Студии), то вы можете зарезервировать диапазон "с запасом" и лежащий "далеко" за пределами, например, _APS_NEXT_CONTROL_VALUE.

Ещё раз, речь об уникальности идёт только в пределах одной формы (родителя).

[Boriska]

Привет.

Тык. Окна создаю, клики обрабатываю вроде все получилось (спсб). Теперь надо поместить на окно битмапу.
Добавил красным.

Не фурычит. SetBitmap возвращает 0, битмапа вернула 1 -> удачно загрузилась. Полный код.

BOOL CWndControl::AddNewControl(CWnd* pParentWnd, int ctrlMaxID, CCtrlParams ctrlParams)
{
   CWnd *pWnd = NULL;
   pWnd = new CStatic();
   BOOL result = FALSE;
   CBitmap bmp;
   bmp.LoadBitmap(ctrlParams.GetCtrlId());

   if (ctrlParams.GetCtrlId() < ctrlMaxID)
   {
      result = pWnd->Create(
         ctrlParams.GetCtrlClass(),
         ctrlParams.GetCtrlCaption(),
         WS_BORDER | WS_CAPTION | WS_VISIBLE | SS_BITMAP | SS_CENTERIMAGE | SS_NOTIFY,
         ctrlParams.GetCtrlRect(),
         pParentWnd,
         ctrlParams.GetCtrlId()
         );

      ((CStatic*)(pWnd))->SetBitmap(bmp);
   }
   return result;
}

[Джон]

Ну начнём с того, что Вы хотите сделать? Чтобы на контроле ВСЁ время его существования показывалась картинка?

[Boriska]

Я не совсем понял, что значит ВСЕ и НЕ ВСЕ время. Ну как я понимаю битмап должен показываться то время пока окно видно.
О кажись потусторонние силы подсказывают, что битмап по выходу из функции разрушается, ток рационального объяснения для себя не нахожу зачем ему существовать после того как приатачили.

[darkelf]

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

Ну, например в функции SetBitmap(), не делают полную копию объекта CBitmat, а записывают ссылку на него, или, например HANDLE какого-то системного объекта. Соответственно после выхода из Вашей функции, этот внутренний указатель или HANDLE указывает в никуда, т.к. вызвался деструктор, который освободил память или закрыл HANDLE. Если Вам надо создавать его динамически - ну и создайте его через new в куче, а не как сейчас, на стеке.

А почему так может быть - думаю, когда разрабатывали WinAPI и MFC, память была не таким дешевым ресурсом как сейчас, и её пытались экономить.

[Джон]

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

И это очень хорошо. 

ток рационального объяснения для себя не нахожу зачем ему существовать после того как приатачили.

А вот это плохо. 
Матчасть учить таки придётся. Какой параметр получает SetBitmap? Что такое HBITMAP? Ну а дальше всё просто.

например HANDLE какого-то системного объекта.

Почти угадал. Только не какого-то системного объекта, а именно HANDLE  этого битмапа.

[Boriska]

Привет

Матчасть учить таки придётся. Какой параметр получает SetBitmap? Что такое HBITMAP? Ну а дальше всё просто.

Матчасть бы лучше понимать, тогда учить не приходится  Мои знания конечно ну очень далеки от .....Ну насколько знаю HANDLE - адрес на объект создаваемый в системе обычно какой нибудь функцией типа CreateXXX. HBITMAP - полагаю особым от него не отличается, только и того чтобы для проверки типа (чтобы левый хэндл туда не совали).
Согласно msdn SetBitmap принимает хэндл, а я туда сунул CBitmap - интересно че это он не заругался?
Но если бы каким то образом добыл хэндл (каким?), то все одно хэндл умер бы согласно этого кода, так ?

[Джон]

Матчасть бы лучше понимать, тогда учить не приходится 

Это словоблудие, и в качестве отмазки не принимается. Как интересно придёт понмание без изучения? Хотя конечно, если Вам открыт доступ к Высшему Информационному Уровню, то ...

В противном случае, начинать надо с Win API. Что такое хэндлы и для чего они нужны. Для этого (и не только для этого) есть замечательная книжка Петцольда.

Согласно msdn SetBitmap принимает хэндл, а я туда сунул CBitmap - интересно че это он не заругался?
Но если бы каким то образом добыл хэндл (каким?), то все одно хэндл умер бы согласно этого кода, так ?

А всё потому... ладно, в последний раз, больше пересказывать теорию не буду. Опять же, "отcебятина".

CBitmap - класс MFC, который является "обёрткой" (немножко ООП) для Win API. Другими словами, в Win API есть ф-ции, которым необходимы хэндлы. MFC прячет эти хэндлы внутри своих объектов и наделяет их (объекты) операторами приведения к необходимому типу. Вот и у CBitmap есть оператор приведения к типу HBITMAP. Сдепано это для удобства работы с native Win API функциями.

[Boriska]

Привет

есть замечательная книжка Петцольда.

Эти ? Петцольд Ч. Программирование для Windows 95. Том 1,2
Брал в руки. Насколько помню там про на АРI(по оглавлению), а тогда нужно было на MFC. На API,МFC у нас не писал никто. спрашивать бесполезно. Толковой литературы про то как устроена "обвертка" не нашел. Ну и ограничился дизайнером - т.е. простейшим. Только вот как по Петцольду MFC разбирать ?

и наделяет их (объекты) операторами приведения к необходимому типу

Про операторы читал, про перегруженные тоже, про операторы приведения не слышал.

Можно пару слов про мое "понятие HANDLE и его отличие от HBITMAP"

HANDLE - адрес на объект создаваемый в системе.....

Соответствует положению дел ?

[darkelf]

Boriska если Вам интересно, и Вы хотите разобраться как всё устроено - Вы можете даже без чтения книг просто посмотреть заголовочные файлы системы:

- посмотрите заголовочные файлы MFC (в данном случае afxwin.h), там, Вы сможете увидеть, что у CStatic есть:

Код: (C++)

        HBITMAP SetBitmap(HBITMAP hBitmap);

далее у CBitmap есть:

Код: (C++)

        operator HBITMAP() const;

ну и наконец, уже в WinAPI, в файле windef.h:

Код: (C)

DECLARE_HANDLE(HBITMAP);

и в файле windef.h

Код: (C)

#define DECLARE_HANDLE(name) typedef HANDLE name

[Джон]

Только вот как по Петцольду MFC разбирать ?

Даааа? Ну в таком случае надо сначала ответить на вопрос, а что же такое MFC? Если следовать Правилам (п.3.8), которые Вы кончно же прочитали и приняли, и воспользоваться Поиском, то можно найти темы, в которых про это уже говорилось.

и наделяет их (объекты) операторами приведения к необходимому типу

Про операторы читал, про перегруженные тоже, про операторы приведения не слышал.

И как тут помочь?  

Можно пару слов про мое "понятие HANDLE и его отличие от HBITMAP"

HANDLE - адрес на объект создаваемый в системе.....

Соответствует положению дел ?

А что говорит Петцольд по этому поводу? (небольшая подсказка HANDLE в MFC тоже самое что и в Win API, так что поняв, что это такое в Win API, разберётесь и с MFC)

[Boriska]

и наделяет их (объекты) операторами приведения к необходимому типу
Про операторы читал, про перегруженные тоже, про операторы приведения не слышал.
И как тут помочь?  А черт его знает...

Как оператор преобразования там вызывается? Он же вызывается от объекта - типа a(b). А в нашем случае
HBITMAP SetBitmap(HBITMAP hBitmap); тут из объекта скобки не вызываются.

[Джон]

Как оператор преобразования там вызывается? Он же вызывается от объекта - типа a(b). А в нашем случае
HBITMAP SetBitmap(HBITMAP hBitmap); тут из объекта скобки не вызываются.

Из какого объекта? Из CBitmap? Почему не вызываются? Вам же уже даже код показали, как это в данном случае работает.

далее у CBitmap есть:

Код: (C++)

        operator HBITMAP() const;

[Boriska]

далее у CBitmap есть:
Код: (C++)
        operator HBITMAP() const;

Джон я по литературе знаком с
operator+()
operator=()
operator++()
operator++(int)
operator()(int a, float b)
.....
для понимания того, что вы пытаетесь объяснить по теме, объясните пожалуйста, что за зверь operator HBITMAP() const;
Оператор мы же вызываем из объекта слева от оператора.
A+B - тут все понятно, из объкта A вызывается оператор+ ему передается B.
A*B аналогично
Это чет не понятная конструкция какая то получается "obHBITMAP"

[Джон]

Boriska, а Вы лентяй, батенька.

Что значит "по литературе"? По какой литературе? Если в ней нет про операторы приведения типа?

Ок, давайте забудем про HBITMAP-ы.

Попытайтесь найти решение в след. ситуации.

Допустим у Вас есть объект, единственное поле данных которого есть целочисленный тип (int). Например

Код: (C++)

class CMyInt
{
public:
        CMyInt() { m_nMyInt = 0; }
        CMyInt(int nVal) { m_nMyInt = nVal; }
        CMyInt(const CMyInt& mi) { m_nMyInt = mi.m_nMyInt; }

private:
        int m_nMyInt;
};

Имеется набор неких ф-ций

Код: (C++)

void func1(CMyInt nVal){}

void func2(int nVal){}

void func3(double dVal){}

необходимо передать экземпляр объекта CMyInt в каждую из этих ф-ций

Код: (C++)

int main()
{
        CMyInt mi(12);

        func1(mi);
        func2(mi);  //<--- error C2664: 'func2' : cannot convert parameter 1 from 'CMyInt' to 'int'
        func3(mi);  //<--- error C2664: 'func3' : cannot convert parameter 1 from 'CMyInt' to 'double'

        return 0;
}

При вызове func1 всё в порядке, в двух остальных случаях не удаётся даже скомпилировать.

Как быть?

ps Подсказка - смотрите окошко Output в режиме Build в Студии. Если по каким-либо причинам его нет, или сообщение не покажется, то вот что "говорит" моя 2012-я в дополнение к этим ошибкам:

No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called

[Boriska]

Не уверен, что я лентяй. Скорее Шилдт отстой. Мой первый бук. Он написал,
есть operator#(), и привел примеры. Примера с преобразованием
типа нет, значит нет. Все, даже намеков, что может быть иначе нет.
Кстати все, что доступно почитать, или так скажем попадалось почитать
не выходит за эти рамки. (На полку худ. литературы.) А эта тема вынесена
в "Определенные пользователем преобразования" и не везде она есть.

Все. Пойду бороть битмап в окне.

[Джон]

Не уверен, что я лентяй. Скорее Шилдт отстой.

Неа, отмазка не канает. Ограничиваться только одной книгой... А что насчёт Страуструпа? Всё-таки родитель С++. Кому как ни ему?
Если уж на то пошло, то самому разбраться? Совсем несложно.

Ладно, раз уж я сказал "А", буду говорить и "Б".

Итак, что такое преобразование типов? Т.н. cast? Это Вы знаете. Про перегрузку операторов тоже. Больше ничего не потребуется.
Оператор определяется ключевым словом и именем, которое по сути может быть любым. Компилятору только нужно его однозначно идентифицировать. По сути, оператор это ф-я. Например, можно определить след. равноправные по функциональности конструкции

Код: (C++)

CMyInt& operator+=(const CMyInt& mo)
{
   m_nMyInt += mo.m_nMyInt;
   return *this;
}

CMyInt& AddMyInt(const CMyInt& mo)
{
   m_nMyInt += mo.m_nMyInt;
   return *this;
}

и соответственно вызов

Код: (C++)

        CMyInt mi(12);
        CMyInt mi2(12);

        mi+=mi2;
     // или      
        mi.AddMyInt(mi2);

произведет одинаковые изменения объекта. Разница только в именах "ф-ций". Т.е. по идее можно было бы определить ф-ю и так

Код: (C++)

CMyInt& +=(const CMyInt& mo)
{
   m_nMyInt += mo.m_nMyInt;
   return *this;
}

и вызывать что-то типа

Код: (C++)

mi.+=(mi2);

Но к сожалению  (или к счастью?) "+=" уже зарезервировано в С++. Ключевое слово operator позволяет "обойти" это ограничение и переопределить (точнее перегрузить, вспомните про перегрузку ф-ций) существующие функции.

Для переопределения типа, тоже можно создать ф-цию. Для примера выше, это могут быть

Код: (C++)

int CastToInt() { return m_nMyInt; }
double CastToDouble() { return (double)m_nMyInt; }

соответственно вызов

Код: (C++)

func2(mi.CastToInt());
func3(mi.CastToDouble());

Но в этом случае, необходимо явно указывать нужную ф-ю при каждом конкретном обращении к объекту. Конечно, можно обойтись и одной ф-ей, возвращающей только int

Код: (C++)

func3(mi.CastToInt());

но эти применимо только к числовым операциям. Например с CString это не будет работать

Код: (C++)

void func4(CString st) {}
...
func4(mi.CastToInt());

да и при неблагоприятном выборе ф-ции компилятор будет возмущаться (допустим мы сделели только CastToDouble).

Код: (C++)

func2(mi.CastToDouble()); // -> warning C4244: 'argument' : conversion from 'double' to 'int', possible loss of data

Вот тут и приходит на помощь оператор приведения типа. Итак, ф-я у нас выглядит след образом

Код: (C++)

int CastToInt() { return m_nMyInt; }

Т.е. вызывающий ожидает возвращаемый объектом тип int. Те над объектом совершается некоторя операция, результатом которой является значение целого типа. Это можно записать след образом

Код: (C++)

operator int()  { return m_nMyInt; }

соответственно для double

Код: (C++)

operator double() { return (double)m_nMyInt; }

Код: (C++)

operator CString()
{
        CString stRet;
        stRet.Format(L"%d", m_nMyInt);
        return stRet;
}

etc.

Теперь можно смело вызывать любую ф-ю

Код: (C++)

func1(mi);
func2(mi);
func3(mi);
func4(mi);

Аналогично оператор класса CBitmap возвращает сохранённый в нём HBITMAP. Вот и всё.

Удачи. И... учите матчасть.

[Boriska]

Спсб за доп. разъяснения. Нашел у Липмана.
гл 15. Перегруженные операторы и определенные пользователем преобразования
    15.9. Определенные пользователем преобразования
Понял так. Если имеем допустим бинарную операцию над двумя разными объектами, сначала выполнится
оператор приведения типа, ( вернет бинарному оператору то, что там по правилу указано в операторе
приведения типа), а затем будет выполнен бинарный оператор.
(Липмана читал по пути на работу, но видать или не догнал или пропустил )



Добавлено через 47 минут и 21 секунду:
Да и по ходу освоения материала, решил его применить. И застрял.
У меня из базы Id объекта можно получить перегруженой функцией (по году, и по имени)

Код: (C++)

int GetCarId(CString);
int GetCarId(int);

Если я теперь сделаю в объекте два оператора

Код: (C++)

class Car{
public:
   operator CString () {return name;}
   operator int(){return year;}
private:
   CString name;
   int year;
}

то какая же функция будет вызвана?

......
Car a(...params...);
db.GetCarId(a);

Пришлось

Код: (C++)

operator CString () {return name;}

убрать ввиду неоднозначности.

[Джон]

Совершенно верно, именно в этом случае будет создана неопределённость, поскольку есть уже перегруженные ф-ции для обоих типов. Но это уже проблема архитектуры программы, а не языка C++.

Почему есть две ф-ции? Они ориентируются на доступные данные: есть либо год, либо имя?

Тогда лучше сделать ф-ю

Код: (C++)

int GetCarId(Car a);
//или
int GetCarId(Car* p); // если лень возиться с конструкторами копирования

которая сама найдёт нужные данные

Если же они возвращают данные ТОЛЬКО для года, или ТОЛЬКО для имени, то в этом случае лучше давать разные имена

Код: (C++)

int GetCarIdByName(CString);
int GetCarIdByYear(int);

Тогда можно оставить оператор приведения к CString и юзать

Код: (C++)

Car a(...params...);
db.GetCarIdByName(a);
//...
db.GetCarIdByYear(a);

[RXL]

...

Код: (C++)

int GetCarId(CString);
int GetCarId(int);

Если я теперь сделаю в объекте два оператора

Код: (C++)

class Car{
public:
   operator CString () {return name;}
   operator int(){return year;}
private:
   CString name;
   int year;
}

...

Код: (C++)

db.GetCarId(a);

...
Пришлось

Код: (C++)

operator CString () {return name;}

убрать ввиду неоднозначности.

Указать явно:

Код: (C++)

db.GetCarId((int)a);

или:

Код: (C++)

db.GetCarId(int(a));

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

Но если нет особой нужды, то лучше явные методы. Только я бы сделал краткие:

Код: (C++)

class Car{
public:
   CString name() const { return _name; }
   int year() const { return _year; }
private:
   CString _name;
   int _year;
}

[Boriska]

Привет

Поехали дальше. Окна динамически научили(спсб), менять размер и позицию - разобрался, битмапу в эти окна вставляю(спсб). Петцольда читаем 
Можно ли битмап не просто вставить, а растянуть(подогнать) по размеру окна?
А как быть с другими типами картинок ? Порылся. Есть CImage. Тудой грузим картинку, а потом пользуем CImage::operator HBITMAP  если надо вставить картинку на кнопку или еще куда ?

[Джон]

Можно ли битмап не просто вставить, а растянуть(подогнать) по размеру окна?

См ф-ю BitBlt
 

А как быть с другими типами картинок?

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

[Boriska]

Дискутировал тут на работе. Пришел к выводу на основании

Других типов картинок не бывает,

, что картинки разные бывают, но отличаются на уровне файла, когда там воз и тележка доп. информации, а когда картинка
в винде, то она любая приведена к Bitmap.

Здесь я с логикой не пострадал ?

Есть CImage. Тудой грузим картинку, а потом пользуем CImage::operator HBITMAP  если надо вставить картинку на кнопку или еще куда

[Джон]

Дискутировал тут на работе. Пришел к выводу ...

А можно было просто дочитать предложение до конца.

[Boriska]

Дак прочитал. И оно (предложение) поселило сомнение, что даже новомодный .net
умеет работать с другими типами картинок. Подумав
просто перефразировал твою мысль, вспомнив

под Виндой другого Бога, кроме Win API, а MFC, .NET, ГТК, ОТК, ИТД и иже с ними лишь жалкие оболочки.

Иными словами хотел сказать "преобразуют к bmp и отдают винде (а там другого не бывает)."

[Aether]

Не к bmp, а к Bitmap.
bmp, jpg... - форматы файлов, которые могут хранить некие сжатые или не сжатые данные. На основании расширения файла (и его заголовка) ему сопоставляется определённый алгоритм расшифровки, оформленный, как программный модуль - кодек - функция... Этот модуль преобразует содержимое файла в массив точек, который и есть Bitmap (и который от системы зависеть не будет - одинаков, как для Windows, так и для всего остального), плюс описательную структуру (которая у разных систем может отличаться).

[Boriska]

Не к bmp, а к Bitmap.

Ну и я же про енто, ну наблал 3 символа вместо 6

Добавлено через 2 дня, 14 часов, 54 минуты и 32 секунды:

Можно ли битмап не просто вставить, а растянуть(подогнать) по размеру окна?

См ф-ю BitBlt

Не могу понять как это сделать. Ну как в доке написано

The BitBlt function performs a bit-block transfer of the color data corresponding to a rectangle of pixels from the specified source device context into a destination device context.

Те по идее она копирует с одного ректангла в другой. По идее можно сделать CompatibleDC - оттуда как с ректангла в памяти скопировать скажем в ректангл кнопки. Но среди кодов операций нет операции растяжения.

Добавлено через 1 день, 14 часов, 42 минуты и 48 секунд:
Вот тут в Петцольде дошел до описаня контекста устройства (приведены атрибуты).
Один из атрибутов Strething mode - может через него, тем более, что название значения по умолчанию BLACKONWHITE я встречал когда читал документацию по BitBlt

[SI]

Можно ли битмап не просто вставить, а растянуть(подогнать) по размеру окна?

[

 Посмотри функции:
 ::SetStretchBltMode(...)
 ::StretchBlt(...)

[Boriska]

С окном на окне разобрался. Сделал. Теперь хочется сделать по настоящему контрол, который бы висел
в тулбаре и его можно бы было перетаскивать на окно и обращаться в программе как к объекту. пожалуйста если
кто знает как это на mfc делается? на С# делал - там мастер есть, создать элемент управлени....