ListView notification trouble...

[brew]

Code Select Expand


case WM_NOTIFY:
if (LOWORD(wParam) == 80) {
switch (((LPNMHDR)lParam)->code) {
case NM_DBLCLK:
char sdfgtmp[256], asdftemp[64];
int selIndex;
LVITEMA lvitem;
selIndex = SendMessage(hWnd_lvwChannel, LVM_GETNEXTITEM, -1, LVNI_FOCUSED);
if (selIndex != -1) {
GetWindowText(hWnd_txtChat, sdfgtmp, sizeof(sdfgtmp));
lvitem.mask = LVIF_TEXT;
lvitem.iSubItem = 0;
lvitem.pszText = asdftemp;
lvitem.cchTextMax = 64;
lvitem.iItem = selIndex;
SendMessage(hWnd_lvwChannel, LVM_GETITEMTEXT, selIndex, (LPARAM)&lvitem);
strcat(sdfgtmp, asdftemp);
SetWindowText(hWnd_txtChat, sdfgtmp);
}
break;
case NM_CUSTOMDRAW:
MessageBox(0, "adsdfgsdfgf", 0, 0);
SetWindowLong(hWnd_lvwChannel, DWL_MSGRESULT, (LONG)ProcessCustomDraw(lParam));
return TRUE;
}
}
break; //  */

LRESULT ProcessCustomDraw (LPARAM lParam) {
    LPNMLVCUSTOMDRAW lplvcd = (LPNMLVCUSTOMDRAW)lParam;
    switch(lplvcd->nmcd.dwDrawStage)  {
case CDDS_PREPAINT:
            return CDRF_NOTIFYITEMDRAW;
case CDDS_ITEMPREPAINT:
            return CDRF_NOTIFYSUBITEMDRAW;
        case CDDS_SUBITEM | CDDS_ITEMPREPAINT:
lplvcd->clrText   = 0x00FFFF00;
            lplvcd->clrTextBk = 0;
            return CDRF_NEWFONT;
    }
    return CDRF_DODEFAULT;
}


For some reason this code is making me crash (every time the listview is repainted) and i have no idea where it does crash either. I tried the messagebox method, but it seems to crash before setwindowlong (not sure why) but i do know it is caused by my code. This code was heavily based off of the example from one of the sites mentioned in the other topic, and it works there but not here at all. Any ideas why?

[Explicit]

Have you tried stepping through it to isolate the line causing the crash?

[brew]

Yes, yes I have. Sometimes it crashes before I have a chance to even DO anything (like popup a messagebox, which pauses the thread), and other times it crashes within my code. Because of this, I can't tell what line is crashing it at all.

EDIT* now that I took a better look it seems as if it only crashes when i move my mouse over it. It doesn't even have to send a WM_NOTIFY to crash. :/

EDIT 2*
After setting the listview long it seems if there is a redraw of that control, then it crashes. Hrmmm.....

[Tazo]

Yes, yes I have. Sometimes it crashes before I have a chance to even DO anything (like popup a messagebox, which pauses the thread), and other times it crashes within my code. Because of this, I can't tell what line is crashing it at all.

try setting breakpoints using your IDE

[l2k-Shadow]

Yes, yes I have. Sometimes it crashes before I have a chance to even DO anything (like popup a messagebox, which pauses the thread), and other times it crashes within my code. Because of this, I can't tell what line is crashing it at all.

try setting breakpoints using your IDE

yeah, this isn't VB.

[rabbit]

The MSVC++ 6 IDE has breakpoint settings too.

[warz]

it sure does, and they're very useful in conjunction with other debuggers.

[Tazo]

The MSVC++ 6 IDE has breakpoint settings too.

yep, along with Dev-C++ (i'm not sure what brew is using)

@l2k-shadow: lmao

[brew]

The breakpoints don't really help. Like I said, it crashes before it gets a chance TO send the second WM_NOTIFY. There must be something wrong with the window long i'm setting it to, but i don't know what exactly. Like I said, I heavily based my code off of MSDN's and that other example's code.

EDIT**** I or'd the return of GetWindowLong and what my ProcessCustomDraw function is returning and it seems to make a difference, just that it now does nothing... it doesn't crash anymore either.

[Zorm]

Did you get this figured out yet?
If not I highly suggest you learn how to use your IDE's debug mode. Then when your program crashes you can get a callstack and look back to see where the crash actually happened at. This will allow you to come to a consensus of what code is causing the problem instead of wildly guessing.
Not to mention that this is an incredibly powerful tool to be able to weild correctly. Once you learn how to use it you won't have to do things like pasting huge chunks of code for people on forums. You'll be able to post a small little chunk, say what the problem is, where the problem is occurring and what you've already tried to resolve it. Its amazing how much faster you'll get a reply if you do this and how much faster you can get back to doing what really matters, programming and making your program rock!

[Camel]

Even if you don't want to actually debug your code, you can still benefit from minidump files; they will give you a clue as to what your application was doing the moment it crashed - and if you open it with your debugger, you will get the state of the stack, which would allow you (or your debugger) to reconstruct local variables and a call trace. Running your program in debug mode would give you even more information, because the program will still be in memory when it crashes.

[brew]

Ah, I gave it another shot and I was able to get it work. This mislead me:

ListView Colors
You won't believe how much time I took to dig this up to actually work! I mean, 99.99% examples were MFC only!

So here we go, finally, pure WinAPI code for listview colors.

Note: This code is found deeply inside MSDN!

First we handle the WM_NOTIFY message to use a NM_CUSTOMDRAW notification. We don't need to use any owner drawn listview, and since this is custom drawn, we can paint the items/subitems at our will.

if(((LPNMHDR)lParam)->code == NM_CUSTOMDRAW)
{
   SetWindowLong(hWnd, DWL_MSGRESULT,
        (LONG)ProcessCustomDraw(lParam));
   return TRUE;
}
We will set a new style which will be a result of our painting function.

So one would think that you'd have to set the window long, right?
Wrong. I had to return it. Found this out from an old MSDN arcticle i was able to dig up with my newfound msdn searching skills.
@Zorm: The program was crashing because I modified the struct it passes without sending the proper return value, therefore it crashed on painting the window.