You are here: PSPad forum > English discussion forum > Problems accessing files with surrogate pairs in their name
Posted by: aGerman | Date: 2016-12-28 19:56 | IP: IP Logged
First of all thank you for this great editor. I use it for years and really enjoy working with it.
Currently running Version 4.6.1 (2730) on Windows 10 (x86).
I possibly found a little bug. If you open a file whose file name contains UTF-16 surrogate pairs everything is okay as long as it is the first file opened in a virgin PSPad instance. But if you open a second file with those surrogates they show up as four question marks in the file tab and the file content is not shown in the editor. If you try to save the file it is considered to be a different file (as expected in this case).
Test files
Posted by: aGerman | Date: 2016-12-30 22:41 | IP: IP Logged
Hmm, actually I was waiting that either somebody confirms or disproves my observation. In most cases the actual problem is between chair and Keyboard Hence there was a good chance that I did something wrong.
Nevermind
@Jan Feel free to move the topic to the "Bug report" forum if you agree this is something that needs to be corrected.
Wish you all a peaceful time and a happy new year.
Steffen
Posted by: pspad | Date: 2016-12-31 09:53 | IP: IP Logged
PSPad works with UTF-16 only, not with a UTF-32. I am afraid I can't help you.
For handling unicode PSPad uses system conversion.
Posted by: aGerman | Date: 2016-12-31 14:58 | IP: IP Logged
Hi Jan.
Thank you for taking a look at it. It's not that PSPad can't handle UTF-16 (and surrogates). As the picture shows it works fine with a single file. It fails if you open a second file that contains surrogates.
Since Windows doesn't work with UTF-32 in its file system it's UTF-16 related only. And since it works with the first file it should also work with further files (imho).
Steffen
Edited 1 time(s). Last edit at 2016-12-31 14:59 by aGerman.
Posted by: Freeman | Date: 2017-01-03 05:44 | IP: IP Logged
Most probable, this is system-wide command line issue. Under Windows 7, I confirm this bug only when try to open a file from command line. When I open that file from Open dialog, all works okay.
If bug still in Windows 10, complain Microsoft on their system design. They'll suggest you PowerShell, I think.
Posted by: Freeman | Date: 2017-01-03 05:53 | IP: IP Logged
Hmmm... Or, if PSPad still built by Delphi 7, this can be ANSI-only ParamStr issue. To avoid it, you should get Unicode command line via GetCommandLineW() and then parse in manually with WideString-based functions.
When testing on surrogate-pair-named file, I had no problems with my program built by Delphi 6, but used GetCommandLineW function as I wrote above.
Posted by: aGerman | Date: 2017-01-03 17:25 | IP: IP Logged
Thank you Freeman
Freeman:complain Microsoft on their system design.
While there are more reasons to blame Microsoft than I can count this doesn't seem to be a Windows problem.
Freeman:... via GetCommandLineW() and then parse in manually with WideString-based functions
I'm pretty sure PSPad can already handle UTF-16 file names with surrogates. It only fails to open a second file with these surrogates in another file tab.
To day I remembered that I still had an old portable version (4.5.8) on Win7 x64 at work. This version opens both files - but for whatever reason in "read only" mode.
Then I downloaded the new version (4.6.1) that creates the same error on Win7 not openimg the 2nd file correctly.
In case you're wondering - normally I use those file names to test my own applications. So rather by a fluke I found that they don't work properly with PSPad. As long as you don't live in a Chinese environment you rather don't have to bother about it but But I thought it was worth to raise my hand.
Steffen
Editor PSPad - freeware editor, © 2001 - 2024 Jan Fiala, Hosted by Webhosting TOJEONO.CZ, design by WebDesign PAY & SOFT, code Petr Dvořák, Privacy policy and GDPR