И еще. Начинаю подозревать версию моей comctl32.dll во всех грехах. Может она имеет значение. У меня эта длл в 3 экземплярах. В MSDN читал что по умолчанию грузится 5 версия. У меня версия ФАЙЛА 5.8.., а в ВЕРСИИ ПРОДУКТА написано 6.. Я имею ввиду ту длл, что находится в system32

Это сообщение отредактировал(а) S.A.G. - 31.3.2008, 13:41

CUSTOM_DRAW еще с версии Win3.1 вроде бы (Win95 точно) работает
причина не в этом
покажите где и как вы вызываете функцию DlgOnNotify

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

Выкладываю весь код:




Для чего нужен Custom Draw. Хочу один столбец сделать красным, другой - малиновым. Парные строки и 0 сделать одним оттенком серого, непарные - другим. Все.

Честно говоря, я уже совсем исчерпался - незнаю в какую сторону копать. Ведь вопрос не в том, что неработает Custom Draw, а в том, что НЕ ОСУЩЕСТВЛЯЕТСЯ ПЕРЕХОД НА ТОТ CASE, КОТОРЫЙ ОТВЕЧАЕТ ЗА СМЕНУ ЦВЕТА И ФОНА.

Это сообщение отредактировал(а) S.A.G. - 31.3.2008, 14:52

И еще один любопытный факт: если в switch добавляю default с любым кодом, то на default НИКОГДА не осуществляется переход также, как и на нужный CDDS_ITEMPREPAINT. Т.е. даже после возврата CDRF_NOTIFYITEMDRAW всеравно в dwDrawStage оказывается CDDS_PREPAINT :((

Добавлено через 1 минуту и 46 секунд
Ничего, что я заполняю контрол в обработчике инициализации диалога?

кажися я понял в чем проблема   
обработку WM_NOTIFY надо делать на уровне ListView =)
при использовании MFC, оно само это делает и выводит его на уровень диалога, поэтому я сразу не въехал.
щас попробую и выложу что получилось.

фигню сказал в прошлом посте...
вот так вот:


и еще некоторые наблюдения:
hWndLV1 = FindWindowEx(hwnd, NULL, WC_LISTVIEW, "1");
hWndLV1 = GetDlgItem(hwnd, IDC_LIST1);


Это сообщение отредактировал(а) korian - 31.3.2008, 17:54

Ща попробую разобраться..

Это сообщение отредактировал(а) S.A.G. - 31.3.2008, 18:09

Почитал "Remarks" к WM_NOTIFY в MSDN "If the message handler is in a dialog box procedure, you must use the SetWindowLong function with DWL_MSGRESULT to set a return value." -> ну, это мне мало о чем говорит. Эх - снова в макросы лезть, разбираться. Так зачем нужна эта процедура? В каких еще случаях кроме WM_NOTIFY она требуется?

Чем неугодила стандартная распаковка? Подводные камни.. мог бы так неделю сидеть, пока бы не наткнулся на нужное место..((((

когда создается простое окно используется такая симантика функции-обработчика:
LRESULT CALLBACK WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam);
The return value is the result of the message processing and depends on the message sent.

и функция описывается примерно так:
switch(uMsg)
{
...
default: return DefWindowProc(...);
}


когда создается диалог, такая:
INT_PTR CALLBACK DialogProc(HWND hwndDlg, UINT uMsg, WPARAM wParam, LPARAM lParam);
Typically, the dialog box procedure should return TRUE if it processed the message, and FALSE if it did not. If the dialog box procedure returns FALSE, the dialog manager performs the default dialog operation in response to the message.

функция выглядет так:
switch(uMsg)
{
...
default: return 0;
}


т.е. у функции-обработчика диалога нету возможности вернуть LRESULT.
чтобы вернуть LRESULT, надо использовать SetWindowLong(hwnd, DWL_MSGRESULT, lResult);
получается она требуется во всех случаях, если используется диалог и сообщение требует возврата значения LRESULT.
правда есть исключения:


Добавлено через 14 минут и 8 секунд
получается, в общем случае, макрос HANDLE_MSG не очень подходит для функции-обработчика диалога.

Это сообщение отредактировал(а) korian - 31.3.2008, 18:39

korian, спасибо за ликбез, но ведь функция-обработчик WM_NOTIFY имеет тип BOOL? Т.е., поидее ничего не должно возвращаться длиннее BOOL? И макрос подойдет?

объясняю популярней   
можно сказать что для диалога, WindowProc создается системой и имеет примерно такой вид:

LRESULT CALLBACK WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
    if (UserDefinedDlgProc(...))
    {
         return GetWindowLong(hwnd, DWL_MSGRESULT);
    }
    return DefWindowProc(...);
}

поэтому, если используется диалог, все что мы возвращаем из нашей функции-обработчика (UserDefinedDlgProc) не имеет смысла, кроме как true или false.
правда, еще раз скажу, есть исключения описанные выше.

Добавлено @ 19:21
чтобы использовать макросы HANDLE_MSG надо сделать обратное преобразование.
только надо учесть исключения.

Это сообщение отредактировал(а) korian - 31.3.2008, 19:28

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


Это сообщение отредактировал(а) korian - 31.3.2008, 19:39

korian, т.е. получается, что если использовать свое главное окно, а не диалог, то оконная функция расширяет BOOL(int), возвращаемый функцией-обработчиком, до LRESULT (т.е., какбы, расширяет BOOL). Т.е., возвращаемое обработчиком сообщение умещается в BOOL, а системе необходим LRESULT, который диалоговая функция обеспечить неможет и используется иной механизм - SetWindowLong() & return TRUE. Сейчас почитаю про оконную функцию диалога..

korian, скиньте, пожалуйста, ссылку на статью в MSDN, где можно прочитать про обработку сообщений диалоговыми окнами.

Добавлено через 2 минуты и 4 секунды
Я все-таки немного непонимаю, InitDialog тоже возвращает BOOL и такое проходит, т.е. в функции диалога return => результат обработки, а в случае WM_NOTIFY такое не прокатывает? Ведь данные-то умещаются в BOOL(int)?