CFile::GetFilePath() setting error
-
I inserted GetLastError() calls before and after the GetFilePath() call. Then I traced it. J
"I am the Lorax. I speak for the trees."
Like this?
int x = GetLastError(); CString str; str = file.GetFilePath(); x = GetLastError();
Five birds are sitting on a fence. Three of them decide to fly off. How many are left?
-
Like this?
int x = GetLastError(); CString str; str = file.GetFilePath(); x = GetLastError();
Five birds are sitting on a fence. Three of them decide to fly off. How many are left?
Yup. And I traced into the MFC code, but of course I can't add that code around the 3 or 4 API calls below CFile::GetFilePath(). J
"I am the Lorax. I speak for the trees."
-
Yup. And I traced into the MFC code, but of course I can't add that code around the 3 or 4 API calls below CFile::GetFilePath(). J
"I am the Lorax. I speak for the trees."
Strange, as I see no calls to
SetLastError()in filest.cpp. And forGetFilePath()to return data whilst also setting the error value is odd. Usually when a functions sets an error, no useable data is returned.
Five birds are sitting on a fence. Three of them decide to fly off. How many are left?
-
Yup. And I traced into the MFC code, but of course I can't add that code around the 3 or 4 API calls below CFile::GetFilePath(). J
"I am the Lorax. I speak for the trees."
Have you tried rebuilding your release version with Debug information and stepping into the MFC code to see which API is failing? Another option is to copy the CFile::GetStatus into your own code (temporarily), sprinkle that with diagnostic code, and then call it instead of GetFilePath. Regards, Alvaro
Hey! It compiles! Ship it.
-
Strange, as I see no calls to
SetLastError()in filest.cpp. And forGetFilePath()to return data whilst also setting the error value is odd. Usually when a functions sets an error, no useable data is returned.
Five birds are sitting on a fence. Three of them decide to fly off. How many are left?
DavidCrow wrote: Strange, as I see no calls to SetLastError() in filest.cpp. Well, GetFilePath() makes several API calls. These typically return a value indicating an error has occurred and set the last error value. DavidCrow wrote: And for GetFilePath() to return data whilst also setting the error value is odd. Hence my confusion. DavidCrow wrote: Usually when a functions sets an error, no useable data is returned. There are no documented error conditions in CFile::GetFilePath(). According to MSDN it shouldn't even throw any exceptions, although the example wraps the call in a try/catch block. My code throws no exception. We only found the problem because a GetLastError() call later in the process was giving the error code when the API call legitimately didn't fail. J
"I am the Lorax. I speak for the trees."
-
Have you tried rebuilding your release version with Debug information and stepping into the MFC code to see which API is failing? Another option is to copy the CFile::GetStatus into your own code (temporarily), sprinkle that with diagnostic code, and then call it instead of GetFilePath. Regards, Alvaro
Hey! It compiles! Ship it.
Alvaro Mendez wrote: Another option is to copy the CFile::GetStatus into your own code (temporarily), sprinkle that with diagnostic code, and then call it instead of GetFilePath. That's probably the best way to handle it. The way not to handle it is by forcefully clearing the error after the call. Which is what I've done. :~ J
"I am the Lorax. I speak for the trees."
-
DavidCrow wrote: Strange, as I see no calls to SetLastError() in filest.cpp. Well, GetFilePath() makes several API calls. These typically return a value indicating an error has occurred and set the last error value. DavidCrow wrote: And for GetFilePath() to return data whilst also setting the error value is odd. Hence my confusion. DavidCrow wrote: Usually when a functions sets an error, no useable data is returned. There are no documented error conditions in CFile::GetFilePath(). According to MSDN it shouldn't even throw any exceptions, although the example wraps the call in a try/catch block. My code throws no exception. We only found the problem because a GetLastError() call later in the process was giving the error code when the API call legitimately didn't fail. J
"I am the Lorax. I speak for the trees."
Jamie Hale wrote: ...a GetLastError() call later in the process was giving the error code... So could
SetLastError()be getting called long afterGetFilePath()has come and gone? For example, I've see instances of this type of code:MyLoggingFunction("%d\n", SomeFunction());
DWORD dw = GetLastError();One of two things can happen here.
SomeFunction()could internally callSetLastError(0)but the above call toGetLastError()could be non-zero ifMyLoggingFunction()calledSetLastError(). Or,SomeFunction()could callSetLastError()with a non-zero value, but by the timeMyLoggingFunction()had finished,GetLastError()is 0. Make sense?
Five birds are sitting on a fence. Three of them decide to fly off. How many are left?
-
Jamie Hale wrote: ...a GetLastError() call later in the process was giving the error code... So could
SetLastError()be getting called long afterGetFilePath()has come and gone? For example, I've see instances of this type of code:MyLoggingFunction("%d\n", SomeFunction());
DWORD dw = GetLastError();One of two things can happen here.
SomeFunction()could internally callSetLastError(0)but the above call toGetLastError()could be non-zero ifMyLoggingFunction()calledSetLastError(). Or,SomeFunction()could callSetLastError()with a non-zero value, but by the timeMyLoggingFunction()had finished,GetLastError()is 0. Make sense?
Five birds are sitting on a fence. Three of them decide to fly off. How many are left?
Makes perfect sense. :) But I was tracing through the code in the debugger. The code looked like this...
DWORD dwErr = GetLastError(); // returns 0
CString strFilename = f.GetFilePath(); // returns a proper path
dwErr = GetLastError(); // returns 87It boggles the mind. I have a feeling it could be because the filenames were originally very long, and to write them to a CD the filenames get truncated. The filesystem on the CD could be wackified somehow. But I'm grasping at straws here. J
"I am the Lorax. I speak for the trees."
-
Makes perfect sense. :) But I was tracing through the code in the debugger. The code looked like this...
DWORD dwErr = GetLastError(); // returns 0
CString strFilename = f.GetFilePath(); // returns a proper path
dwErr = GetLastError(); // returns 87It boggles the mind. I have a feeling it could be because the filenames were originally very long, and to write them to a CD the filenames get truncated. The filesystem on the CD could be wackified somehow. But I'm grasping at straws here. J
"I am the Lorax. I speak for the trees."
Try this:
DWORD dwErr = GetLastError();
char s[256];
lstrcpy(s, f.GetFilePath());
dwErr = GetLastError();
CString strFilename = s;
dwErr = GetLastError();
Five birds are sitting on a fence. Three of them decide to fly off. How many are left?
-
Try this:
DWORD dwErr = GetLastError();
char s[256];
lstrcpy(s, f.GetFilePath());
dwErr = GetLastError();
CString strFilename = s;
dwErr = GetLastError();
Five birds are sitting on a fence. Three of them decide to fly off. How many are left?
?? Implying that the SetLastError() might be called in CString::operator=()? J
"I am the Lorax. I speak for the trees."
-
?? Implying that the SetLastError() might be called in CString::operator=()? J
"I am the Lorax. I speak for the trees."
Yes.
Five birds are sitting on a fence. Three of them decide to fly off. How many are left?