Line feed eliminieren aus textfeld (script)

[LordMacBee]

Hallo zusammen,

Ich versuche vor dem Export eines oder mehrere Textfelder in ein tabelliertes flat file, eventuelle carriage returns / line feeds zu eleminieren.

Normalerweise kein Problem durch einfügen eines berechneten Feldes in die Maske, welche @newline mit "" replaced.
Leider ist das keine option und ich muss mich mit script daran machen.

Das Problem ist, dass sich die Chr(10) und Chr(13) wohl nicht einfach bafangen lassen, resp. es nicht immer so klar scheint, ob es sich um ein Chr(10) oder Chr(13) handelt  

Der Grund, warum ich die line feeds eleminierung muss ist, dass excel beim import völligen Blödsinn generiert, weil es versucht diese Sonderzeichen zu eleminieren.

Gibt es eine performante Möglichkeit, die line feed exakt zu identifizieren?

[koehlerbv]

Wenn Du nicht Millionen von Dokumenten exportieren musst, kannst Du die primitiv-brutale Methode verwenden:
- Feld in String einlesen
- String einer Function übergeben, die sich Zeichen für Zeichen des Strings holt und an den Ergebnisstring anhängt - solange es nicht Chr$ (10) oder Chr$ (13) ist.
Nenn' das Teil dann "GetAllowedChars" und erweitere es gleich so, dass Du beliebige Zeichenketten als Parameter übergeben kannst, die Du aus Strings eliminieren willst:

Function GetAllowedChars (szForbiddenChars as String) as String

HTH,
Bernhard

[LordMacBee]

Yep... danke. das habe ich bereits gemacht.
Leider muss ich aber recht viele Dokumente exportieren und deshalb kommt die Zeichen für Zeichen Version nicht in Frage.

Ich hatte mir auch schon überlegt mit Instr zu prüfen, ob chr10 oder chr13 vorkommen, aber das bringt auch nicht die gewünschte erleichterung. Vor allem prüfe ich dann ja doppelt, wenn die Zeichen wirkich vorkommen. Die Performance ist das hauptoroblem hier...

Gibt es einen anderen weg, sich den text zu holen, damit diese blöden sonderzeichen einfach rausfallen? (so wie z.B. im web... dort muss man ja bei textfelder extra parsen, damit man ein <br> tag kriegt)

Gibt es vielleicht was undokumentiertes in der NoteItem Klasse, was mir weiterhelfen könnte?

[koehlerbv]

Hm, das bottle neck File-I/O für den Export schlägt doch um ein Vielfaches heftiger zu als eine derartige LS-Routine ... Um wieviele Dokumente und Felder darin handelt es sich denn ? Werden die Dokumente per Hand angelegt ? Wenn ja, kannst Du ja pro betreffenden Feld gleich noch ein verstecktes berechnetes Feld "mit ohne" line feeds erzeugen.

Bernhard

[LordMacBee]

Es sind ca 100000 schon bestehende Dokumente mit jeweils ca 75 feldern, welche leider nicht mehr angefasst werden dürfen. Eben... kein berechnetes Feld....

[Semeaphoros]

Einmalig oder wiederkehrend?

Wenn das so restriktiv ist, würde ich mir überlegen, mit irgendwelchen selbst erfundenen "Datensatz-Trennern" das in ein ASCII File ohne Konvertierung rauszuschreiben und dann entweder mit einem Konvertierungstool/programmierbarem Editor das File zu wandeln und dann ins Excel zu füttern. Normalerweise schreib ich dann den Filter dazwischen in TurboPascal / Delphi rasch selber, solche Dinger sind dann absolut performant ......  bei einmaligen Sachen würde ich schon so vorgehen, wie Bernhard beschrieben hat, das Ding lässt sich ja dann über x stunden laufen lassen ....

[koehlerbv]

Semeaphoros' Vorgehen ist auch eine absolut denkbare Lösung - solltest Du in Erwägung ziehen !
Da das Thema ein sehr interessantes ist, habe ich eben mal ein paar Tests gemacht (lokaler Client auf Celeron 2,3 GHz, 80er Platte - alles also Durchschnitt):
100.000 mal Durchlauf durch eine Function
GetAllowedChars (szOriginal as String, szForbiddenChars as String) as String,
wobei szOriginal 100 Zeichen umfasste und szForbiddenChars 2 Zeichen.
Laufzeit: 33 Sekunden.
Wenn ich dem jetzt entgegenrechne:
- Dokument instantiieren und auslesen
- Werte ins Export-File schreiben,

dann kann die Brachialmethode mit GetAllowedChars einfach nicht wesentlich ins Laufzeitverhalten eingreifen - bottle necks liegen garantiert ganz woanders.

Bernhard

[LordMacBee]

Danke.... das ist eine äusserst nützliche information

wir werden das wohl mal so implementieren....

Danke an alle