|
I have an application I am trying to move from VC6++ to VC++ 2008. It is an MFC application based on Jan Axelson's USB code.
The application that was built with VC6 runs fine with no problems or errors. I am upgrading it to VC++ 2008 a couple of functions at a time. When I run my VC++ 2008 application I see the following messages:
Endpoint 0 found The data area passed to a system call is too small
HidD_GetAttributes: The data area passed to a system call is too small
Master Cell PIC24 found
CreateFile: The data area passed to a system call is too small
Handle to Endpoint Out found
The message identifiers (Endpoint 0, HidD_GetAttributes, CreateFile:, Handle) are messages that I created. However, the message "The data area passed to a system call is too small" is coming from a system call to GetLastError.
I do not get the warning messages with the VC6++ version of the application. The 2008 version appears to be connecting to my USB device (I will know for sure after I add a few more functions) and it runs with no errors. However I am concerned about the too small warning.
Here is one of the calls that gives me the message:
DeviceHandle=CreateFile
(detailData->DevicePath,
0,
FILE_SHARE_READ|FILE_SHARE_WRITE,
(LPSECURITY_ATTRIBUTES)NULL,
OPEN_EXISTING,
0,
NULL);
if(!DeviceHandle)
{
DisplayLastError((CString)"Endpoint 0 not found");
}
else
{
DisplayLastError((CString)"Endpoint 0 found");
}
As you can see by the "Endpoint 0 found" message in the list of messages, the CreateFile call finds the handle to the device. However, DisplayLastError returns the "too small" warning. The function DisplayLastError performs a system call to GetLastError and does some other small tasks.
Does anyone know what I must do to eliminate the message from GetLastError?
|
|
|
|
|
GetLastError return value probably refers to last failed API call (not to CreateFile call: it succeedes).
You should call GetLastError only when a API function fails.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
CreateFile is an API call:
HANDLE WINAPI CreateFile(
It is in the Microsoft list of API functions.
|
|
|
|
|
That's not the point. GetLastError returns valid information from the last API call that failed; you're interrogating it when the last call succeeded. Not surprisingly, it returns gibbersih.
L u n a t i c F r i n g e
|
|
|
|
|
OK, do you have any suggestion as to how I find where the message is coming from? I have a dialog based form that has nothing on it except a list box for the messages and a button to find my HID device when I click the button. So I put this code as the first 2 lines in my OnBnClicked function:
SetLastError(0);
DisplayLastError((CString)"Button Clicked Function: ");
This is what the result is:
Button Clicked Function: The data area passed to a system call is too small
Is it possible the call to DisplayLastError is causing this due to the CString cast? Here is that code:
void CHIDTest2008Dlg::DisplayLastError(CString Operation)
{
LPVOID lpMsgBuf;
USHORT Index = 0;
CString strLastError;
FormatMessage(
FORMAT_MESSAGE_ALLOCATE_BUFFER |
FORMAT_MESSAGE_FROM_SYSTEM |
FORMAT_MESSAGE_IGNORE_INSERTS,
NULL,
GetLastError(),
MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
(LPTSTR) &lpMsgBuf,
0,
NULL
);
strLastError = Operation + (LPCTSTR)lpMsgBuf;
strLastError.TrimRight();
Index = m_ResultsList.InsertString(-1, strLastError);
ScrollToBottomOfListBox(Index);
LocalFree(lpMsgBuf);
}I have no function calls in my BOOL CHIDTest2008Dlg::OnInitDialog(). And the debug window shows no errors when I run the application.
This same code runs without the error messages when compiled with VC6++.
|
|
|
|
|
The most likely cause is the FormatMessage call - I see you're using FORMAT_MESSAGE_ALLOCATE_BUFFER and a Size of 0
From MSDN "If FORMAT_MESSAGE_ALLOCATE_BUFFER is set, this parameter specifies the minimum number of TCHARs to allocate for an output buffer.
so you arnt supplying it with a minimum number of characters
.. so maybe this is what is producing the message - but as the others have already pointed out, to call DisplayLastError() if the call to CreateFile actually succeeeded is pointless anyway.
I think your DisplayLastError() function is incorrect if you intend calling it unnecessarily like this - but if you insist, you could call and store the result from GetLastError() in a DWORD, then test the stored value to see if it's 0 (zero) or not, if it is 0, then you can actually return/exit DisplayLastError or set a hardcoded string eg 'No Error'. If it's NOT 0, then you use the stored value, do the FormatMEssage etc
'g'
|
|
|
|
|
Think about it. GetLastError returns valid information only when the API call immediately preceding it fails. If the call preceding it succeeds, the information returned is meaningless.
So what do you do with your two lines of code? Call SetLastError, which, in all likelihood, succeeds; then you call GetLastError.
L u n a t i c F r i n g e
|
|
|
|
|
Garth, I tried setting the buffer size to 2048 and 4096 but that didn't make a difference. This code is from Jan Axelson's USB code and it works in VC6++ without allocating a buffer size. I did find out that if I turn Unicode off and set it to MBCS the warning messages all disappear.
LunaticFringe, for those two lines of code I was just testing to see if the call to SetLastError would then make an immediate GetLastError call return success. But that didn't work.
Almost all of the GetLastError calls will be removed once I have the application running properly. I just put them in there for test purposes as I am developing the application.
|
|
|
|
|
Don't worry about the buffer size - the GetLastError code snippet was lifted from the same MSDN page Garth referenced, down near the bottom of the page. The 0 for minimum buffer size is fine.
L u n a t i c F r i n g e
modified on Friday, January 15, 2010 8:48 PM
|
|
|
|
|
LunaticFridge,
Thanks for your help. I understand what you are saying about GetLastError. And reading Microsoft's documentation about it makes it seem even less useful. It may be helpful like you say if you already know the API call is failing.
The few places where I want to be aware of failure I put something like this in:
if (DeviceDetected == FALSE)
DisplayData("Device not detected");
else
DisplayData("Device detected");That way I know for sure what the results of a call are.
Again, thanks to you and the others for your help.
|
|
|
|
|
LunaticFringe wrote: That's not the point.
Very well said.
LunaticFringe wrote: GetLastError returns valid information from the last API call that failed; you're interrogating it when the last call succeeded. Not surprisingly, it returns gibbersih.
That's not completely true.In spite of the function name (GetLastError), when a API call succeedes, it often sets last error to 0. Hence, when a API call succeedes and GetLastError is different from zero, the odds are that it refers to an error occurred in a previous API call. That, however, doesn't change the prescription: "use GetLastError just when a API call fails".
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
As L u n a t i c F r i n g e already noted, that's not the point: since CreateFile does NOT fail, hence GetLastError is reporting an error coming from a previous API call (which one?!).
Your approach to error handling is wrong: you've to:
- First and always check
API return value. - Then (if the
API call failed) call GetLastError to retrieve additional information.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
CPallini wrote: First and always check API return value.
Then (if the API call failed) call GetLastError to retrieve additional information.
which is what I said - I think - maybe convoluted (just been drinking French Red wine I bought back from my last trip)
come sta Carlo ?
'g'
|
|
|
|
|
Garth J Lancaster wrote: come sta Carlo ?
Bene, grazie!
E tu?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
CPallini wrote: E tu?
Non c'è male, grazie
|
|
|
|
|
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Yes, but you should call GetLastError IMMEDIATELY after it (and immediately before it to clear Previous Errors) Pass the return value of GetLastError to your Error Display function if things go sour!
The way you did it, you have NO guarantee that other API functions are NOT called, before your Display function calls GetLastError().
Regards,
Bram van Kampen
|
|
|
|
|
You do not show the code for the DisplayLastError() function. I also wonder why you are casting a character constant to a CString. Chances are that one of these two is causing the erroneous message.
MVP 2010 - are they mad?
|
|
|
|
|
2buck56 wrote: Does anyone know what I must do to eliminate the message from GetLastError?
First, CreateFile() is not a boolean function so checking its return value as such is wrong. Second, you need to call GetLastError() as soon as the error is detected, like:
DeviceHandle = CreateFile(detailData->DevicePath,
0,
FILE_SHARE_READ | FILE_SHARE_WRITE,
NULL,
OPEN_EXISTING,
0,
NULL);
if (DeviceHandle == INVALID_HANDLE_VALUE)
{
LPVOID lpMsgBuf;
FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM,
NULL,
GetLastError(),
MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
(LPTSTR) &lpMsgBuf,
0,
NULL);
...
LocalFree(lpMsgBuf);
}
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
DavidCrow wrote: First, CreateFile() is not a boolean function
Good point, indeed.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Richard this is the code for DisplayLastError:
void CHIDTest2008Dlg::DisplayLastError(CString Operation)
{
LPVOID lpMsgBuf;
USHORT Index = 0;
CString strLastError;
FormatMessage(
FORMAT_MESSAGE_ALLOCATE_BUFFER |
FORMAT_MESSAGE_FROM_SYSTEM |
FORMAT_MESSAGE_IGNORE_INSERTS,
NULL,
GetLastError(),
MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
(LPTSTR) &lpMsgBuf,
4096,
NULL
);
strLastError = Operation + (LPCTSTR)lpMsgBuf;
strLastError.TrimRight();
Index = m_ResultsList.InsertString(-1, strLastError);
ScrollToBottomOfListBox(Index);
LocalFree(lpMsgBuf);And I believe you are correct in saying that the CString cast is causing the error. If I call GetLastError immediately after entering my OnBnClick funtion I get the error. At that point no API call has been made (other than the ones the system is doing). Also, by turning off unicode and going to MBCS, all the error messages disappeared. That points to the CString cast.
Ian, the code you show is the way I am doing it now. Since none of my API calls are failing I am not getting any error messages.
|
|
|
|
|
Hi everyone. I'm a newbee that's exhausted the Internet already, so I joined the forum.
I'm attempting to create a file on the Desktop under the Vista environment, which is not user dependent. e.g
ofstream file;
file.open("c:\\%userprofile%\\Desktop\\report.txt");
if (!file){
cerr <<"Unable to open file report.txt";
exit(1);
}
but cannot seem to make this happen on the c drive (desktop).
Thanks in advance.
|
|
|
|
|
You should be able to just call %userprofile%\desktop without having the c:\ at the front. if you open your command prompt and type in %userprofile% it'll then give you an error message but it will expand the %userprofile% to it's actual value.
Hope that helps
|
|
|
|
|
CoderGirl42 wrote: ...but it will expand the %userprofile% to it's actual value.
Unless it contains spaces.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
I see the expansion in which you are speaking of from the cmd window. However, since %userprofile% yields the msg. "...' is not recognized as an internal or external command, operable program or batch file.", I'm wondering if this is the same reason %userprofile% does not work from within my program. I'm beginning to think it's the vista platform 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
