Schau Dir doch mal die Selektions- Formel(n) Deiner Ansicht(en) an: Worauf wird dort zugegriffen ?

Jetzt überprüf mal in Deinem generierten Dokumenten, ob nach dem Computewithform die in den Ansichten abgefragten Felder tatsächlich vorhanden sind.

Ich vermute folgendes: Relativ weit oben in Deiner Maske ist ein Feld, was bei "Computewithform" mit einem Fehler reagiert... dadurch wird das Compute abgebrochen und die restlichen Felder werden NICHT gesetzt.

Die Validierung "von Hand" ist meist wesentlich stabiler als ein ComputewithForm und übergeht den Fehler vermutlich, deshalb sind die Dokumente nach dem manuellen Speichern dann auch in der Ansicht.

MERKE: Wenn man ComputeWithForm verwenden will, muss man immer sicher sein, dass alle kritischen Felder vorher gefüllt sind, sonst läuft der ins Nirvana.

Solltest Du das falsche Feld nicht finden, dann melde Dich noch mal, dann beschreib ich Dir kurz, wie man ein ComputeWithForm "Debuggt"...

HTH
Tode

Das ComputeWithForm ist ja herauskommentiert, das wird evtl. die Ursache sein.

Ich verwende immer computeWihtForm(false,false).

Weiterhin empfiehlt es sich, die aktuelle Ansicht nach dem Einfügen zu aktualisieren. Das geht so:

dim ws as NotesUIWorkspace
set ws = New NotesUIWorkspace

call ws.ViewRefresh   'am Ende des Code

Andreas

Wie oben beschrieben ist der ComputeWithForm ein kleines "Zieselchen" wie wir hier bei uns sagen: Er reagiert extrem empfindlich auf falsche Feldwerte / Datentypen und bricht ab, wo ein manuelles "F9" im Dokument einfach die Werte korrigiert.

Leider sagt uns der ComputeWithForm auch bei RaiseError = True nur, dass ein Fehler aufgetreten ist, nicht aber, wo genau dieser Fehler aufgetreten ist.

Um das herauszufinden, muss man sich eines kleinen Tricks bedienen:
Bricht ein ComputeWithForm ab, dann werden alle Felder, die sich UNTERHALB des Fehler- verursachenden Feldes befinden, nicht mehr berechnet.

Man tut also folgendes: Man erstellt in der Maske ein Feld, Typ Text, berechnet, Formel "Bis hier OK" (o.ä.) und stellt dieses ganz nach oben (als Referenz, dass die Formel korrekt ist).

Nach dem Script- Lauf prüft man, ob tatsächlich "Bis hier OK" im Feld steht.

Ist das der Fall, dann verschiebt man das Feld in der Maske schrittweise nach unten. irgendwann wird das Feld plötzlich leer sein nach dem Script- Lauf. Dann weiss man, dass direkt überhalb des Feldes das Feld ist, was den ComputewithForm abbrechen lässt. In dieses Feld baut man jetzt einfach eine entsprechende Fehler- Routine ein, und VOILA: Der ComputeWithForm läuft durch...

Mögliche Fehlerursachen sind:

- Ein Feld, dass als Datum definiert ist, aber nur den TEXT eines Datums enthält (F9 wandelt das automatisch um, ComputeWithForm bricht ab).

Lösung: Einfach in die Formel (bei berechnet) oder in die Eingabeumsetzung( bei Bearbeitet) ne Formel ala:
x := @Date( FeldName );
@If( @IsError( x ) ; "" ; x )

- Das selbe gilt für Zahlenfelder: Steht dort z.B. ein Text drin, der als Zahl interpretiert werden KÖNNTE, dann tut das F9 auch... ComputeWithForm bricht mit Fehler ab. Das passiert z.B. dann, wenn man Felder per Script füllt, und nicht bemerkt, dass man einen Textwert in ein Zahlenfeld schreibt...
Auch hier hilft wieder eine ähnliche Formel:
x := @TextToNumber( FeldName );
@If( @IsNumber( FeldName ) ; FeldName ; @IsError( x ) ; "" ; x )

So kriegt man den ComputeWithForm dazu, alles korrekt durchzuführen.

HTH
Tode

@Tode:
Wenn ich das richtig interpretierem geht Notes bei ComputeWithForm Feld für Feld vor und speichert das Dokument !? Sonst stünde ja nicht in einigen Feldern das richtige und in den anderen nicht.

Andreas

Danke Jens für den Hinweis - Macht der Gewohnheit  

Der Code wäre so aber besser - ComputeWithForm am Ende.

While Not (docMail Is Nothing)
     
      Set docNew = docMail.CopyToDatabase(dbCurrent)
     
      docNew.Form = "frmVorgangMail"
     
      docNew.xDeleteReason = "gültig"
      docNew.VorgangsTyp = "E-Mail"
                                ...

      Call docNew.ComputeWithForm(True, False)
      Call docNew.Save(True,False)
     
      Set docMail = collection.GetNextDocument(docMail)
   Wend  'While Not (docMail Is Nothing)

Andreas

Danke Jens für den Hinweis - Macht der Gewohnheit  

Der Code wäre so aber besser - ComputeWithForm am Ende.

While Not (docMail Is Nothing)
     
      Set docNew = docMail.CopyToDatabase(dbCurrent)
     
      docNew.Form = "frmVorgangMail"
     
      docNew.xDeleteReason = "gültig"
      docNew.VorgangsTyp = "E-Mail"
                                ...

      Call docNew.ComputeWithForm(True, False)
      Call docNew.Save(True,False)
     
      Set docMail = collection.GetNextDocument(docMail)
   Wend  'While Not (docMail Is Nothing)

Andreas

Hi,

so hatte ich das auch am Anfang. Machte die gleichen Probleme. Das mit dem Feld xDeleteReason muss ich nochmal genauer untersuchen. Wenn das so wäre wie du sagst, dass Script manchmal alles in Grossbuchstaben schreibt, warum sehe ich denn dann das Dokument nachdem ich es über Ungelesene suchen..., bearbeiten und speichern einmal angefasst habe. Das will mir im Moment nicht in den Kopf.

Ich vermute, dass der Hund darin begraben liegt, dass das Maildokument über CopyToDatabase in die Datenbank übernommen wird und ich dann nur die andere Maske drüberziehe. Ich denke das es hier mit den Backend-Funktionen irgendein Problem gibt.

Ich habe in einer kommerziellen Version diese Funktion gesehen. Hier ist es aber nur möglich immer nur ein Mail zu übernehmen. Außerdem wird es im Frontend geöffnet und man muss es dann speichern. Das werde ich morgen mal testen.


Axel