Diese Seite mit anderen teilen ...

Informationen zum Thema:
Forum:
WinDev Forum
Beiträge im Thema:
10
Erster Beitrag:
vor 2 Jahren, 3 Monaten
Letzter Beitrag:
vor 2 Jahren, 3 Monaten
Beteiligte Autoren:
DarrenF, Peter Holemans, Fabrice Harari, CCC2

[WDM20] Problem with Chinese characters...

Startbeitrag von DarrenF am 08.03.2016 13:32

Hi guys,

I've got an issue with Chinese characters appearing when I read a (text) CSV file!

When I open the CSV file in the Android app in GO mode, then use fReadLine, I can't get to the bottom of why it didn't seem to be working as expected. When I added a Trace command I discovered that the Trace(sCSVRow) line of code below displays as Chinese characters: :confused:
(Note: the RETURN at the end is just so the rest of the processing doesn't execute - it's just for trying to trace this issue)


sFullFileName is string = fDataDir() + "/" + sFileName
nFileNum = fOpen(sFullFileName)

// Was the file opened or was there an error?
IF nFileNum = -1 THEN
// Display error message and go back to the button
ToastDisplay("Error: File was not found in " + fDataDir(),toastLong,vaMiddle,haCenter)
// Enable plane 0 (main) after error
WIN_Data_Import..Plane = 0
// Return to specific screen object
ReturnToCapture(BTN_Course_Material)
ELSE

// Read the first row and throw it away - it's just headers
sCSVRow = fReadLine(nFileNum)
Trace("This appears in non-Chinese chars!")
Trace(sCSVRow)
RETURN


I've looked at the project settings, but can't see why this would be happening. The text file, when opening notepad or Notepad++ looks fine :confused:

Any idea where I can look?

Antworten:

Hi Daren

you have an ansi/unicode problem.

Windows is ansi, android is unicode, and you are declaring your string as string, instead of specifying ansi or unicode, so basically you don't know what kind of file you are dealing with and how.

Best regards

von Fabrice Harari - am 08.03.2016 13:46
Thanks Fabrice! I thought it would be an ANSI/Unicode issue, but silly me... I was expecting (...more like "hoping") that WDM would realise that I was developing in Windows and deploying via an Android project :cheers:

von DarrenF - am 08.03.2016 14:14
Hi Darren,

in android , Watch out for UTF8

UTF8 is not UNICODE

:D:D:D:D:D:D:D:D:D:D

von CCC2 - am 08.03.2016 15:49
Thanks!

I'm so used to developing in WD for Windows that I'd forgotten about specifying the format of string vars :rolleyes:

von DarrenF - am 08.03.2016 16:10
Hi Darren,

I never specfify it at string level unless I'm interacting with something external that requires a conversion.
I specify the Unicode/Non-Unicode aspect always at configuration level.

A WD program for exemple can have a unicode/non-unicode configuration that compiel into a unicode supporting exe and a non-unicode supporting exe.

But anyway, I don't think I have create a non unicode program anymore since WX V18.
All my configurations are flagged as unicode.
When doing Windows API calls I use the ASCIIZ string type mostly but I am noticing that on the newest Windows 64 bit server platforms almost all API's hava a unicode variant as well.

Just my 2 cents,

Peter Holemans

von Peter Holemans - am 08.03.2016 20:51
Thanks Peter - point taken and worth knowing. :xcool:

For this test app I've just saved the external file as Unicode and defined the string I'm reading into as Unicode also - now I'm getting somewhere :cheers:

von DarrenF - am 08.03.2016 21:10
Hi Peter,

I think that your method is dangerous, so I always specify the type of string when declaring them. This is why:
- I'm sharing code between project (classes by example)
- some of these projects are for customers who are used to work in ansi (historical reason, no need of unicode, etc)
- some of these projects are for environments/cases where unicode can creates problem (web/web service/etc.)
- and most of the projects are very happy in unicode

So If I rely on the configuration settings and import a class from another project, I suddenly have to verify everything done in the imported class, as I cannot be sure that the original project had the same configuration settings. Instead, I use the following in my declarations:
usString is unicode string
asString is ansi string
ccsString is string

This way, I always know, when I work on a string, if it is unicode, ansi or (ccs) configuration coded. The ccs case is used for cases like the return or external function, when I know that depending on the system the code is running on, I'll get a string of a different type.

Best regards

von Fabrice Harari - am 09.03.2016 12:44
Hi Fabrice,

Thanks for the heads up but I am not sure I understood your remark completely as I never had the same potential issue tipping point as you describe...

I tend to manage this at configuration level (ansi or unicode excutable) rather than at the declaration point of individual variables which makes it a tedious job to alter between them for the same source code imho. (Or I don't understand what you are trying to say which is also possible... :-))

I also have classes shared between unicode and ansi projects and they either compile into an executable as ansi or unicode depending on the targetted configuration I am generating to. In both cases, the class will work for me identical in ansi and unicode configurations and within different projects. And in there, strings just remain strings. Only at executable level they become ansi or unicode.

When I really need to make sure that a conversion is done because of integrating with external software or API calls I do an explicite test and declare the string types explicitely depending on the mode I am in... I need to verify my code (no WX at hand here) but I believe it something like "if InUnicodeMode() then ...". Eitehr they declarea as ansi, either as unicode...

I 'll provide an example later on if you want.

If I miss understood your point, thanks for enlightening me but I never had the issue you seem to describe.

Cheers,

Peter

von Peter Holemans - am 09.03.2016 14:34
Hi Fabrice,

Thanks for the heads up but I am not sure I understood your remark completely as I never had the same potential issue tipping point as you describe...

I tend to manage this at configuration level (ansi or unicode excutable) rather than at the declaration point of individual variables which makes it a tedious job to alter between them for the same source code imho. (Or I don't understand what you are trying to say which is also possible... :-))

I also have classes shared between unicode and ansi projects and they either compile into an executable as ansi or unicode depending on the targetted configuration I am generating to. In both cases, the class will work for me identical in ansi and unicode configurations and within different projects. And in there, strings just remain strings. Only at executable level they become ansi or unicode.

When I really need to make sure that a conversion is done because of integrating with external software or API calls I do an explicite test and declare the string types explicitely depending on the mode I am in... Next either I declare as ansi, either as unicode...

This way a unicode configuration will compile into a unicode exe and an ansi configuration will compile into an ansi exe in WD.

If I miss understood your point, thanks for enlightening me but I never had the issue you seem to describe.

Cheers,

Peter

von Peter Holemans - am 10.03.2016 08:29
Zur Information:
MySnip.de hat keinen Einfluss auf die Inhalte der Beiträge. Bitte kontaktieren Sie den Administrator des Forums bei Problemen oder Löschforderungen über die Kontaktseite.
Falls die Kontaktaufnahme mit dem Administrator des Forums fehlschlägt, kontaktieren Sie uns bitte über die in unserem Impressum angegebenen Daten.