1

When trying to get a Shellfile from file path using WindowsAPICodePack, (Which I use to get a thumbnail from) it works fine until it gets passed a file with a non-english (specifically Japanese) filename.

            using (FolderBrowserDialog SelFolder = new FolderBrowserDialog() )
            {
                if (SelFolder.ShowDialog() == System.Windows.Forms.DialogResult.OK )
                {
                    Files = Directory.GetFiles(SelFolder.SelectedPath);
                    Files = Weld(Files, GetSubfolders(SelFolder.SelectedPath));
                }
            }

Up there is the code I use to get every file from a folder and its subfolders.

ShellFile shellFile = ShellFile.FromFilePath(Path.GetFullPath(Files[Count]));

And then this is the code that throws an exception. It runs fine for over 1000 files, but only stops on Non-English characters. Special characters do not throw an exception. I tried using Path.GetFullPath as it seemed like it might've worked but alas it didn't.

I don't see anyone else with this problem. Is there a fix?

BBonless
  • 97
  • 7
  • Does [setting the Culture make any difference](https://learn.microsoft.com/en-us/dotnet/api/system.globalization.cultureinfo.currentculture?view=netcore-3.1)? And what is the file name? Can you browse to the File Path in Windows? What is the exception? Does ProcessMonitor show the Path can be found? Does the Japanese file even have a thumbnail, can you Try/Catch or do you really need it because you would have to make your application global/culture neutral, this could be the tip of the iceberg. – Jeremy Thompson Jul 07 '20 at 05:23
  • @JeremyThompson Setting the culture didn't seem to make a difference. There are many files, but for example just a test file called 'あ.mp4' threw an exception. I can navigate to these files in most places, however CMD/Powershell do not open it, and foreign characters render as unknown. I'll be using a try/catch for now but It'd be nice to be able to have these files without much more hassle like renaming all of them or something. – BBonless Jul 07 '20 at 13:21
  • This is a broader problem, it's to do with the Win32 API AFAIK. Google stuff like "multi language Win32 file system calls". You have a choice now, make the app completely global or not? – Jeremy Thompson Jul 07 '20 at 13:52
  • @JeremyThompson Welp, it actually seems to be that I was going 1 item over the amount of items in my array of files. It never told me it was an index out of range exception making it not very obvious. The reason I thought it was breaking on Japanese files is because they appear at the very end of the list alphabetically, so when it reaches the end and the index goes out of range, those files would be the last shown. Sorry for wasting your time. – BBonless Jul 07 '20 at 15:33

1 Answers1

0

Seems to actually have been an IndexOutOfRange Exception. Fixed by -1 on a for loop

BBonless
  • 97
  • 7