My BltFast() function returns an unknown HRESULT that doesn''t match any of the 10 possible values returned (as stated in the DirectX 7a SDK). Debugging shows that it''s just a long number. Does anybody know how to check what this number means or how to convert it into one of the HRESULT types? ***************************************************************** HRESULT hr; hr = BBuffer->BltFast(400,300, OffScr1, &source_rect, DBLTFAST_NOCOLORKEY); /*if(hr != DD_OK) ReportError("Unable to blit object from offscreen surface");*/ if (hr == DDERR_EXCEPTION) ReportError("DDERR_EXCEPTION"); if (hr == DDERR_GENERIC) ReportError("DDERR_GENERIC"); if (hr == DDERR_INVALIDOBJECT) ReportError("DDERR_INVALIDOBJECT"); if (hr == DDERR_INVALIDPARAMS) ReportError("DDERR_INVALIDPARAMS"); if (hr == DDERR_INVALIDRECT) ReportError("DDERR_INVALIDRECT"); if (hr == DDERR_NOBLTHW) ReportError("DDERR_NOBLTHW"); if (hr == DDERR_SURFACEBUSY) ReportError("DDERR_SURFACEBUSY"); if (hr == DDERR_SURFACELOST) ReportError("DDERR_SURFACELOST"); if (hr == DDERR_UNSUPPORTED) ReportError("DDERR_UNSUPPORTED"); if (hr == DDERR_WASSTILLDRAWING) ReportError("DDERR_WASSTILLDRAWING"); ***************************************************************** ReportError() just pops up a message box with the string passed to it. None of the last 10 ifs evaluate to TRUE except the first commented out one which just confirms that it is not DD_OK. Any help is appreciated. Thanks in advance.

If you took the time to inspect your SDK docs more closely, there is a lot
more than a mere 10 error codes. Or just look at the header files themselves
for a list of the defined constants.

Relying on an API to return *only* one of a certain set of error codes is definitely bad practice unless the docs specifically state that you can do so. New error codes are introduced all the time to give (hopefully) better error reporting. Also, the guts underneath an API tends to change from time to time which introduces new error codes - a canonical example is when networked file systems got popular all of the sudden a bunch of new error codes started showing up because of the networking code. The codes listed in the docs should be taken as the set of errors people commonly run in to, not the only errors there are.

We might have better luck figuring out your mysterious code if you mentioned what it was.

Lastly, in general you should not check for errors by testing against DD_OK, you should use the FAILED (or SUCCEEDED) macro. API''s can return multiple success codes as well.

-Mike

Another (less cool) way is to manually reverse-engineer the error code. Take a look at the hex value. It will almost certainly take the form 0x8007____ or 0x8876____.
If it''s the first type, then it''s a standard windows error code (such as E_OUTOFMEMORY) and you should be able to find it in winerror.h.
If it''s the second form, then it''s a DDraw-specific error code (such as DDERR_SURFACELOST), and you have to do a bit more work. First, strip off the top 2 bytes, leaving only the last 4 hex numbers. Then fire up calculator and convert the number to decimal. Finally, search for the decimal number in ddraw.h. You should find something that looks like "#define DDERR_SURFACELOST MAKE_DDHRESULT(450)". You''ve found your error code.

Hope this helps.
...Syzygy

Thanks 4 all the helpful replies. Well, I solved the problem by checking against more DDERRs (all 119 of ''em) and found my bug. But Mike mentioned a better way is to use FAILED/SUCCEEDED macros. Care to show me how?

Usually, some parts of the code have

if (FAILED(BBuffer->Blt(........))) {
return;
}

or

if (FAILED(BBuffer->Blt(........))) {
ReportError("some text saying this call failed");
exit(10);
}

but this doesn''t help much bcoz it doesn''t pinpoint what went wrong which is why I resorted to checking against DDERRs to find the exact error. Is there a way to get info about what went wrong from the macro? If there is a better way to check for errors then I won''t have to waste more time coding long switch statements for all the DIERRs, D3DERRs, etc.

Thanx again.