Читаю MSDN и никак немогу врубиться как это сделать. Что нужно делать, перехватив сообщение WM_NOTIFY?

http://msdn2.microsoft.com/en-us/library/bb774865.aspx - это поможет?

korian, Я как раз читаю это и много чего другого, но разобраться пока немогу. Я так понимаю, что никак не изменишь цвет или фон ячейки просто изменив соотв. значения в передаваемых структурах в обработчик WM_NOTIFY? Т.е. выходит, что изменятся только локальные параметры обработчика. Может отослать WM_NOTIFY в нужный момент с обновленными структурами в качестве параметров? Иного выхода пока невижу.

http://msdn2.microsoft.com/en-us/library/b...817(VS.85).aspx
пример изменения шрифта и его clrTextBk и clrText
HDC есть, так что, менять можно все, что можно менять для HDC.
некоторые операции делаются просто (как с шрифтом - установка нового шрифта, и return CDRF_NEWFONT)
а другие изменения делаем при PREPAINT и возвращаем исходное состояние HDC в POSTPAINT

korian, спасибо за наводку. Оказывается, есть технология Custom Draw. Сейчас почитаю про нее в своей MSDN.

Проблема, однако, не решена. Вот пример из MSDN:


Что делает функция GetFontForSubItem()? Кстати, в MSDN ее ненайти. И негде в студии ее тоже нет, гы гы гы. Вот она - забота о разработчиках от MS. Ладно, книжики есть корявые, но такого я не ожидал. Везде в примерах не рабочие коды, а постоянные сокращения. И еще на английском языке. Особенно любопытны ее параметры:

1. dwItemSpec - The item number. What is contained in this member will depend on the type of control that is sending the notification. See the NM_CUSTOMDRAW notification reference for the specific control to determine what, if anything, is contained in this member.

2. lItemlParam - Application-defined item data

3. iSubItem - в nmc вообще нету такого элемента.

Ну просто сказка - как же в этом разобраться?

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



Предлагают пользоваться вторым вариантом, а в примере криво показали второй. А - ну да, цвет и фон просто записывают в локальные параметры, а шрифт заносят в контекст.


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

GetFontForSubItem - это Application Defined функция =)
короче ее вы должны написать сами...
она должна возвращает нужный шрифт в зависимости от того, какая ячейка в данный момент рисуется.
все ее параметры описывают ячейку.

Добавлено через 2 минуты и 1 секунду

в цитате ясно сказано "except for the list view and tree view".

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

Вот код моего обработчика:

Он компилируется. Где ошибка? Цель - все итемы должны быть красными. Если выходит не то, то что? Разъясните, пожалуйста.

Добавлено @ 17:39
Кстати, по поводу

Просто place??? - я сделал просто place в локальный параметр, но что дальше? - Система помимо return еще проверяет, что я записал в локальный параметр обработчика???

Добавлено @ 17:47

Ага, ну так я же "place", а оно неработает.

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

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

вроде так

Ну так вы же не поменяли ничего? Просто закомментировали объявление hdc?

Добавлено через 1 минуту и 40 секунд

Это прояснили, но все по прежнему неработает.

поменял
case CDDS_ITEMPREPAINT: SetTextColor(hdc, RGB(255, 0, 0));
case CDDS_ITEMPREPAINT: lpNMCustomDraw->clrText = RGB(255, 0, 0);


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

Я после того как написал предыдущее сообщение (незная о вашей замене) сделал так и не заработало. И раньше делал - не зарабатывало. Чушь какая-то..

Добавлено через 11 минут и 16 секунд
Может еще у кого-нибудь появяться какие-нибудь мысли?

код написанный выше - рабочий код, если DlgOnNotify вызывается при WM_NOTIFY парента, а hWndLV1 - HWND ListView
там правда хз, нафига такое написано:
NMLVCUSTOMDRAW * lpNMCustomDraw = lpNMCustomDraw = (NMLVCUSTOMDRAW *)pnmh;
но оно все равно работает.

как конкретно оно у вас не работает? и давайте тогда уж побольше кода...

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

Оно почему-то не переходит на кейс CDDS_ITEMPREPAINT. Ставлю брейк - запускается сразу окошко -> программа и не доходит до изменения цвета для каждого итем-а. Почитал ОЧЕНЬ вдумчиво документацию в MSDN про Custom Draw. Оно должно, поидее, и все subitem-ы рисовать красным, но у меня попрежнему все черное. Может я неправильно описал стиль диалога (у меня прога на основе диалога). Вот описание:



У меня два List-а. Первый тот что hWndLV1

И еще. Начинаю подозревать версию моей 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)?

ммм. наверно не так.
это логически разные типы возврата вообще. не понимаю что значит расширяет... в общем случае, когда используется обычное окно, мы полюбому должны обработать сообщение (даже если это вызов DefWindowProc) и возвращаем ответ на сообщение (LRESULT).
С диалогом, есть возможность сообщить - обработали ли мы данное сообщение (TRUE) или система должна сама этим заниматься (FALSE). LRESULT в диалоге можно возвратить только с помощью SetWindowLong.


Это сообщение отредактировал(а) korian - 1.4.2008, 11:04

У любого окна есть WindwoProc, которая должна возвращать LRESULT, у диалога тоже. Только в последнем случае она имеет стандартный вид и пользователю дают возможность изменить ее часть, которая называется DialogProc, вот и все. N/t/ DialogProc - это часть WindowProc.