Folderitem case

I have found an issue with folderitem and the case of file and folder names. It seems that the results of Nativepath and Name are not consistent with the actual file name if a lowercase string is used in Getfolderitem, at least in Windows (have not tested in Mac).

Sample code:

[code] Dim s1 as string = “C:/Temp/Mytest Name.tiff” 'this is the correct name

Dim f1 as FolderItem = GetFolderItem(s1)
if f1 <> nil and f1.Exists then
Label1.Text = f1.NativePath

'shows  C:/Temp/Mytest Name.tiff

end if

Dim s2 as string = Lowercase(s1)
Dim f2 as FolderItem = GetFolderItem(s2)
if f2 <> nil and f2.Exists then
label2.Text = f2.NativePath

'shows c:/Temp/mytest name.tiff

end if[/code]

I think NativePath,DisplayName and Name should always display the correct name even if a lowercase string has been passed, and in the worst scenario it should not mix lowercase and uppercase like in the second label c:/Temp/mytest name.tiff

Am I missing something?

[quote=159539:@Alejandro Fresno Meyer]I have found an issue with folderitem and the case of file and folder names. It seems that the results of Nativepath and Name are not consistent with the actual file name if a lowercase string is used in Getfolderitem, at least in Windows (have not tested in Mac).

Sample code:

[code] Dim s1 as string = “C:/Temp/Mytest Name.tiff” 'this is the correct name

Dim f1 as FolderItem = GetFolderItem(s1)
if f1 <> nil and f1.Exists then
Label1.Text = f1.NativePath

'shows  C:/Temp/Mytest Name.tiff

end if

Dim s2 as string = Lowercase(s1)
Dim f2 as FolderItem = GetFolderItem(s2)
if f2 <> nil and f2.Exists then
label2.Text = f2.NativePath

'shows c:/Temp/mytest name.tiff

end if[/code]

I think NativePath,DisplayName and Name should always display the correct name even if a lowercase string has been passed, and in the worst scenario it should not mix lowercase and uppercase like in the second label c:/Temp/mytest name.tiff

Am I missing something?[/quote]

In Windows, you got two different ways of encoding paths ; one is the “human” way with long names, that is nativepath. If you use shellpath, you will have a file name such as “PRINAC~1.txt”.

It is because for historical reasons, the system uses internally the old DOS 8 characters representation, with stuck on its back the Windows long file names. If your file name is less than 8 characters, as in name.tiff, when you enter it in lowercase, it is represented both as NAME.TIFF in shellpath (DOS), and name.tiff in Displayname or NativePath, because both use the Windows long file name representation.

Displayname and name usually display the same, but the LR states explicitly Displayname shows the human representation of the name, implying name can be different.

Mac does not have the issue, since it has been using long file names all along.

At one time in the past, the file name was 31 characers long, folder name 27 characters long, if my memory is correct (on the number of characters).

Note that 27 or 31 characters is a huge number of characters to name a file !

Michel, being as you mention I would get the same result for both folderitem.nativepath as they belong to exactly the same file.
But this is not the case.

I’m not changing the case of the file itself, only the case of the string passed to folderitem to get the file/folder data and I believe this data should represent exactly the same as File explorer f.s.

It’s not a matter of how Windows file names are used, it’s about how folderitem return different values for the same file in the system.

//
// Directory listing below from Windows 7 64 bit OS
//
c:\\>dir /x T*
 Volume in drive C is System
 Volume Serial Number is 1A3E-9EE9

 Directory of c:\\

01/15/2015  12:28 PM    <DIR>                       Temp
               0 File(s)              0 bytes
               1 Dir(s)   4,411,224,064 bytes free

c:\\>cd Temp

c:\\Temp>dir /x
 Volume in drive C is System
 Volume Serial Number is 1A3E-9EE9

 Directory of c:\\Temp

01/15/2015  12:28 PM    <DIR>                       .
01/15/2015  12:28 PM    <DIR>                       ..
01/15/2015  12:28 PM                 0 MYTEST~1.TIF Mytest Name.tiff
01/30/2013  03:15 PM    <DIR>                       SEP
               1 File(s)              0 bytes
               3 Dir(s)   4,404,658,176 bytes free

