[gelöst] RTC: VALIDATE wird doppelt durchgeführt

[raggy]

Ich habe in eine Page zur Verwaltung von Zusatztexten.
In der Page ist ein Feld, in der man eine Textnummer eingeben kann, die Texte mit dieser Textnummer werden dann an diesen Zusatztext eingefügt.
Die Verarbeitung (das Hinzukopieren der Texte) wird aus dem OnValidate-Trigger des Textnummern-Feldes aufgerufen – sonst nie.

Das Problem ist nun, dass die Verarbeitung immer 2 mal aufgerufen wird – und dann beim 2.Mal auf die Nase fällt, weil die Sätze schon da sind.

In der Form, aus der die Page erstellt wurde, funktioniert das wunderbar. Allerdings wird da die Verarbeitung (das Hinzukopieren der Texte) wird aus dem OnAfterValidate-Trigger des Textnummern-Feldes aufgerufen – diesen Trigger gibt es ja in der Page nicht.

Das ist der Code der Einfüge-Routine in der Page:

Code:

IF cuTransferExtText.ZusTextPrüfWennTextBauStein(Rec,ExtTextHeader) THEN BEGIN
  // hat geprüft auf Vorhandensein des einzufügenden Textes und einen Text gefunden
  CurrPage.SAVERECORD;
  // fügt jetzt den Text ein
  cuTransferExtText.ZusTextEinfügenTextBauStein(Rec,ExtTextHeader);
END;

IF cuTransferExtText.MakeUpdate THEN BEGIN
  // das ist TRUE, wenn ein Text gefunden und eingefügt wurde
  CurrPage.UPDATE;
END;


Wenn ich – versuchsweise - den

Code:

CurrPage.UPDATE;


ändere in

Code:

  CurrPage.UPDATE(FALSE);


dann funktioniert es wohl.

Ich kann mir aber selber nicht so recht erklären, warum das so ist ………………
Vielleicht kann es mir ja jemand erklären.

Zuletzt geändert von raggy am 14. Juli 2011 18:59, insgesamt 1-mal geändert.

Das Problem ist nun, dass die Verarbeitung immer 2 mal aufgerufen wird – und dann beim 2.Mal auf die Nase fällt, weil die Sätze schon da sind.

Das sollte nie passieren, auch bei doppeltem validate nicht. Da musst Du Deinen Code überarbeiten, um sauber zu sein.

Mich macht dein Codebeispiel stutzig, denn im Standard geht es (z.B. auf Page 46) so:

Feld "No.", OnValidate:

Code:

...
NoOnAfterValidate;

NoOnAfterValidate

Code:

InsertExtendedText(FALSE);
[...]
IF (Reserve = Reserve::Always) AND
   ("Outstanding Qty. (Base)" <> 0) AND
   ("No." <> xRec."No.")
THEN BEGIN
  CurrPage.SAVERECORD;
  AutoReserve;
  CurrPage.UPDATE(FALSE);
END;

InsertExtendedText (dies hier ist wichtig):

Code:

IF TransferExtendedText.SalesCheckIfAnyExtText(Rec,Unconditionally) THEN BEGIN // anderer Parameter als bei dir
  CurrPage.SAVERECORD;
  TransferExtendedText.InsertSalesExtText(Rec);
END;
IF TransferExtendedText.MakeUpdate THEN
  UpdateForm(TRUE);

UpdateForm(TRUE) entspricht CurrPage.UPDATE(TRUE).
Ich würde mich im Zweifel an den Standard halten. Die Funktionen für die Textbausteine (Codeunit TransferExtendedText) sind mittlerweile modifziert worden.

Die unterschiedlichen Übergabeparameter resultieren daraus:

Parameter "Unconditionally"
- der Standard steuert darüber zusätzlich, ob der Text generell übernommen werden soll oder abhängig von einer weiteren Einstellung (z.B. Artikeltext nur, wenn "Automat.Textbaustein" aktiviert)
- in unseren Funktionen wird der Text immer übernommen, da wird der Parameter also nicht gebraucht
Unsere Funktionen übergeben noch ExtTextHeader als Rec - in der Übergabefunktion lokal und ohne Rückgabe aus der gerufenen Funktion.
Beides dürfte aber m.E. keinen Unterschied machen.

Weitere Unterschied ist, dass die Standardfunktion InsertSalesText am Anfang einen COMMIT hat, den unsere Funktion ZusTextEinfügenTextBauStein nicht hat.
Könnte das Ursache des Problems sein ?

Ich lasse das jetzt aber parallel durch meinen Entwicklungsleiter mal überprüfen.
Unsere Zusatzfunktionen sind ein internes "Standard"-AddOn, das schon seit Jahren existiert. Daran will ich nichts ändern - es könnte sonst an anderen Stellen u.U. Probleme geben, wer weiss