Seite 1 von 1
ConvToOemCp in 2.0
Verfasst: Fr, 27. Mai 2016 11:27
von Jan
Ich stolpere gerade über ein merkwürdiges Problem. In einer Funktion zum berechnen der korrekten Strings für einen 128er Barcode gibt es am Ende diese Abfrage:
Code: Alles auswählen
IF SET(_SET_CHARSET) <> CHARSET_ANSI // Wieder zurück auf OEM, falls erforderlich
cCode128 := ConvToOemCP(cCode128)
ENDIF
Das macht dann unter 1.9 SL1 z. B. aus dem String "Ñ1335103ÌÓ" ein "¥1335103Þà". So soll das auch sein.
Aber wenn ich das unter 2.0 benutze kommt da ein "¾1335103è…" bei raus!
Das geht unter 2.0 nur so:
Code: Alles auswählen
IF SET(_SET_CHARSET) <> CHARSET_ANSI // Wieder zurück auf OEM, falls erforderlich
cDummy := ConvToOemCP(cCode128)
cCode128 := cDummy
ENDIF
Dann bekomme ich den korrekten String zurück.
Wie geht das denn?
Jan
Re: ConvToOemCp in 2.0
Verfasst: Fr, 27. Mai 2016 18:44
von brandelh
sehr seltsam, gleich mal als Fehler melden
Re: ConvToOemCp in 2.0
Verfasst: Fr, 27. Mai 2016 19:09
von Martin Altmann
Naja,
Du wandelst die Quelle direkt um (also schreibst in den Speicherbereich, von dem du liest). Sowas ist mir alleine vom Gedanken her eh suspekt (gerade, wenn man ASCII in UTF8 oder UTF16 wandelt und somit mehr Speicher braucht, als vorher - ist hier nicht der Fall, ich weiß. Aber trotzdem!)
Ist natürlich ärgerlich, wenn es nicht mehr so funktioniert, wie gewohnt.
Viele Grüße,
Martin
Re: ConvToOemCp in 2.0
Verfasst: So, 29. Mai 2016 12:48
von brandelh
Martin Altmann hat geschrieben:Naja,
Du wandelst die Quelle direkt um (also schreibst in den Speicherbereich, von dem du liest).
das stimmt nicht, erstens wird der Parameter per Copy und nicht per Referenz übergeben ( @cTxt wäre per Referenz ) und
zweitens erfolgt bei einer Zuweisung immer ein Umkopieren im Speicher der beide Kopien vorrätig hat.
c1 := c2 legt eine Kopie an, solange kein Array im Spiel ist.
c1[3] := "b" würde das Original bearbeiten ...
Also kein Grund für das seltsame Verhalten.
Re: ConvToOemCp in 2.0
Verfasst: So, 29. Mai 2016 13:25
von Martin Altmann
Hubert,
Deinem ersten Beispiel folgend, schreibt Jan aber c1 := c1!
Viele Grüße,
Martin
Re: ConvToOemCp in 2.0
Verfasst: So, 29. Mai 2016 19:13
von brandelh
Das spielt keine Rolle, c1 wird im neuen Speicherbereich erzeugt.
Du kannst ja mal vergleichen auf welche Speicheradresse beide c1 verweisen
Bei allen Zuweisungen wird zunächst (mit Klammerregeln) das Ergebnis aller Teile von rechts ausgewertet und im Speicher zwischengespeichert bzw. neu angelegt.
Danach wird der neue Inhalt (bei Strings als Adresse auf den Stringspeicher) an die Variable links weiter gegeben.
Re: ConvToOemCp in 2.0
Verfasst: Mo, 30. Mai 2016 6:47
von Jan
Der Punkt ist ja, daß das unter 1.9 SL1 immer funktioniert hat. Nur unter 2.0 irgendwelchen Kauderwelsch zurück gibt. Alaska muß da also irgendwas verändert haben.
Jan
Re: ConvToOemCp in 2.0
Verfasst: Mo, 30. Mai 2016 7:12
von brandelh
Bei mir funktioniert das auch unter 2.0 ...
Quellcode in ANSI ohne Compilerschalter etc:
Code: Alles auswählen
#include "Gra.ch"
#include "Xbp.ch"
#include "Common.ch"
#include "Inkey.ch"
#include "directry.ch"
#include "DLL.ch"
procedure main
local cCode128 := "¥1335103Þà"
? cCode128
IF SET(_SET_CHARSET) <> CHARSET_ANSI // Wieder zurck auf OEM, falls erforderlich
cCode128 := ConvToOemCP(cCode128)
? "conv",version()
ENDIF
?
? "¥1335103Þà"
? "¾1335103è…" // JA WAS IST DENN DAS ???? So steht es im Quellcode: "¥1335103Þà"
?
? cCode128
inkey(20)
return
In meinem Test Quellcode (Ansi Eingabe, normal compiliert) steht da genau das was du oben geschrieben hast.
Nach Paste im Forum wird daraus ¾, eintippen mit ALT+190 gibt aber ¥ ...
In meinem Editor sind beide Zeichen mit chr(190) belegt, je nach Schriftart kommt dann ¾ oder ¥ raus
Aber wie gesagt bei mir ist das Ergebnis unabhängig vom Compiler gleich (EXE aus Explorer gestartet).
Re: ConvToOemCp in 2.0
Verfasst: Mo, 30. Mai 2016 10:04
von Herbert
Martin Altmann hat geschrieben:Naja,
Du wandelst die Quelle direkt um (also schreibst in den Speicherbereich, von dem du liest). Sowas ist mir alleine vom Gedanken her eh suspekt (gerade, wenn man ASCII in UTF8 oder UTF16 wandelt und somit mehr Speicher braucht, als vorher - ist hier nicht der Fall, ich weiß. Aber trotzdem!)
Ist natürlich ärgerlich, wenn es nicht mehr so funktioniert, wie gewohnt.
Ich denke, Martin hat recht. Da hat man offenbar intern bereits Vorbereitungen auf Unicode getroffen. Nur das erklärt meiner Meinung nach diesen Fehler.
Re: ConvToOemCp in 2.0
Verfasst: Mo, 30. Mai 2016 10:13
von Jan
Herbert,
interessante Idee. Die würde aber bedeuten, das damit dann bestehender Code massiv gebrochen wird.
Wie auch immer: Ich hab das letzte Woche als Ticket an Alaska geschickt. Mal sehen was die dazu sagen. Diese Woche müsste Till wieder Support-Dienst machen ... Mal schauen was Alaska dazu sagt.
Jan
Re: ConvToOemCp in 2.0
Verfasst: Mo, 30. Mai 2016 10:15
von Martin Altmann
Jan,
gedacht gewesen wird das so nicht sein - sie werden einfach etwas übersehen haben (z.B. auf die Art vorzugehen, wie Du das gemacht hast).
Viele Grüße,
Martin