Watch, Follow, &
Connect with Us

QualityCentral

Public Report
Report From: Delphi-BCB/FireMonkey/Dialogs    [ Add a report in this area ]  
Report #:  99841   Status: Open
[MacOS] TOpenDialog can't correctly return file names with non-ASCII characters
Project:  Delphi Build #:  16.0.4276.44006
Version:    16.1 Submitted By:   Chris Rolliston
Report Type:  Basic functionality failure Date Reported:  10/9/2011 6:42:40 PM
Severity:    Critical / Show Stopper Last Updated: 3/20/2012 3:49:25 AM
Platform:    All Mac platforms Internal Tracking #:   26519
Resolution: Duplicate (Resolution Comments) Resolved in Build: : None
Duplicate of:  98480
Voting and Rating
Overall Rating: No Ratings Yet
0.00 out of 5
Total Votes: 20
Description
[MacOS]
Partly due to the (bad) assumption that Cocoa to Delphi string conversions must go via UTF-8 intermediaries, line 2661 of FMX.Platform.Mac.pas does a direct PAnsiChar to string cast as it returns the chosen file name. Notwithstanding the fact this is bad coding style in the first place (if you must go via UTF-8, use UTF8ToUnicodeString), it causes corruption of the returned file name if it contains non-ASCII characters (e.g. one or more accented letters, let alone anything truly exotic from an Anglophone POV), and the GetACP function of System.pas has failed to return CP_UTF8, which it doesn't on my iMac (if this function can't get anything sensible from the OS, it defaults to Windows Latin-1).
Steps to Reproduce:
1. Using (say) TextEdit, create a text file called caf·txt on your Mac (note the accent).
2. In Delphi, create a new FireMonkey HD application, and drop a TMemo, TButton and TOpenDialog on the form.
3. Handle the button's OnClick event by executing the dialog, and passing on the chosen file to Memo1.Lines.LoadFromFile.
4. Target OS X, run the application, and try to load the text file created in step 1. If you can, then good for you, but for me there's a big problem - the file name returned by the dialog is corrupted, leading to the LoadFromFile call to raise an exception.
Workarounds
None
Attachment
None
Comments

Tomohiro Takahashi at 10/9/2011 7:46:40 PM -
Could you please attach sample project(including sample text file) to verify your issue?

> ...  LoadFromFile call to raise an exception.
Is the exception 'EFOpenError'?
Is your issue same as QC#98480 ? If you are a FieldTester, you can see the report.

Francois GAILLARD at 10/10/2011 3:02:07 PM -
Care to explain what you don't understand in the given steps to reproduce the problem?

Tomohiro Takahashi at 10/10/2011 6:22:14 PM -
> ...  LoadFromFile call to raise an exception.
Is the exception 'EFOpenError'?

Note:
This issue is already logged as QC#98480. We hope it will be fixed in future update release.

Chris Rolliston at 10/13/2011 3:11:00 PM -
It is indeed EFOpenError, since the file name string has been corrupted by the code I identified in my report. I've no idea whether this is the same issue as the one in report no. 98480, since I can't access it (the IDE client comes up with a blank, and the web client comes up with 'either there is no report #98480, or you are not authorized to see that report'). Are you and your superiors just trying to waste my time?

As for 'hoping' for the fix - really now, it's not like the required change is rocket science. Either avoid the roundtrip conversion in the first place, or (if you must) call UTF8ToUnicodeString, as I suggested.

Chris Rolliston at 11/6/2011 1:37:17 PM -
Update 2 has fixed the immediate problem - i.e., TOpenDialog can now return file names with non-ASCII characters. However, I would still like the GetACP issue at least documented (surely there's a reason, given the difference with the old Kylix behaviour), and the recourse to UTF-16->UTF-8->UTF-16 roundtrips should be got of IMO.

Tomohiro Takahashi at 11/6/2011 4:38:38 PM -
Yes, this issue should be fixed in Update 2.
So, if you still have any problem, could you please put new QC report about it?

Chris Rolliston at 11/6/2011 1:57:51 PM -
Er, that was supposed to be 'got rid of IMO'...

Server Response from: ETNACODE01

Copyright© 1994 - 2013 Embarcadero Technologies, Inc. All rights reserved.