CreateFile problem
-
Ok, this is a revisit to the problem that Chris Losinger tried to help me with. I had wrongly thought GetFileSize was the problem, he helped me determine that was not the case, thanks again Chris!! I have an app associated with a certain file type. When I double click the file, it opens up my app. In this way the file name is passed to the app. This works fine and I have proved it by popping a message box with the filename on it. As you can see below
m_EncryptedFilePathis the file name in question.HANDLE hOriginal = ::CreateFile(m_EncryptedFilePath,
GENERIC_READ,
FILE_SHARE_READ,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL);Now, in
DEBUGmode, all is dandy.hOriginalis notNULL. But inRELEASEmode, it isNULLeven though the correct file name is passed through in each case. Could it be file permissions?? Access rights?? The way I'm associating the file with the app?? By the way, release mode works fine if I hard code the file name like soHANDLE hOriginal = ::CreateFile("c:\\myfile.abc",
GENERIC_READ,
FILE_SHARE_READ,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL);So I'm completely at my wits end over this at the moment. Any and all comments will be appreciated. Senwe And when God, who created the entire universe with all of its glories, decides to deliver a message to humanity, He WILL NOT use, as His messenger, a person on cable TV with a bad hairstyle.
-
Ok, this is a revisit to the problem that Chris Losinger tried to help me with. I had wrongly thought GetFileSize was the problem, he helped me determine that was not the case, thanks again Chris!! I have an app associated with a certain file type. When I double click the file, it opens up my app. In this way the file name is passed to the app. This works fine and I have proved it by popping a message box with the filename on it. As you can see below
m_EncryptedFilePathis the file name in question.HANDLE hOriginal = ::CreateFile(m_EncryptedFilePath,
GENERIC_READ,
FILE_SHARE_READ,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL);Now, in
DEBUGmode, all is dandy.hOriginalis notNULL. But inRELEASEmode, it isNULLeven though the correct file name is passed through in each case. Could it be file permissions?? Access rights?? The way I'm associating the file with the app?? By the way, release mode works fine if I hard code the file name like soHANDLE hOriginal = ::CreateFile("c:\\myfile.abc",
GENERIC_READ,
FILE_SHARE_READ,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL);So I'm completely at my wits end over this at the moment. Any and all comments will be appreciated. Senwe And when God, who created the entire universe with all of its glories, decides to deliver a message to humanity, He WILL NOT use, as His messenger, a person on cable TV with a bad hairstyle.
-
Good question, in DEBUG mode it returns 0, implying all is well. That's why when I'm debugging everything works. The release version of CreateFile returns a NULL handle. Perhaps I should place a FormatMessage and populate a MessageBox to retrieve GetLastError in my release mode? And when God, who created the entire universe with all of its glories, decides to deliver a message to humanity, He WILL NOT use, as His messenger, a person on cable TV with a bad hairstyle.
-
GetLastError returns the following...
The filename, directoryname, or volume label syntax is incorrect
Which is what I assumed...but I just don't see how or why. And when God, who created the entire universe with all of its glories, decides to deliver a message to humanity, He WILL NOT use, as His messenger, a person on cable TV with a bad hairstyle.
-
Ok, this is a revisit to the problem that Chris Losinger tried to help me with. I had wrongly thought GetFileSize was the problem, he helped me determine that was not the case, thanks again Chris!! I have an app associated with a certain file type. When I double click the file, it opens up my app. In this way the file name is passed to the app. This works fine and I have proved it by popping a message box with the filename on it. As you can see below
m_EncryptedFilePathis the file name in question.HANDLE hOriginal = ::CreateFile(m_EncryptedFilePath,
GENERIC_READ,
FILE_SHARE_READ,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL);Now, in
DEBUGmode, all is dandy.hOriginalis notNULL. But inRELEASEmode, it isNULLeven though the correct file name is passed through in each case. Could it be file permissions?? Access rights?? The way I'm associating the file with the app?? By the way, release mode works fine if I hard code the file name like soHANDLE hOriginal = ::CreateFile("c:\\myfile.abc",
GENERIC_READ,
FILE_SHARE_READ,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL);So I'm completely at my wits end over this at the moment. Any and all comments will be appreciated. Senwe And when God, who created the entire universe with all of its glories, decides to deliver a message to humanity, He WILL NOT use, as His messenger, a person on cable TV with a bad hairstyle.
-
Hi, Sounds like a memory allocation\deallocation problem with 'm_EncryptedFilePath' especially if the path is correct('\\' etc) and it works when you hard code the path. What type of string is 'm_EncryptedFilePath'?
Hi Ollie, it's a WTL CString. I've always used it as a drop in replacement for MFC's CString in most cases. And when God, who created the entire universe with all of its glories, decides to deliver a message to humanity, He WILL NOT use, as His messenger, a person on cable TV with a bad hairstyle.
-
Good question, in DEBUG mode it returns 0, implying all is well. That's why when I'm debugging everything works. The release version of CreateFile returns a NULL handle. Perhaps I should place a FormatMessage and populate a MessageBox to retrieve GetLastError in my release mode? And when God, who created the entire universe with all of its glories, decides to deliver a message to humanity, He WILL NOT use, as His messenger, a person on cable TV with a bad hairstyle.
If you think, that to populate a MessageBox is the right answer, you have to do it. (If you know what I mean) I also have these type of problems and I have to fix them. The first step is to get a "handle" to the problem. You have there a member variable for the file name. I guess it is a CString -> (LPCSTR) cast is best practise. Try also Release Output of it to check its ok. ( I Do a Findfile to check this).:~
-
If you think, that to populate a MessageBox is the right answer, you have to do it. (If you know what I mean) I also have these type of problems and I have to fix them. The first step is to get a "handle" to the problem. You have there a member variable for the file name. I guess it is a CString -> (LPCSTR) cast is best practise. Try also Release Output of it to check its ok. ( I Do a Findfile to check this).:~
KarstenK wrote: The first step is to get a "handle" to the problem. Yep and my assumption was correct, the file isn't being recognised. GetLastError confirms this. KarstenK wrote: I guess it is a CString -> (LPCSTR) cast is best practise Well yes, a WTL CString, not an MFC CString :-) And when God, who created the entire universe with all of its glories, decides to deliver a message to humanity, He WILL NOT use, as His messenger, a person on cable TV with a bad hairstyle.
-
Hi Ollie, it's a WTL CString. I've always used it as a drop in replacement for MFC's CString in most cases. And when God, who created the entire universe with all of its glories, decides to deliver a message to humanity, He WILL NOT use, as His messenger, a person on cable TV with a bad hairstyle.
-
have you tried making a local copy of the string and then using it, sorry not up to speed on WTL CString, what is the underlying type?
No prob Ollie, it's a great library as you already know I'm sure, please do explore it for your new win32 work :-) The underlying type is LPTSTR. I think you're onto something though. Let me explore the CString header file more carefully. And when God, who created the entire universe with all of its glories, decides to deliver a message to humanity, He WILL NOT use, as His messenger, a person on cable TV with a bad hairstyle.