Unicode comparing of file extensions?
-
== '.') { // Get the extension wcsncpy(FileExt, FileName + x + 1, FileNameLen - x - 1); break; } } FileExt = _wcsupr(FileExt); if(FileExt == _T("U") || FileExt == _T("DLL")) { return 1; } else if(FileExt == _T("UNR")) { return 2; } else { return 3; } === First of all, it ALWAYS returns 3, none of the other IFs are triggered for some reason. Second, if I view the FileExt after the extraction; if the extension of the file is only ONE charachter, it adds a strange other char to it for no apparent reason... Can anyone tell me what I'm doing wrong? Thanks, - Fahr
-
== '.') { // Get the extension wcsncpy(FileExt, FileName + x + 1, FileNameLen - x - 1); break; } } FileExt = _wcsupr(FileExt); if(FileExt == _T("U") || FileExt == _T("DLL")) { return 1; } else if(FileExt == _T("UNR")) { return 2; } else { return 3; } === First of all, it ALWAYS returns 3, none of the other IFs are triggered for some reason. Second, if I view the FileExt after the extraction; if the extension of the file is only ONE charachter, it adds a strange other char to it for no apparent reason... Can anyone tell me what I'm doing wrong? Thanks, - Fahr
Try this:
_TCHAR *FileExt = new _TCHAR[10];
int FileNameLen = _tcslen(FileName);
for(int x = FileNameLen; x>= 0; x--)
{
== _T('.'))
{
// Get the extension
_tcsncpy(FileExt, FileName + x + 1, FileNameLen - x - 1);
break;
}
}_tcsupr(FileExt);
if ((_tcscmp(FileExt,_T("U")) == 0) || (_tcscmp(FileExt,_T("DLL")) == 0))
{
delete []FileExt;
return 1;
}
else if (_tcscmp(FileExt,_T("UNR")) == 0)
{
delete []FileExt;
return 2;
}
else
{
delete []FileExt;
return 3;
}First, I replaced the 'unsigned short' with _TCHAR. You're using the tchar.h macros elsewhere, so this will make the code work whether you compile for MBCS or UNICODE. Second, the first
ifcondition wasn't quite right; I changed the character constant from '.' to _T('.'). The '.' is an MBCS character always, even if you are compiling for UNICODE. The statementFileExt = _wcsupr(FileExt)will make theFileExtvalue upper case, but it may also change the value of FileExt (which you probably don't want). Next, the conditions where you compare the extracted extension weren't right. UsingFileExt == _T("U")compares the pointer to the extension value to the pointer to a constant string. You want to do a string comparison here, hence the_tcscmpcalls. I also added thedelete's before thereturn's so that this wouldn't leak memory.
Software Zen:
delete this; -
Try this:
_TCHAR *FileExt = new _TCHAR[10];
int FileNameLen = _tcslen(FileName);
for(int x = FileNameLen; x>= 0; x--)
{
== _T('.'))
{
// Get the extension
_tcsncpy(FileExt, FileName + x + 1, FileNameLen - x - 1);
break;
}
}_tcsupr(FileExt);
if ((_tcscmp(FileExt,_T("U")) == 0) || (_tcscmp(FileExt,_T("DLL")) == 0))
{
delete []FileExt;
return 1;
}
else if (_tcscmp(FileExt,_T("UNR")) == 0)
{
delete []FileExt;
return 2;
}
else
{
delete []FileExt;
return 3;
}First, I replaced the 'unsigned short' with _TCHAR. You're using the tchar.h macros elsewhere, so this will make the code work whether you compile for MBCS or UNICODE. Second, the first
ifcondition wasn't quite right; I changed the character constant from '.' to _T('.'). The '.' is an MBCS character always, even if you are compiling for UNICODE. The statementFileExt = _wcsupr(FileExt)will make theFileExtvalue upper case, but it may also change the value of FileExt (which you probably don't want). Next, the conditions where you compare the extracted extension weren't right. UsingFileExt == _T("U")compares the pointer to the extension value to the pointer to a constant string. You want to do a string comparison here, hence the_tcscmpcalls. I also added thedelete's before thereturn's so that this wouldn't leak memory.
Software Zen:
delete this;Ok, since I'm compiling only unicode I stuck with the wcs commands (Unicode is required for this, I'm not ever going to recompile it in MBCS). If there's a good reason for me to use the _TCHAR and _tcs commands instead, please tell me :) The code DOES work now with the compare calls and the not writing back after uppercasing, but the 1-letter-extension problem still remains for some reason, after a one-letter extension it adds a 135-char... I don't get why... As for the delete[]s, what to do in such a case if I want to RETURN the FileExt? I can't delete it before the return. And also, what to do with static variables? I assume I can't delete those either... Thanks, - Fahr
-
== '.') { // Get the extension wcsncpy(FileExt, FileName + x + 1, FileNameLen - x - 1); break; } } FileExt = _wcsupr(FileExt); if(FileExt == _T("U") || FileExt == _T("DLL")) { return 1; } else if(FileExt == _T("UNR")) { return 2; } else { return 3; } === First of all, it ALWAYS returns 3, none of the other IFs are triggered for some reason. Second, if I view the FileExt after the extraction; if the extension of the file is only ONE charachter, it adds a strange other char to it for no apparent reason... Can anyone tell me what I'm doing wrong? Thanks, - Fahr
You have a couple of problems. First, the correct type for Unicode characters is
WCHAR(yeah, it's the same thing as unsigned short due to a typedef, but usingWCHARwill make the code easily readable by others). Then you're comparing strings with==which is not correct for C-style strings. There's already an API for finding the extension, then once you have that use_wcsicmp()to do case-insensitive comparison.int LookAtExt(LPCWSTR wszFilename)
{
LPCWSTR wszExt = PathFindExtension ( wszFilename );if ( 0 == _wcsicmp ( wszExt, L".U" ) || 0 == _wcsicmp ( wszExt, L".DLL" ) )
return 1;
else if ( 0 == _wcsicmp ( wszExt, L".UNR" ) )
return 2;
else
return 3;
}You can also use a string wrapper class like
wstringorCString(which has a handyCompareNoCase()method) to make the code a little neater. --Mike-- When 900 years old you reach, look as good you will not. Hmm. 1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click! My really out-of-date homepage Sonork-100.19012 Acid_Helm -
You have a couple of problems. First, the correct type for Unicode characters is
WCHAR(yeah, it's the same thing as unsigned short due to a typedef, but usingWCHARwill make the code easily readable by others). Then you're comparing strings with==which is not correct for C-style strings. There's already an API for finding the extension, then once you have that use_wcsicmp()to do case-insensitive comparison.int LookAtExt(LPCWSTR wszFilename)
{
LPCWSTR wszExt = PathFindExtension ( wszFilename );if ( 0 == _wcsicmp ( wszExt, L".U" ) || 0 == _wcsicmp ( wszExt, L".DLL" ) )
return 1;
else if ( 0 == _wcsicmp ( wszExt, L".UNR" ) )
return 2;
else
return 3;
}You can also use a string wrapper class like
wstringorCString(which has a handyCompareNoCase()method) to make the code a little neater. --Mike-- When 900 years old you reach, look as good you will not. Hmm. 1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click! My really out-of-date homepage Sonork-100.19012 Acid_Helm -
PathFindExtension results in: error LNK2001: unresolved external symbol __imp__PathFindExtensionW@4 I DO have shlwapi.h in my includes... - Fahr
2.3 I'm trying to call a Windows API, but the linker gives an unresolved external error (LNK2001) on the API name. Why? --Mike-- When 900 years old you reach, look as good you will not. Hmm. 1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click! My really out-of-date homepage Sonork-100.19012 Acid_Helm
-
2.3 I'm trying to call a Windows API, but the linker gives an unresolved external error (LNK2001) on the API name. Why? --Mike-- When 900 years old you reach, look as good you will not. Hmm. 1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click! My really out-of-date homepage Sonork-100.19012 Acid_Helm
OK! That worked! Thanks a lot :) It saves a lot of trouble of getting it myself, plus the weird trailing char error is no longer there :) Also, you suggested the use of L"", while I use _T(""), a quick look in the TCHAR.h gave me the idea that _T("") is defined as L""... So what IS the actual difference? If any... - Fahr
-
OK! That worked! Thanks a lot :) It saves a lot of trouble of getting it myself, plus the weird trailing char error is no longer there :) Also, you suggested the use of L"", while I use _T(""), a quick look in the TCHAR.h gave me the idea that _T("") is defined as L""... So what IS the actual difference? If any... - Fahr
Use the
TCHARmacros (including_T) when you want to make ANSI and Unicode builds from the same code. Since you said you only need to make a Unicode build, you can go ahead and useL""to make Unicode literals. See my article on Win32 Character Encodings[^] for the full scoop. --Mike-- When 900 years old you reach, look as good you will not. Hmm. 1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click! My really out-of-date homepage Sonork-100.19012 Acid_Helm -
Use the
TCHARmacros (including_T) when you want to make ANSI and Unicode builds from the same code. Since you said you only need to make a Unicode build, you can go ahead and useL""to make Unicode literals. See my article on Win32 Character Encodings[^] for the full scoop. --Mike-- When 900 years old you reach, look as good you will not. Hmm. 1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click! My really out-of-date homepage Sonork-100.19012 Acid_HelmWell, that article does shed light on a lot of issues, thanks a lot :) I actually DO need the DLL to run under Windows 98, if I use only unicode it wont work then I guess? I didn't quite realise that... So what do I do now? Change all my L""s back to _T("")s and all my WCHAR*s to TCHAR*s? Will that do the trick? And do I need to build 2 different DLLs for WinNT and Win9x?? - Fahr
-
Well, that article does shed light on a lot of issues, thanks a lot :) I actually DO need the DLL to run under Windows 98, if I use only unicode it wont work then I guess? I didn't quite realise that... So what do I do now? Change all my L""s back to _T("")s and all my WCHAR*s to TCHAR*s? Will that do the trick? And do I need to build 2 different DLLs for WinNT and Win9x?? - Fahr
Fahr wrote: I actually DO need the DLL to run under Windows 98, if I use only unicode it wont work then I guess? Right. You can use Unicode strings in 98, however you can't call Unicode APIs because they are not implemented. So yeah, you'll need to change your
wcsxxx()calls to their_tcsxxx()equivalents, and use_Taround literals. The string article covers this topic and why theTCHARsystem is necessary. It sounds like you're not using any NT-specific features, so you can just build an MBCS build of your code and use that on NT. Again, see the string article for the full story. --Mike-- When 900 years old you reach, look as good you will not. Hmm. 1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click! My really out-of-date homepage Sonork-100.19012 Acid_Helm -
Fahr wrote: I actually DO need the DLL to run under Windows 98, if I use only unicode it wont work then I guess? Right. You can use Unicode strings in 98, however you can't call Unicode APIs because they are not implemented. So yeah, you'll need to change your
wcsxxx()calls to their_tcsxxx()equivalents, and use_Taround literals. The string article covers this topic and why theTCHARsystem is necessary. It sounds like you're not using any NT-specific features, so you can just build an MBCS build of your code and use that on NT. Again, see the string article for the full story. --Mike-- When 900 years old you reach, look as good you will not. Hmm. 1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click! My really out-of-date homepage Sonork-100.19012 Acid_Helmyeah, I changed all it around... problem is tho, as soon as I change UNICODE,_UNICODE to _MBCS, I get about 5 unresolved externals... I'm using the DLL for native coding with Unreal Script, the script can call to the DLL and uses the core and engine of the game for game-specific functions, apperently those only support unicode... Which is terribly odd, cuz the game runs on ANY windows... - Fahr