Domino 9 und frühere Versionen > Entwicklung

Anzahl der Zeichen in einem Textfeld!!!

<< < (6/7) > >>

Axel:

--- Zitat von: koehlerbv am 01.10.05 - 00:46:20 ---Hi, Axel,
irgendwie hast Du da jetzt aber eine Widerspruch drin mit einmal Chr$ (13) und dann Chr$ (10). Code 10 (dezimal) ist der normal verwendete in Notes. 13 kann aber auch vorkommen (vorrangig von aussen - Notes ist da "grosszügig" ;-) - daher sollte man beide Codes abfragen.

--- Ende Zitat ---

Jein. Chr$10 verwende ich eigentlich immer wenn es um mehrzeilige Messsageboxen geht. (eigentlich weil, ich auch schon einige Messagebox-Texte mit Chr$(13) gefunden habe  :o  ).

Bisher bin ich mit der Abfrage nur nach Chr$(13) ganz gut gefahren. Ich habe damals, als der Code entstand, einiges getestet und Chr$(13) war das einzigste was richtig und immer funktioniert hat. Sicherlich schadet es nichts noch auf Chr$(10) zu prüfen.


--- Zitat von: voigt am 30.09.05 - 17:09:58 ---Hi Axel,

vielen Dank für Deine Lösung. Habe nun einmal die Formel getestet leider bringt er mir folgenden Fehler:

ProblemDescriptionNoUpdate: Querysave: 19: Not a sub or function name: UIDOC

Gruß
Steffen

--- Ende Zitat ---

Hier fehlt die Deklaration der Variablen uidoc. Du kannst anstatt der Variablen uidoc auch die Variable Source nehmen. Die ist in den meisten Maskenevents bereits vorhanden.

Das Beispiel war ein Auszug aus einem kompletten QuerySave-Event - Script und nur als Denkanstoß gedacht und nicht als fertige Lösung. Ich bin eigentlich davon ausgegangen, dass du weißt, wo und wie man die benötigten Variablen deklariert und initialisiert.

Axel
 

koehlerbv:
Hi Axel,

ich habe eben einer meiner Standardroutinen (man verwendet die ja - leider - irgendwann dann doch ohne weiteres Nachdenken) nochmal geprüft. Die Routine soll in bestimmten und hierfür relevanten Textfeldern die Eingabe einer Zeilenschaltung verhindern (Aufruf der Routine im Querysave, der Ausschnitt stammt aus einer Function namens ValidateMandatoryFields - der Function-Name sagt sicherlich alles):


--- Code: --- 'In the following fields carriage returns are not allowed:
For iLoop = 0 To Ubound (aNoCR)
szTemp = uidocCurrent.FieldGetText (aNoCR (iLoop))
If Instr (szTemp, Chr$ (10)) > 0 Or Instr (szTemp, Chr$ (13)) > 0 Then
Messagebox "Im Feld '" & aNoCR (iLoop) & "' sind keine Zeilenschaltungen erlaubt !", MB_ICONEXCLAMATION, "Eingabefehler"
Call uidocCurrent.GotoField (aNoCR (iLoop))
Exit Function
End If
Next

--- Ende Code ---

Egal, ob ich in der betreffenden Zeile jetzt den Check auf 10D oder 13D auskommentiere - die Prüfung schlägt immer zu.