c:\\Temp>

  //
  // Result below from Windows 7, Xojo v2014r2.1
  //

  Dim s1 as string = "C:/Temp/Mytest Name.tiff"   'this is the correct name 
  
  Dim f1 as FolderItem = GetFolderItem(s1)
  if f1 <> nil and f1.Exists then
    Label1.Text = f1.NativePath
    Label3.Text = s1

    // Label1.Text shows  C:/Temp/Mytest Name.tiff
    // Label3.Text shows  C:/Temp/Mytest Name.tiff

  end if
  
  Dim s2 as string = Lowercase(s1)
  Dim f2 as FolderItem = GetFolderItem(s2)
  if f2 <> nil and f2.Exists then
    Label2.Text = f2.NativePath
    Label4.Text = s2
    
    // Label2.Text shows  C:/Temp/mytest name.tiff
    // Label4.Text shows  c:/temp/mytest mame.tiff

  end if

The above shows details of the problem reported in OP.

[quote=159551:@Alejandro Fresno Meyer]I’m not changing the case of the file itself, only the case of the string passed to folderitem to get the file/folder data and I believe this data should represent exactly the same as File explorer f.s.

It’s not a matter of how Windows file names are used, it’s about how folderitem return different values for the same file in the system.[/quote]

I tried your code but am sorry, the syntax with the forward slash and a space before the name simply does not work on my system. Instead of Temp I used Desktop, but only the documented Windows path with backslash works :

 "c:\\Users\\Mitch\\Desktop\ame.tiff" 

Are you working on Mac and building for Windows ? At any rate, the space between the path and the file name does not do here in either case. Where did you find that peculiar notation ?

After correcting the path string I was able to verify your issue.

Xojo is case insensitive. So is Win32 when it comes to the file name.

Most importantly, see http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx

I have no idea how the file information box fetches the case sensitive name. I could not find anything of that sort in the Win32 API
http://msdn.microsoft.com/en-us/library/windows/desktop/aa364232(v=vs.85).aspx

In short, what you found is that Xojo uses whatever name you pass to it to point to a particular file, and so does Windows itself.

I’m using Windows 8.1 and Xojo 2014R3.1.

There is no space between the path and the file name, it’s only that the file name is “Mytest Name.tiff” as many other files in Windows.

I understand that there is no case sensitivity in Windows file names, the file “myname.txt” is the same than “MyName.txt”, that is correct but the displayed name remains different.

For sample: if you search in Windows File Explorer for myname you will get all files called myname.txt, MyName.jpg, etc, etc. BUT the file name displayed is the correct one for each file as the user named it.

If I create a file browser with Xojo and include an option to search I would get myname.txt, myname.jpg and this is NOT the same result.

This difference is very important, it’s not the same john smith.jpg than John Smith.jpg, the second name can be used for many purposes, the first one not.

[quote=159581:@Alejandro Fresno Meyer]I’m using Windows 8.1 and Xojo 2014R3.1.

There is no space between the path and the file name, it’s only that the file name is “Mytest Name.tiff” as many other files in Windows.

I understand that there is no case sensitivity in Windows file names, the file “myname.txt” is the same than “MyName.txt”, that is correct but the displayed name remains different.

For sample: if you search in Windows File Explorer for myname you will get all files called myname.txt, MyName.jpg, etc, etc. BUT the file name displayed is the correct one for each file as the user named it.

If I create a file browser with Xojo and include an option to search I would get myname.txt, myname.jpg and this is NOT the same result.

This difference is very important, it’s not the same john smith.jpg than John Smith.jpg, the second name can be used for many purposes, the first one not.[/quote]

What I am trying to say is that folderitem is simply case insensitive. You may want to file a feature request if you think DisplayName should show the case. Or a bug report if you think a folderitem should be case sensitive.

Now if you need the name as it appears on your screen, one obvious workaround is to shell to

DIR "Mytest Name.tiff"

and parse the result.

Thanks, I can get the correct name by comparing folderitem.item(n).nativepath of the files in the same folder with the searched nativepath; item(n).nativepath is displayed correctly.