Столкнулся с такой ситуацией.
Пытаюсь написать класс обертку над обычным окном в winAPI.
И столкнулся с такой проблемой.
Функция которая передаеся для обратного вызова должна быть static если она static то методы класса она не видит если они тоже не static.
Как обычно поступают в таких ситуациях?

Естественно — ибо WTL использует ATL, которая является оберткой над WinAPI. Как и MFC. Кстати если очень хорошо понимать все — то можно делать ацские смеси — аля WTL+MFC =)

"Uzumaki Naruto" <67166@users.rsdn.ru> wrote in message news:2828786@news.rsdn.ru...
> Естественно — ибо WTL использует ATL, которая является оберткой над WinAPI. Как и MFC. Кстати если очень хорошо понимать все — то можно делать ацские смеси — аля WTL+MFC =)

А кстати кто нибудь знает, с DEP современные версии ATL/WTL подружили, и все так же, как в VC 6?

S>"Uzumaki Naruto" <67166@users.rsdn.ru> wrote in message news:2828786@news.rsdn.ru...
>> Естественно — ибо WTL использует ATL, которая является оберткой над WinAPI. Как и MFC. Кстати если очень хорошо понимать все — то можно делать ацские смеси — аля WTL+MFC =)

S>А кстати кто нибудь знает, с DEP современные версии ATL/WTL подружили, и все так же, как в VC 6?

Подружили. Собственно, и с 3-кой тоже проблем нет. Пофиксили это давно на уровне винапи...

Здравствуйте, sawerset, Вы писали:

S>Функция которая передаеся для обратного вызова должна быть static если она static то методы класса она не видит если они тоже не static.
S>Как обычно поступают в таких ситуациях?

Обычно callback передаётся с неким кастомным параметром. По этому параметру можно достать экземпляр класса, с которым и работать. Часто этот параметр имеет тип LPVOID и его можно приводить к указателю на экземпляр, передавая this в функцию, требующую callback.

Здравствуйте, sawerset, Вы писали:
S>Функция которая передаеся для обратного вызова должна быть static если она static то методы класса она не видит если они тоже не static.
S>Как обычно поступают в таких ситуациях?
В процедуру окна передается HWND окна, на которое пришло сообщение. То есть надо привязать твой класс окна к дескриптору этого окна. Структура окна в Виндовс имеет дополнительное поле для application defined данных. Доступ к этим данным можно получить используя функции SetWindowLong() и GetWindowLong() с параметром DWL_USER. Судя по функциям размер этого поля sizeof(LONG), что есть достаточно для передачи указателя на твой класс окна. Должно получиться что-то вроде этого:
1) при создании окна "привязываешь" к его дескриптору указатель на класс окна

class MyCoolWindow {...};
...
MyCoolWindow my_cool_window;
...
SetWindowLong(my_cool_window_handle, DWL_USER, (LONG)&my_cool_window);
...

2) в процедуре окна получаешь указатель на класс по дескриптору окна

LRESULT MyCoolWindowProc(HWND hwnd, ...)
{
...
MyCoolWindow* my_cool_window = (MyCoolWindow*)GetWindowLong(hwnd, DWL_USER);
...
my_cool_window->SomeMethod(...);
...
}

Здравствуйте, ncode, Вы писали:

N>В процедуру окна передается HWND окна, на которое пришло сообщение. То есть надо привязать твой класс окна к дескриптору этого окна. Структура окна в Виндовс имеет дополнительное поле для application defined данных. Доступ к этим данным можно получить используя функции SetWindowLong() и GetWindowLong() с параметром DWL_USER. Судя по функциям размер этого поля sizeof(LONG), что есть достаточно для передачи указателя на твой класс окна.
N>

Вообще говоря, в MFC маппинг HWND на объекты устроен по-другому — там используются хеш-таблицы, и в оконной процедуре (которая в MFC одна на все классы окон) при обработке каждого сообщения происходит поиск в этой таблице указателя на нужный объект (CWnd*) по хэндлу окна.

AS>Подружили. Собственно, и с 3-кой тоже проблем нет. Пофиксили это давно на уровне винапи...

Чуть порыл в инете, наткнулся на:

It works because the OS traps the exception, analyzes the code
and allows execution if it matches the ATL thunk signature. It's
inefficient of course...

Тут задумаешься что выгоднее — юзать общий map(или хэш) из HWND в CWnd в стиле MFC или иметь SEH (похэндленный, конечно — но всё же) на каждый вызов оконной функции...

AS>>Подружили. Собственно, и с 3-кой тоже проблем нет. Пофиксили это давно на уровне винапи...

L>Чуть порыл в инете, наткнулся на:

L>

L>It works because the OS traps the exception, analyzes the code
L>and allows execution if it matches the ATL thunk signature. It's
L>inefficient of course...
L>

L>Тут задумаешься что выгоднее — юзать общий map(или хэш) из HWND в CWnd в стиле MFC или иметь SEH (похэндленный, конечно — но всё же) на каждый вызов оконной функции...

Ну, при желании это легко замерить. Однако у меня стойкое ощущение, что при большом количестве обработчиков (что вполне характерно для MFC приложений) MFC -ные временные объекты на каждый чих будут сильно сливать даже приторможенной DEP'ом ATL 3.