The problem is that when run from the command line, it will correctly process files with extended chars (non English alphabet if you will) in the name/path. When run as a Tk GUI, it won't! (see this post for my initial worries).
In other words, SOMETHING in Tk changes the runtime environment such that the encoding of filepaths, either entered manually, found by readdir, or selected in Tk::getOpenFile are not recognized as valid paths by any common Perl file operation (-f, -d, open, etc)!!
I can pull some tricks to make the filepaths digestable to Linux and OS-X, and some even more diabolical ones to partially address the Windows situation, but this will NEVER be a fix because the problem is so low-level that using Tk::getOpenFile to select files fails internally when trying to open a directory with extended chars in the name. The list box has shown the directory, but when you double-click to enter it, an error dialog is generated by getOpenFile saying the file does not exist.
I know how to fix this, but I'm not about to start hacking Tk as a past-time. It appears to me that there is a fundamental problem with Tk and extended chars in filenames. I also can't believe I'm the first to encounter this, but I can't find any posts on any forums that mention this problem specifically.
If any Monk can point me at something that helps, or suggest a different forum where Perl Tk is might get better coverage, I'd sure appreciate it.
I've not included a demo program due to the difficulty of including/creating the necessary test data, but if anyone is serious about assisting, I'm happy to create a little tar with example code and data.
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |