MessageBox (appWindow_, DXGetErrorDescription9(result), "Error", MB_OK );
DXGetErrorDescription9
Author
It looks like the DXGetErrorDescription9 function returns a c style string. Why is that? I'm using c++ so I don't want to be forced to use c strings, but one of my surfaces is failing to get created and I want it to display the error message in a MessageBox. I try to use it directly as a parameter like this:
and I get a dialog box that says "No Source Code Available for the Current Location".
Is there a way to turn the result into a c++ string?
a std::string can be constructed from a const char* so just do this:
std::string(DXGetErrorDescription9(hr))
or is that not what you meant? as MessageBox does not take a c++ string, but rather a LPCTSTR which is a NULL terminated C style string.
also: check that DXGetErrorDescription9 isnt returning a NULL pointer, as this will cause MessageBox to crash and then you will see the "No Source Code Available for the Current Location" from the debugger.
std::string(DXGetErrorDescription9(hr))
or is that not what you meant? as MessageBox does not take a c++ string, but rather a LPCTSTR which is a NULL terminated C style string.
also: check that DXGetErrorDescription9 isnt returning a NULL pointer, as this will cause MessageBox to crash and then you will see the "No Source Code Available for the Current Location" from the debugger.
Author
Ah thanks for the tip! I'm not sure if DXGetErrorDescription9 is returning null because as soon as I call it, I get that dialog. So I guess my question now how do I tell what's going wrong with this line here:
The HRESULT being returned is -2005532417... no idea what that means, but apparently DXGetErrorDescription9 is not happy being passed that.
ddscaps_.dwCaps = DDSCAPS_BACKBUFFER;HRESULT result;result = lpddsPrimary_->GetAttachedSurface (&ddscaps_, &lpddsSecondary_ );if (result != DD_OK ){ MessageBox (appWindow_, "Failed to create secondary surface.", "Error", MB_OK ); return 0;}The HRESULT being returned is -2005532417... no idea what that means, but apparently DXGetErrorDescription9 is not happy being passed that.
Quote:Original post by CandleJackI'm not sure what's causing that error, but here's how to find out what a HRESULT code is:
Ah thanks for the tip! I'm not sure if DXGetErrorDescription9 is returning null because as soon as I call it, I get that dialog. So I guess my question now how do I tell what's going wrong with this line here:
*** Source Snippet Removed ***
The HRESULT being returned is -2005532417... no idea what that means, but apparently DXGetErrorDescription9 is not happy being passed that.
1. View it as an 8 digit hex number. If the high bit is set (First digit is >= 8), it's a failure code. Your -2005532417 number is 0x887600ff as hex, which is a failure.
2. The next 3 digits are the facility (Module) the error is in. Since you're using DirectDraw, we'll see what DDraw's facility code is. In ddraw.h, line 45 I have: #define _FACDD 0x876, which shows that the error you have is a DirectDraw error. Annoyingly, D3D and DDraw use the same facility code for some reason...
3. The last 4 digits is the error itself; 00ff in your case. If you read those 4 digits as a decimal number rather than hex, you get 255.
4. Search ddraw.h (Or whatever header is appropriate for the facility code you have) for your error code on a line that looks like it's an error. That brings up: #define DDERR_NOTFOUND MAKE_DDHRESULT( 255 ) on line 5345.
So, the error you have is DDERR_NOTFOUND, which according to the comment just above it means "Requested item was not found". That makes me think that your secondary surface doesn't exist, or the surface described by the caps you passed doesn't exist at least.
As for why it crashes - I suspect that's some other bug. You could try copying the return value of DXGetErrorDescription9 on one line, and displaying it on another, such as:
const char* szError = DXGetErrorDescription9(result);MessageBox (appWindow_, szError, "Error", MB_OK );Also, it's a bad idea to test against DD_OK - that's only one of the 2 billion possible success codes; any return value that doesn't have the top bit set is a success code. You should always be using the FAILED or SUCCEEDED macros instead, so your code would become:
if (FAILED(result))
Author
Quote:Original post by Evil SteveQuote:Original post by CandleJackI'm not sure what's causing that error, but here's how to find out what a HRESULT code is:
Ah thanks for the tip! I'm not sure if DXGetErrorDescription9 is returning null because as soon as I call it, I get that dialog. So I guess my question now how do I tell what's going wrong with this line here:
*** Source Snippet Removed ***
The HRESULT being returned is -2005532417... no idea what that means, but apparently DXGetErrorDescription9 is not happy being passed that.
1. View it as an 8 digit hex number. If the high bit is set (First digit is >= 8), it's a failure code. Your -2005532417 number is 0x887600ff as hex, which is a failure.
2. The next 3 digits are the facility (Module) the error is in. Since you're using DirectDraw, we'll see what DDraw's facility code is. In ddraw.h, line 45 I have: #define _FACDD 0x876, which shows that the error you have is a DirectDraw error. Annoyingly, D3D and DDraw use the same facility code for some reason...
3. The last 4 digits is the error itself; 00ff in your case. If you read those 4 digits as a decimal number rather than hex, you get 255.
4. Search ddraw.h (Or whatever header is appropriate for the facility code you have) for your error code on a line that looks like it's an error. That brings up: #define DDERR_NOTFOUND MAKE_DDHRESULT( 255 ) on line 5345.
So, the error you have is DDERR_NOTFOUND, which according to the comment just above it means "Requested item was not found". That makes me think that your secondary surface doesn't exist, or the surface described by the caps you passed doesn't exist at least.
As for why it crashes - I suspect that's some other bug. You could try copying the return value of DXGetErrorDescription9 on one line, and displaying it on another, such as:
*** Source Snippet Removed ***And then step over that in the debugger.
Also, it's a bad idea to test against DD_OK - that's only one of the 2 billion possible success codes; any return value that doesn't have the top bit set is a success code. You should always be using the FAILED or SUCCEEDED macros instead, so your code would become:
if (FAILED(result))
Wow thanks for all that, that's all very useful information to have! I finally found that I needed to do ZeroMemory(&ddscaps_, sizeof(ddscaps_)); before trying to create the back buffer. I'll switch everything to use the FAILED/SUCCEEDED macros too.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
