Thread: StretchDIBits() - weird behaviour..

I'm using aforementioned gdi function to display some data into window's client area (part of memory where i actually write some data like lines etc..), i do not use stretching or such thinks, just plain copy from data in form of bitmap.
I use it A LOT, it handles all drawing to client area, and i encountered problem: sometimes it does neither fail nor draw anything: input params are proper, but it returns 0 as number of lines drawn. Weird is that it happens seemingly without any triggering effect, if i force a window to repaint, it sometimes works again, sometimes not; when i resize window, it works again... I have no clue why might it fail and so far found no evidence of errors in my own code (it actually WORKS almost all the time without errors or problems and/even after such a draw error).
I still hope i'll find error within the code, but it is unlikely, so i started to 'blame' the function itself. May it be kind of 'overload'?
I tried it only on WinXP (Pro) systems so far.

Any ideas?

not much to work with here. Is the memory DC being recreated every time? Just when you resize? I wonder if your DC being recreated on the resize is what's causing it to work again. As if the DC got hosed. Difficult to say without seeing the code I guess.

Code:

case WM_PAINT:
//shall we draw?
    ld = (P_LOCAL_DATA) GetWindowLong(hwnd, 0);

    hdc = BeginPaint(hwnd, &ps);

    if (lcs->v[ld->id].view__viewport.viewport__data != NULL)
    {
        bmi.bmiHeader.biWidth = lcs->v[ld->id].view__viewport.viewport__size_x;
        bmi.bmiHeader.biHeight = lcs->v[ld->id].view__viewport.viewport__size_y;

        long lines;

        if (GDI_ERROR == (lines = SetDIBitsToDevice(hdc, 0, 0, lcs->v [ld->id].view__viewport.viewport__size_x,
          lcs->v[ld->id].view__viewport.viewport__size_y, 0, 0,
          0, lcs->v[ld->id].view__viewport.viewport__size_y,
          (P_VOID) lcs->v[ld->id].view__viewport.viewport__data,  &bmi, DIB_RGB_COLORS)))
     }

     EndPaint(hwnd, &ps);
     break;

Code looks like this.
I tried SetDIBitsToDevice(), but to the same result. Those structs point to window-specific data (dimensions, memory area to be displayed..) and contain valid data, that is sure. Bmi struct is static and fully initialised in WM_CREATE, here is only local dimension specification.

Most important question (to me) is 'Can used function (setdibitstodevice or stretchdibits) return 0 drawn lines (as it does) even if all params are ok and it should draw +-hundreds of them???'

Small note: resizing of window does sometimes cause data to appear (eg. cause successfull draw) but it works other way as well - sometimes if i resize window with displayed data, new draw does not display anything...

ok, I think I know what it is. The paint DC has an HREGION selected into it. This means that you will only be able to see the part that was Invalidated. If you want to force a repaint of the entire window, you need to InvalidateRect() with NULL passed in for the rect.

try ignoring the paintdc and using GetDC on the window to get a different one to draw on. At least that way we can eliminate the paintDC as being the problem.

Sorry. I can't do much without being able to debug the project myself.

um... you debugging it doesn't help me find your problem I'm afraid.

GDI_ERROR (-1) is not returned by SetDIBitsToDevice() if it fails.

It returns 0.

StretchDIBits() returns GDI_ERROR.

Use GetLastError() if SetDIBitsToDevice() returns zero and output to a messagebox your params.

How are you filling the rest of the bitmap header? Is the header struct a local and non static?

Do you check that you are actually asking it to draw some lines ie not drawing 0 lines?

How do you know this index, ld->id, is valid? (just a suggestion)

Try using the rect returned in the paintstruct for the update area.
It may not be your app that calls for the paint (and so sets the update area to the whole client area)

Do you have any non static local variables that are used by this function?

Thank you guys for suggestions :).. i did not find exact cause of the problem yet, but i managed to isolate part of preprocessing that seems to trigger possibility of error.. I'm not absolutely sure about it, but when i disabled it, i did not run into the problem so far. I should have no problems finding that error now, as it is only a few hundred lines of code to check :o).

to Novacain specially:

>GDI_ERROR (-1) is not returned by SetDIBitsToDevice() if it fails.
>It returns 0

My overlooking, thanks for correcting :).. i use StretchDIBits(), but error value from SetDIBitsToDevice() will be useful, too.
The rest of things you suggested cannot play any role there, they are either being checked or are valid due to internal logic (like number of lines or indices).

edit: i tried GetLastError(). Returned 0 :-|.

Holy thread necrophillia batman!