Ich muss nochmal nachvollziehen, wie Notes in den einzelnen Situationen die Werte verwendet: In LS reicht für einen Zeilenumbrauch (auch in einem RTI) immer 10D, aber ich bin mir sicher, bei @functions braucht es statt dessen irgendwo ein 13D (@Prompt ?). Die Eingabe im FrontEnd erzeugt aber offensichtlich beide Werte (was ja auch "ASCII-mässig" korrekt wäre (LF + CR).

(Wirklich) Übel, dass irgendwann die Routine dazu führt, dass man nicht mehr genau weiss, wie es denn nun genau funktioniert ...

Bernhard

flaite:

--- Zitat von: koehlerbv am 02.10.05 - 00:09:53 --- (was ja auch "ASCII-mässig" korrekt wäre (LF + CR).

--- Ende Zitat ---
muss insistieren. Das hat nichts mit ASCII zu tun sondern ist ein reiner Microsoft Standard.
In Unix gibt es das nicht.

koehlerbv:
Axel, ich glaube nicht, dass das was mit LS zu tun hat. Lass Dir mal "Line feed" und "Carriage return" auf der Zunge zergehen ... Ich habe das bei der Steuerung von Druckern (oder programmierbaren Schreibmaschinen im weiteren Sinne) erstmals kennengelernt, und welches OS auf den Kisten, an denen diese Teile angeschlossen waren, war diesen LPTs sowas von egal  ;)

Bernhard

flaite:
Ich behaupte nicht das das was mit LotusScript zu tun hat.
Ich weiss nur, dass ich mir in der Vor-Eclipse-Code viele Java Source Dateien in Notepad angeschaut habe. Notepad versteht nur den Microsoft Standard Carriage Return Linefeed als Zeilenumbruch. Je nachdem wie die Dateien ursprünglich erstellt waren, sah man da auf Notepad manchmal einfach keine Zeilenumbrüche.
Deshalb bin ich ein Anhänger dieser Theorie:
http://www.oreilly.de/catalog/mcosxhksger/chapter/hack05.html
Zitat

--- Code: ---Es gibt drei verschiedene Arten von Zeilenumbrüchen, die ursprünglich jeweils einem der großen Betriebssysteme zuzurechnen waren: Windows/DOS, Macintosh und Unix. Ein Dokument mit Mac-Zeilenumbrüchen sieht auf einem Windows-System grässlich aus, und ein Dokument mit Windows-Umbrüchen wird von Unix auch nicht korrekt interpretiert. Der Grund dafür besteht darin, wie der Zeilenumbruch erstellt wird. Der Mac bedient sich standardmäßig eines einfachen Carriage Returns (<CR>), dargestellt als \r. Unix hingegen verwendet einen einfachen Zeilenvorschub (<LF> für engl. line feed), dargestellt als \n. Windows geht einen Schritt weiter und verbindet beide (<CRLF>) zu der Kombination \r\n.

--- Ende Code ---
Das hat sich natürlich mittlerweile ziemlich relativiert, da z.B. ein Programm wie Textpad oder Wordpad (ist nicht Notepad) natürlich auch unix/linux und Mac-Zeilenumbrüche versteht.

ASCII ist für mich einfach ein Mapping von 2 ^7 in Binärform dargestellter positiver natürlicher Zahlen (?) auf bestimmte Zeichen. In Ascii ist aber nicht definiert, ob jetzt ein Zeilenumbruch durch carriage return, line feed oder beides dargestellt wird. Vielmehr haben aus meinen Verständnisse verschiedene Betriebssysteme unterschiedliche "Haus"-Standards.
Ascii ist
0000 1101 ist carriage return
0000 1010 ist line feed

Betriebssystemstandard (eine Abstraktionsebene dadrüber) ist
Zeilenumbruch heisst:
carriage return + line feed (Windows)
carriage return (Mac)
line feed (linux/unix)

Das Programme wie TextPad, Wordpad, Eclipse, Notes auf Windows auch die Hausstandards von Mac und Linux/Unix mitunterstützen ist für mich ein Zugeständnis an Interoperabilität von Betriebssystemen.

Durch die zunehmende Verbreitung von unicode und xml/webservices tauchen in diesem Kontext auch aktuell immer wieder Fragen auf. Da spielt das encoding nämlich eine Rolle. Ich bin da manchmal auch am grübeln, hab das aber im Griff.

Wenn du dir ein txt file im Hex-Editor anschaust, da steht dort meines Wissens nirgendwo, ob dies im ASCII Standard, ISO-8859-1, UTF-8 oder in Unicode 4.0 encodiert ist. In UTF-8 sind manche Zeichen 16 bit, andere 8 bit. ASCII ist 7bit, ISO-8859-1 ist 8 bit, UTF-8 ist manchmal 8, manchmal 16 bit. Unicode 4.0 ist manchmal 16 bit, manchmal 32 bit.

Auf einer tiefen technischen Ebene enthalten ja Dateien rein nur binäre Zeichenfolgen. Die Programme, die txt-Dateien darstellen, machen eine reine Annahme, mit welchem Zeichensatz-Mapping die binäre Zeichenkette als characters angezeigt wird.
In xml steht aber z.B. das encoding direkt in dem xml declaration Element.

--- Code: ---<?xml encoding="ISO-8859-1"?>
<root>
<element>value</element>
</root>

--- Ende Code ---

Manchmal haben Leute Probleme, wenn sie nicht die korrekte Vorstellung von Text-Dateien als binäre Zeichenfolgeketten. Die als korrekt (oder inkorrekt) empfundene Anzeige in Zeichen hängt dann rein von diesen  impliziten oder expliziten byte -> character Mapping-Tabellen-Standards ab.  ;D

Axel

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete