Важный вопрос насчет окон Windows

[HWork]

я зарегестрировал свой класс окна. При создании самого окна в сообщении WM_CREATE я могу создать какие либо данные, соответственно (например с помощью оператора new). Оператор new вернет указатель.
Суть вопроса: как мне привязать этот указатель к окну без хранения этого указателя в глобальной переменной. Также чтобы при создании еще одного такогоже окна создавалить данные для этого окна. И соответсвенно при уничтожении любого из этих окон уничтожались данные только уничтожаемого окна.

P.S. Чтобы было понятнее что я подразумеваю - При создании стандартных окон в Windows (например SysListView) возвращается только хендл окна. Создать их можно сколько угодно и у всех будут свои данные: ImageList, списки и т.д.

[pu4koff]

Как вариант: SetWindowLong с параметром GWL_USER или GWL_USERDATA. Я не помню просто уже чем они отличаются

[Stilet]

Ну вот попробуй поступи так - сделай класс окна, в котором будет скажем некий динмассив указателей. Далее при "добавлении" обьекта на окно, вписывай его в массив этот. А в конце проходи по массиву и освобождай приписанное в нем. Как правило это делается в обертках из классов.

[HWork]

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

[Stilet]

проблема в том что юзер сможет получить доступ к этим данным

Это еще с какого перепуга?

можно, но нужен другой способ.

Чем этот не угодил?

[HWork]

Если я что-то передам через SetWindowLong, я смогу это получить через GetWindowLong.
Массив неустраивает из-за постоянной проверки.
Если например 100 окон, постоянно проверять массив при кажном обращении. Я намерен использовать эти данные в таких сообщениях как: WM_MOUSEMOVE, WM_PAINT, и т.д. А теперь представь если я провожу мышко по окну слева на право, окну посылается около 200 сообщений - 200 * 100 = 20000, и еще добавь сообщения прорисовки - смело на 100 умножаем, конечно можно подумать и сделать это все быстрее. Так что это крайний способ который я буду использовать.

Мне бы как в стандартых окнах, например окно класса "LISTBOX" где-то же хранит свой список (у каждого окна свой). И при этом хранить можно только хендл окна, а данные получать и назначать через сообщения.

Надеюсь теперь меня поняли.

[Stilet]

если я провожу мышко по окну слева на право, окну посылается около 200 сообщений

Ну и что? Я не пойму что за данные ты хочешь прикреплять к окну то?

[pu4koff]

Сообщение от Stilet

Ну и что? Я не пойму что за данные ты хочешь прикреплять к окну то?

Ну тот же ListBox должен хранить массив строк, TreeView - иерархию элементов и т.д. Только мне что-то тоже никак в голову не прийдет как это дело лучше всего хранить...

[Stilet]

Ну тот же ListBox должен хранить массив строк

Ну он так и делает, я одного не пойму с чего автор взял что массивы будут ему обузой?

[pu4koff]

Сообщение от Stilet

Ну он так и делает, я одного не пойму с чего автор взял что массивы будут ему обузой?

Ну если много контролов этого класса создавать, то поиск по массиву будет не самый шустрый. Опять же удалять контрол из начала/середины массива не есть хорошо.
В общем я бы сделал примерно так:
Создал класс окна, где всё что надо реализовал. Добавил к этому классу статическую функцию типа WinProc для обработки сообщений.

class MyControl
{
static LRESULT CALLBACK WinProc (...);
};

LRESULT CALLBACK MyControl::WinProc (...)
{
  switch (...)
  {
  case WM_CREATE:
    MyControl *new_control = new MyControl(...); // Создание нового объекта
    // Привязка объекта к хэндлу окна
    ...
    break;
  case WM_DESTROY:
    // Поиск соответствующего объекта по хэндлу окна
    ...
    delete obj; // Удаление объекта
    break;
  }
}

Остаётся проблема с сопоставлением: хендл <-> объект
Я вижу тут 3 вариант:
1. SetWindowLong. Проблема - опасность вмешивания пользователя. Кто знает чего туда передадут
2. Можно попробовать использовать функцию SetProp. Опасность та же, что и в пункте 1, но шансы на порчу данных меньше.
3. Завести, например, std::map<HWND, MyControl*>. В минусах может быть скорость, но еще не факт. Кто знает как в самой винде это дело хранится. Зато никто ничего не запортит так просто и не вмешается в процесс. На небольших количествах контролов этого класса, оптимальнее будет массив. так что тут кому что нравится
Больше, по крайней мере у меня, никаких идей нет