SVG_New_textArea et SVG_SET_TEXTAREA_TEXT caractères < et >

bonjour,
en 4dv17r7 32 et 64 bits
lorsqu’un texte contient le caractère < suivi de > ,avec les commandes SVG_New_textArea et SVG_SET_TEXTAREA_TEXT,
le texte ne peut pas s’afficher >4D : v13.2
le XML est mal interprété par les commandes

exemple:
Application par circulation :
Concentration bactéricide : 1.4%
Température : < 60°C
Temps de contact : >5 minutes
Rinçage final à l’eau potable
A utiliser avec précaution sur métaux légers

Bonjour Sylvain,
c’est “réservé”, en xml. De mémoire, il faut les remplacer, “<” par “& lt;” et “>” par “& gt;” (sans les espaces)

Bonjour Arnaud,
J’ai déjà tenté le coup mais cela écrit & l/gt;

Sylvain

Bonjour,

Je viens de vérifier… et de reproduire le problème.

Le bug est enregistré sous le Nº ACI0100277, dors et déjà fixé dans notre version de développement et sera disponible dans les version courantes dès que la qualité aura testé la non regression et demandé le report.

En attendant, la solution proposée par Arnaud vous permet de contourner le problème.

Merci de votre aide

Ja, rechtsbündige Texte zu manipulieren, ist keine Freude.
Probieren Sie mal ein ZERO WIDTH SPACE am Ende.

<code 4D>
SVG_New_textArea ($vtSvgRef;"Test "+char(8203);0;0;300;50;“Arial”;12;0;Align right)

</code 4D>

Übrigens liefert Char(NBSP ASCII CODE) bei mir kein umbruchgeschütztes Leerzechen, sondern ein E mit Zirkumflex. Denn die Konstante NBSP ASCII CODE liefert den Wert 202, aber das umbruchgeschützte Lerzeichen ist Char(160). Oder haben Sie noch keinen Unicode-Modus aktiviert? Im alten Mac-Zeichensatz war Char(202) das umbruchgeschützte Leerzeichen. Dann funktioniert mein Workaround allerdings auch nicht, denn das ZERO WIDTH SPACE gibt’s nur mit Unicode.

Super!
Vielen Dank Herr Buchwitz für den Tipp mit dem ZERO WIDTH SPACE! Ich
kämpfe damit jetzt schon eine ganze Weile herum und habe schon Code
geschrieben, der die Position des Strings über die Parameter 3 und 5
festlegt - funktioniert auch leidlich gut, aber Ihre Lösung ist doch
wesentlich einfacher.

Übergebe ich <code 4D>
Replace string($1;" ";Char(NBSP ASCII CODE))+Char(8203)
</code 4D> an SVG_New_textArea, werden Leerzeichen an allen Positionen
korrekt berücksichtigt.

: Joerg BUCHWITZ

Übrigens liefert Char(NBSP ASCII CODE) bei mir kein
umbruchgeschütztes Leerzechen, sondern ein E mit Zirkumflex. Denn die
Konstante NBSP ASCII CODE liefert den Wert 202, aber das
umbruchgeschützte Lerzeichen ist Char(160). Oder haben Sie noch
keinen Unicode-Modus aktiviert?

NBSP ASCII CODE liefert bei mir aber sowohl unter Windows als auch MacOS “160” zurück…??? … und doch - wir haben den Unicode-Modus aktiviert.

: Peter GRUN

NBSP ASCII CODE liefert bei mir aber sowohl unter Windows als auch
MacOS “160” zurück…??? … und doch - wir haben den Unicode-Modus
aktiviert.

ja, das ist korrekt.

Es ist eine Konstante, die zur Kompilationszeit mit einem festen Wert ersetzt wird.
Das ist immer der gleiche Wert, er kann sich nicht je nach einer anderen Bedingung ändern. Die Werte stehen hier:

https://doc.4d.com/4Dv17/4D/17.2/ASCII-Codes.302-4386145.de.html

Es gibt ab v17 R5 den Projekt-Modus und wenn man diesen wählt gibt es nur noch Unicode, aber nicht alle werden diesen Modus (gleich) verwenden. Also können wir diese Konstanten aus Kompatibilitätsgründen noch eine ganze Weile nicht ändern.

Hallo Herr Maul,

: Thomas MAUL

https://doc.4d.com/4Dv17/4D/17.2/ASCII-Codes.302-4386145.de.html
in dieser Liste fehlt aber “NBSP ASCII CODE”. Da wir in v17 die SVG-Komponente von v17R4 verwenden (sorry - hätte ich erwähnen sollen…), nehme ich an, dass diese Konstante erst in einem R-Release dazugekommen ist. Das erklärt auch den Unterschied zu Herrn Buchwitz…

… zu früh gefreut - unter MacOS klappt es bei rechtsbündigen Texten mit Leerzeichen am Ende nicht. Schade…

: Thomas MAUL

Die Werte stehen hier:
https://doc.4d.com/4Dv17/4D/17.2/ASCII-Codes.302-4386145.de.html

Hm, genau dort steht aber 202 und nicht 160, anscheinend ein Fehler in der Doku.
Außerdem steht dort nicht NBSP ASCII CODE sondern nur NBSP.

[]30246356;“NBSP - Lange Ganzzahl - 202”[/]

Ich hatte übrigens mit 4Dv15 getestet, dort ist NBSP ASCII CODE noch 202.
In 4Dv17.1 ist es dann 160.
Also Entwarnung: Man kann Char(NBSP ASCII CODE) nutzen, zumindest in 4Dv17.

danke für den Hinweis. Da gab es einen Fehler mit nicht zulässigen Zeichen im Konstanten-Namen. Wurde inzwischen behoben. Aktuelle Nummer ist 160. Nicht mehr in v15. Ich leite den Hinweis an die Dokumentation weiter.