How to determine winapi EnumDisplaySettings failure? According to MSDN
If the function fails, the return value is zero.
also
Graphics mode indexes start at zero. To obtain information for all of
a display device's graphics modes, make a series of calls to
EnumDisplaySettings, as follows: Set iModeNum to zero for the first
call, and increment iModeNum by one for each subsequent call. Continue
calling the function until the return value is zero.
How to determine if returned zero is a failure sign or mode doesnt exist (iModeNum value too big)?
There's nothing told about GetLastError. It seems like this winapi doesnt set last error on failure.
This is typical for GDI api calls, they don't set the GetLastError error code. All you've got is the "it didn't work" return value.
Do note that you must start with iModeNum at 0. If that returns FALSE then you can safely assume there's something drastically wrong with the device name argument. Keep incrementing iModeNum until you get FALSE.
Related
I am debugging some code that uses the MFC CDC Class for printing documents, and which have issues with the preview-printing for determining the total number of pages.
When comparing return values from CDC::DrawText for certain elements, I notice that when drawing to memory the return value is positive but then when drawing to printer the return value is negative.
The CDC documentations says DrawText return "The height of the text if the function is successful."
What does a negative value mean?
This is caused by the fact that your two CDC's (memory and printer) have been placed in different mapping modes.
For example, when the CDC's underlying device context is in MM_TEXT mode, then positive y is down whereas, in (most) other modes, positive 'y' is up. A quick test on my own system (albeit using a screen-based CDC) has shown that CDC::DrawText() returns a positive value when the DC is in MM_TEXT mode but a negative value for (e.g.) MM_ISOTROPIC or MM_HIMETRIC.
Whether or not you have explicitly changed the mapping mode for either of your CDCs, I don't know! But, even if you haven't, the MFC framework has probably "done something" to the printer device context - either before you've retrieved it or (more likely) in the OnPreparePrinting function.
I have the following method in C++:
In case the folder already exists, the correct message is displayed on the screen. However, if the folder does NOT exist, nothing is displayed on the screen, that is, the part identified by case NULL is not executed. How can I solve this problem?
In other words, how can I get the code after the case NULL to run if the folder does not exist?
First, if the folder does not exist, CreateDirectory() will probably succeed and return a non-zero value, so the if condition will return false and you will never get to the switch statement.
Second, GetLastError() does as advertised: it returns the last error. If CreateDirectory() does not raise an error, it will return whatever was the last error set by any other function. Checking for NULL is not very useful.
The spec say that as long as CreateDirectory succeeds, the return value is nonzero.
CreateDirectory
So why don't you use an else to the if clause to print that
At max you can use a default in your switch to print
"There was some error".
Since the switch only executes in case of an error
How do you determine the maximum number of display modes returnable by EnumDisplaySettings without incrementing the second parameter until the function fails.
According to MSDN's Documentation on EnumDisplaySettings. It looks like your only option is to increment IModeNum
From Link:
Graphics mode indexes start at zero. To obtain information for all of a display device's graphics modes, make a series of calls to EnumDisplaySettings, as follows: Set iModeNum to zero for the first call, and increment iModeNum by one for each subsequent call. Continue calling the function until the return value is zero.
I'm kind of wondering about this, if you create a texture in memory in DirectX with the CreateTexture function:
HRESULT CreateTexture(
UINT Width,
UINT Height,
UINT Levels,
DWORD Usage,
D3DFORMAT Format,
D3DPOOL Pool,
IDirect3DTexture9** ppTexture,
HANDLE* pSharedHandle
);
...and pass in D3DFMT_UNKNOWN format what is supposed to happen exactly? If I try to get the surface of the first or second level will it cause an error? Can it fail? Will the graphics device just choose a random format of its choosing? Could this cause problems between different graphics card models/brands?
I just tried it out and it does not fail, mostly
When Usage is set to D3DUSAGE_RENDERTARGET or D3DUSAGE_DYNAMIC, it consistently came out as D3DFMT_A8R8G8B8, no matter what I did to the back buffer format or other settings. I don't know if that has to do with my graphics card or not. My guess is that specifying unknown means, "pick for me", and that the 32-bit format is easiest for my card.
When the usage was D3DUSAGE_DEPTHSTENCIL, it failed consistently.
So my best conclusion is that specifying D3DFMT_UNKNOWN as the format gives DirectX the choice of what it should be. Or perhaps it always just defaults to D3DFMT_A8R8G8B.
Sadly, I can't confirm any of this in any documentation anywhere. :|
MSDN doesn't say. But I'm pretty sure you'd get "D3DERR_INVALIDCALL" as a result.
If the method succeeds, the return
value is D3D_OK. If the method fails,
the return value can be one of the
following: D3DERR_INVALIDCALL,
D3DERR_OUTOFVIDEOMEMORY,
E_OUTOFMEMORY.
I think this falls into the "undefined" category. Some drivers will fail the allocations, while others may default to something. I've never seen anything in the WDK that says that this condition needs to be handled. I'm guessing if you enable the debug DX runtime you will see an error message.
Decimal: 143196173
Hex: 0x889000D
Results from a call to IAudioSessionControl2->GetProcessId().
GetLastError = 126*
Message = "The specified module could not be found"
I'm not really sure how to interpret this error. Additionally, I can't find a description of the HRESULT anywhere. The documented return codes are S_OK, E_POINTER, AUDCLNT_E_NO_SINGLE_PROCESS, and AUDCLNT_E_DEVICE_INVALIDATED.
Anyone know what this code indicates?
*This is an error marshalled across a managed/unmanaged boundary, obtained by Marshal.GetLastError with a Win32Exception providing the message. It could be bogus, but its what I've got. The HRESULT is pulled out of the unmanaged code directly.
Further investigation, FAILED() doesn't seem to think this is an error. However, the out parameter is cleared (set to 0) which doesn't really make sense. Also, GetErrorInfo returns S_FALSE; so there isn't any additional debug info to go on.
This is AUDCLNT_S_NO_CURRENT_PROCESS - I realized that it somehow missed the Windows 7 SDK headers too late.
The SDK documentation is going to be updated to reflect this.
The result means that the session is a cross process session. The process ID returned is the process ID for the first process which created the session, but if you get this result, you really can't depend on the process ID since the process ID isn't unique.
COM methods can set IErrorInfo on failure. Try to retrieve it - it can contain additional information. In unmanaged code you use GetErrorInfo() for that.