Programmierung

Im Titel der CONZEPT 16-Druckvorschau werden Umlaute nicht korrekt dargestellt.

In regelmäßigen Abständen erreicht uns der Hinweis, dass im Titel der Druckvorschau die Umlaute fehlen oder stattdessen Sonderzeichen dargestellt werden.


Bei der Druckvorschau handelt es sich um ein Systemdialog, der von CONZEPT 16 erzeugt wird, wenn der Programmierer das Druckergebnis über die Anweisung PrtJobClose(_PrtJobPreview) auf dem Bildschirm ausgibt.

Der Dialog enthält die notwendigen Schaltflächen für das Drucken und Verändern der Druckansicht. Bis zu einem gewissen Grad lässt sich das Fenster der Druckvorschau individuell anpassen. So ist es unter anderem möglich die von CONZEPT 16 vorgegebene Beschriftung der Titelzeile und Schaltflächen zu ändern. Im Zuge der Weiterentwicklung von CONZEPT 16 in Richtung Unicode, erwartet die Druckvorschau seit der Version 5.4 die übergebenen Zeichenketten im UTF-8 Zeichensatz.
Bei der Verwendung von Strings die nicht im UTF-8 Format vorliegen, können zum Beispiel Umlaute nicht dargestellt werden. Für eine Lösung gibt es zwei Wege. Zum einem kann der Entwickler die Zeichenkette vor der Zuweisung mit der Funktion StrCnv(...,_StrToUTF8) nach UTF-8 wandeln, oder er setzt die Flags-Eigenschaft des Application-Objekts (_App) auf _WinAppPrtJobPreviewC16. Letzteres bewirkt, dass die Druckvorschau die Zeichenketten im CONZEPT 16-Zeichensatz erwartet und somit keine Konvertierung notwendig ist. Bei der Option _WinAppPrtJobPreviewC16 handelt es sich um eine globale Einstellung, die zur Laufzeit nur einmal gesetzt werden muss.

5 Kommentare

5 Kommentare “Im Titel der CONZEPT 16-Druckvorschau werden Umlaute nicht korrekt dargestellt.”

  1. Kommentar – Teil 2

    Was ich mich nun aber frage ist folgendes: Die Anweisung StrCnv(StrCnv(…, _StrToUTF8), _StrFromANSI) sollte doch – so wie sie notiert ist – zuerst die _StrToUTF8-Konvertierung und erst *danach* die_StrFromANSI-Konvertierung durchführen, oder? Genau dies ist es ja, was mich eigentlich ursprünglich verwirrt hat. Wieso muss *nach* einer UFT8-Konvertierung noch eine weitere Konvertierung stattfinden, obwohl die Druckvorschau mit UTF8-Strings umgehen kann.

    Nach Ihrer Erklärung hätte ich übrigens erwartet, dass die korrekte Anweisung lautet: StrCnv(StrCnv(…, _StrFromANSI), _StrToUTF8).

    Freundliche Grüsse
    Kilian Kwaschik

  2. Kommentar – Teil 1

    @Andreas

    Vielen Dank für die Antwort.

    Leider verstehe ich noch nicht ganz, was eigentlich abläuft. Ich entnehme Ihren Ausführungen, dass ein String-Literal im Prozedurtext offenbar nicht im C16-Zeichensatz, sondern im Windows-Zeichensatz vorliegt. Da die UTF8-Konvertierungsfunktion nur C16-Zeichensätze verarbeiten kann, muss vorher eine entsprechende Konvertierung stattfinden. Soweit alles klar.

  3. @Kilian

    Die Funktion StrCnv() erwartet als Quell-Zeichensatz den CONZEPT 16-Zeichensatz. Daher muss der String vor der Umwandlung nach UTF-8, vom Windows- in den CONZEPT 16-Zeichensatz konvertiert werden.

    Die Druckvorschau kann Strings verarbeiten, die im UTF-8-Format übergeben werden. Das lässt sich überprüfen, in dem der Eigenschaft ppCaption ein UTF-8-String zugewiesen wird.

    Beispiel:
    tPreView->ppCaption # ‘Müller’

    Weiterführende Informationen zu Verwendung von Zeichensätzen finden Sie auch im Kapitel "Zeichensätze" der CONZEPT 16-Hilfe.

  4. Hallo,

    ich hatte kürzlich genau dieses Problem der fehlenden Umlaute in der Druckvorschau. und habe nach einigem Hin und Her die angesprochene Lösung gefunden. Allerdings genügte es nicht, die Zeichenkette mit StrCnv(…, _StrToUTF8) zu wandeln, sondern es musste (merkwürdigerweise) doppelt konvertiert werden: StrCnv(StrCnv(…, _StrToUTF8), _StrFromANSI). Können Sie erklären, wieso das Fenster für die Druckvorschau dann doch nicht mit UFT-Strings fertig wird?

    Die integrierte Hilfe ist leider nicht eindeutig was dieses Thema betrifft, es gibt zum Einen die Hilfeseite "_PrtFrame", in der dasselbe steht wie hier im Blog (also 1x in UTF8 wandeln), zum Anderen die Seite "_WinAppPrtJobPreviewC16", auf der man die korrekte Lösung findet (also 2x wandeln wie oben beschrieben).

    Freundliche Grüsse
    Kilian Kwaschik

Kommentar abgeben