Steuerzeichen werden gedruckt

Hallo in die Runde.
Ich habe bislang mit der Druckfunktion meiner App keine Probleme gehabt. Jetzt, nach dem Umstieg auf Xojo wird bei langen Texten mit Zeilenumbruch kein Zeilenumbruch erzeugt, sondern ein entsprechendes Zeichen ausgegeben.

Ich bin nicht sicher, wo ich bei der Suche ansetzen soll. Hat jemand eine Idee, wo sich diesbezüglich bei Tojo gegenüber REALstudio etwas geändert hat?

Gruß, Stefan Mettenbrink.

Mac?

Sorry, hatte ich nicht erwhnt.

Ja, hier auf dem Mac ist es definitiv so. Hier eine Beispielsausgabe als PDF:
http://www.familienbande-genealogie.de/Test/FBWin.zip
link text

Gru, Stefan Mettenbrink.

EndOfLine auf OS X hat gewechselt von EndOfLine.Mac zu EndOfLine.UNIX. D.h. wenn Du das “nackte” EndOfLine gebraucht hast, musst Du .UNIX dahinter setzen.

Vielen Dank für die Info.
Ich habe gerade nachgesehen, unter Windows sind die Zeilenumbrüche vorhanden. Scheint also daran zu liegen.

Ich habe bislang immer das nackte EndOfLine benutzt. Ich dachte, es wird dann immer das genutzt, welches für das System korrekt ist. Muss ich jetzt doch wieder ein lokales EndOfLine anlegen und dort den korrekten Code nach Systemprüfung eintragen? Das wollte ich durch Nutzung von EnOfLine eigentlich vermeiden.

Gruß, Stefan Mettenbrink.

Bei Cocoa-Projektem musste man von der ersten Beta an EndOfLine.UNIX angeben um die korrekten Zeilenumbrüche zu erhalten.

Also muss ich jetzt doch bei Programmstart das System prüfen und klären, welches EndOfLine ich benötige?

Nach der Language Reference ergibt EndOfLine: The end of line String for the platform being compiled.

Also würde ich jetzt nicht erwarten, dass ich nun für Mac OS ein “.Unix” anhängen muss um einen Zeilenumbruch auch als solchen zu bekommen. Das sieht mir eher nach einem Fehlverhalten von Tojo aus.

Hat dazu noch jemand Informationen/eine Meinung?

Gruß, Stefan.

Die LR sagt auf der gleichen Seite, wieso bei Cocoa-Projekten ein .UNIX angehngt werden muss.

Wozu benötige ich ein EndOfLine ohne Zusatz, wenn es nicht sauber das für das aktuell verwendete System den richtigen Wert zurück liefert?

Cocoa ist bei allen 32-Bit Projekten voraus zu setzen?

Ich lese den Text anders: EndOfline ergibt seit 2013r1 EndofLine.Unix auf Mac, weil Cocoa-Apps das Unix-EOL benutzen. Für “legacy” EndOfLine muss man explizit EndofLine.Macintosh angeben.

Davon aber abgesehen: Kontrolliere doch einmal die Codierung des Anhangtextes. Da sind ja nicht nur die Returns verschluckt, sondern auch alle Umlaute. Ich würde drauf tippen, dass der Fehler eher in einem falschen Encoding zu suchen ist. Das richtige EndOfLine müsste sich dann von selbst ergeben.

Ja, die falsch codierten Umlaute habe ich auch bemerkt. Allerdings hatte ich hierzu eine andere Ursache im Hinterkopf.

Ich werde mal nachsehen, ob das zusammen hngt.

Danke fr den Hinweis!

Gru, Stefan Mettenbrink.

Ein ReplsceLineEndings Aufruf kann da Wunder bewirken und die Zeilenenden korrigieren.