I am trying to load an image using SHLoadImageFile,but its returning invalid handle.
I am puzzled where the fault is.Because the path given to SHLoadImageFile is absolutely fine.
The question title currently is "SHLoadImage is returning error code 6". But SHLoadImage return is a handle, not an error code. So perhaps this means that you have called GetLastError?
If so, then error code 6 is defined in <winerror.h> as
//
// MessageId: ERROR_INVALID_HANDLE
//
// MessageText:
//
// The handle is invalid.
//
#define ERROR_INVALID_HANDLE 6L
The documentation does not however say anything about SHLoadImage setting the last error code, so perhaps this is something from earlier in the execution. Try using SetLastError to set the last error code to 0 before calling SHLoadImage.
For more specific advice you need to include more specific information, like showing the code with the "absolutely fine" path. If it really is, perhaps the file doesn't exist. Or is not a valid image.
Cheers & hth.,
Related
I've a function to convert GetLastError function to string to use in my project. But before deploying, I need to test in a sample program.
When I test it, it gets me no error, because the sample program doesn't have any error.
Can anyone help me how can I generate a couple of errors in std::errc, so that GetLastError throw them?
Call SetLastError() from the same thread with desired error code.
Take a look on the SetLastError documentation here
nRetVal = context.InitFromXmlFile(SAMPLE_XML_PATH, &errors);
Above is the function which results in the errors. Actually, SAMPLE_XML_PATH is xml file's path. I tried relative path and absolute path. But the error still pumps out. The return value(nRetVal) of this function is supposed to be 0 here. But the return value is 65537. This function is to read kinect information through XBOX360.
Blow is the error message.
Failed: The parameter is incorrect.
[80070057] (m_pDmo -> AllocateStreamingResources())
m_pReader->Start():Error!
But Niviewer samples all run very well.
Is there any engineer who has bumped into this problem before? I have been struggling for this for a whole day.
Note: This program run pretty well yesterday. But the error pumps out today with similar program. (The difference between them can be ignored because I've already test it.)
I will appreciate your any answers.
When I initialize the kinectInterface handler, I use pointer to "new" a memory and commit operation on the memory.
The bad thing is the handler has never been closed if main process exit.
The Solution is put the pointer into smart pointer like "Ptr" would solve the problem.
So i have a bit of code that uses Dos Commands to try to rename a folder. So
system("rename C:\\Users\\me\\SecondDir NewDir);
So this tries to rename SecondDir to NewDir. There is already a folder at that location called NewDir so it should fail. And it does. Im then using GetLastError to get the error code returned to ensure the problem is what i expect it to be. But it only ever returns ERROR_NO_MORE_FILES. Which isnt the error i should be getting, which is ERROR_ALREADY_EXISTS. Im assuming this is something to do with using the system command?
EDIT: I just checked and i even get ERROR_NO_MORE_FILES returned when a command is successful.
GetLastError will not return a meaningful value except in the circumstances where it is documented to do so. This is not one of them - the values you are getting are irrelevant and intended for someone else.
To rename a file from C you should use the C runtime rename function not use system to invoke a rename utility.
GetLastError is only meaningful immediately after calling a Win32 function which is documented to set the thread Last Error using SetLastError. The C equivalent is errno, which applies to C functions.
The rename function returns -1 on failure and sets errno.
E.g.: http://msdn.microsoft.com/en-us/library/zw5t957f(v=VS.80).aspx
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.
I am using OpenCV 1 to do some image processing, and am confused about the cvSetErrMode function (which is part of CxCore).
OpenCV has three error modes.
Leaf: The program is terminated after the error handler is called.
Parent: The program is not terminated, but the error handler is called.
Silent: Similar to Parent mode, but no error handler is called
At the start of my code, I call cvSetErrMode(CV_ErrModeParent) to switch from the default 'leaf' mode to 'parent' mode so my application is not terminated with an exception/assertion pop up.
Unfortunately 'parent' mode doesn't seem to be working. I still get the message dialog pop up, and my application still terminates.
If I call cvSetErrMode(CV_ErrModeSilent) then it actually goes silent, and no longer quits the application or throws up a dialog... but this also means that I dont know that an error has occurred. In this case, I think the mode is being set correctly.
Has anyone else seem this behaviour before and might be able to recommend a solution?
References:
cvSetErrMode function reference
Open CV Error handling mode reference
I am going to answer my own question, because after some fiddling around I have worked out what happens.
When you switch to 'parent' mode instead of leaf mode, there is an error handler that gets called cvGuiBoxReport(). cvGuiBoxReport() is the default error handler. It seems that even in parent mode, cvGuiBoxReport() still terminates your application! Oops.
So, to get around that you can write your own error handler, and redirect the error to be handled and NOT terminate the application.
An example error handler:
int MyErrorHandler(int status, const char* func_name, const char* err_msg, const char* file_name, int line, void*)
{
std::cerr << "Woohoo, my own custom error handler" << std::endl;
return 0;
}
You can set up parent mode and redirect your error with:
cvSetErrMode(CV_ErrModeParent);
cvRedirectError(MyErrorHandler);
In a week of servers crashing from uploading corrupt or empty images to our image processing server, here are some thoughts on how I solved the intricacies of OpenCV's error handling. We are using V2.2 in a C++ server.
The problem arises in cv::imread() and cv::imdecode() when the image to be loaded is corrupt (or empty). Normally OpenCV just exits the process with with some error messages, not a good idea when you're running a server which should work all the time.
Reviewing the source code at https://code.ros.org/trac/opencv/browser/trunk/opencv/modules/core/include/opencv2/core/core.hpp I ignored the hint in the source comments for cv::setBreakOnError() and discovered the that following pattern works:
cv::setBreakOnError(true); // Can be set globally
...
...
cv::Mat srcImage = cv::imread(filename, 1);
if (!srcImage.data) throw std::exception("bad image");
cv::imread() will now not exit the process, but passes control to your own exception handling, so you can do with it what you like.
Finding this has saved a lot of heartbreak.