Domino 9 und frühere Versionen > Entwicklung

Anzahl der Zeichen in einem Textfeld!!!

<< < (5/7) > >>

Axel:

--- Zitat von: voigt am 30.09.05 - 16:31:56 ---Hast Du noch einen Tipp wie ich Notes sage dass in dem Feld txtProblemPre kein Zeilenumbruch stattfinden darf?

--- Ende Zitat ---

Hi,

das kannst du auf diese Art lösen.
...
'Prüfung ob im Feld txtProblemPre Zeilenschaltungen enthalten sind.
If Instr(doc.txtProblemPre(0), Chr$(13)) > 0 Then
  Messagebox "Im Feld txtProblemPre darf keine Zeilenschaltung enthalten sein." _
      & Chr$(10) & "Das Dokument kann nicht gespeichert werden.",   48, "Adressen - Warnung"
  Call uidoc.GotoField("txtProblemPre")
  Continue = False
  Exit Sub
End If  'If Instr(doc.txtProblemPre(0), Chr$(13)) > 0 Then
...


Axel

TMC:

--- Zitat von: voigt am 30.09.05 - 17:09:58 ---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

--- Ende Zitat ---

Hab jetzt nicht den ganzen Thread gelesen, aber poste doch mal die Zeile wo der fehler auftitt, oder alternativ den kompletten Code des Querysave (inkl. Zeilenangabe wo Fehler auftritt). Könnte z.B. ein fehlender Punkt sein bei einem Call uidoc.irgendwas.

koehlerbv:

--- Zitat von: Axel am 30.09.05 - 16:42:49 ---'Prüfung ob im Feld txtProblemPre Zeilenschaltungen enthalten sind.
If Instr(doc.txtProblemPre(0), Chr$(13)) > 0 Then
  Messagebox "Im Feld txtProblemPre darf keine Zeilenschaltung enthalten sein." _
      & Chr$(10) & "Das Dokument kann nicht gespeichert werden.",   48, "Adressen - Warnung"
  Call uidoc.GotoField("txtProblemPre")
  Continue = False
  Exit Sub
End If  'If Instr(doc.txtProblemPre(0), Chr$(13)) > 0 Then
...

--- Ende Zitat ---

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.

@Steffen: Woher Fehler wie der von Dir beschriebene kommen, sollten Dir aber mittlerweile klar sein. Wenn der Compiler oder der Interpreter ein deklariertes Objekt nicht finden, ist das doch in der Regel der einfachst lösbare Fall ("wo und wie habe ich das überhaupt deklariert ?").
Ich denke, dies ist das Problem von übernommenen Code, den man nicht wirklich verstanden hat. Im wirklichen (Programmierer-)Leben ist sowas kreuzgefährlich !

Bernhard

flaite:
Soviel ich weiss ist der Standardzeilenumbruch in Windows
Chr$(13) + Chr$(10)

auf unix und linux:
Chr$(10)

http://www.oreilly.de/catalog/mcosxhksger/chapter/hack05.html

--- Zitat ---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 Zitat ---

Viele Windowsprogramme verstehen aber heutzutage auch chr$(10) -> z.B. Lotus Notes.
Windows Notepad meines wissens nicht. Wordpad aber schon.

\r -> 13 (CR)
\n -> 10 (LF)

--- Code: ---public class Test {

/**
* @param args
*/
public static void main(String[] args) {
// TODO Auto-generated method stub
String test = "\r\n";
char[] someChars = test.toCharArray();
for (int i=0; i<someChars.length; i++) {
System.out.println((long)someChars[i]);
}

}

}

--- Ende Code ---
printet:
13
10

koehlerbv:
Axel, das einfachste ist (so habe ich das auch getan), mal ein Textfeld und ein RichText-Feld aus einem NotesDocument Zeichenweise auszugeben, wenn dort ein Zeilenumbruch eingefügt wurde. Du findest dort Dec 10 als Standardcode von Notes.
Importierst Du aber zum Bleistift Daten aus Excel, ist der Umbruch gekennzeichnet durch Dez 13. In Textfeldern okay, in RTIs gibt es aber statt einem Umbruch ein Ersatzzeichen und keinen Umbruch. Daher filtere ich schön ASCII-gemäss immer nach Dec 10 und Dec 13 und war bisher immer auf der sicheren Seite. Die Zeiten der eigentlichen Bedeutungen von ASCII 10 = Zeilenvorschub und ASCII 13 = Wagenrücklauf sind ja längst vorbei ...

Bernhard

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete