Domino 9 und frühere Versionen > ND6: Entwicklung

Refresh fields in Script

<< < (3/3)

Glombi:
@Bernhard: Ich tippe mal, dass im Frontend durch F9 einige Script-Events getriggert werden, die tonnenweise Felder setzen/manipulieren.

DAS kann ComputeWithForm natürlich nicht.

Ich lasse das auch nur auf Anwendungen los, die ich selbst gestrickt habe bzw. von denen ich weiß, was da genau abgeht. Ich glaube, vom Mail kann ich das nicht behaupten  ;D

Andreas

koehlerbv:

--- Zitat von: Glombi am 15.03.06 - 19:15:52 ---Ich lasse das auch nur auf Anwendungen los, die ich selbst gestrickt habe bzw. von denen ich weiß, was da genau abgeht. Ich glaube, vom Mail kann ich das nicht behaupten  ;D
--- Ende Zitat ---

Gut gebrüllt, Löwe  ;D

A-Bär: ComputeWithForm scheitert bei Appointments (wenn man es an der falschen und releaseabhängig falschen Stelle einsetzt), sprich: Es wirft einen Fehler. Mit den LS-Events kann das nun nicht zusammenhängen.

Vulgo: Bei eigenen Anwendungen verwende ich auch meine eigenen Update-Routinen und denke nicht mehr über ComputeWithForm nach. Einsetzbare Fälle kann ich mir aber vorstellen.

Und: Vielen Dank für die KBase-Recherchen. Das war sehr interessant.

Bernhard

Tode:
muss ich auch noch meinen Senf dazugeben.

Ich habe mal einen Beitrag zum "kontrollieren" der ComputeWithForm geschrieben (ist sicher noch irgendwo auffindbar).

Zusammenfassend ist zu sagen:
ComputeWithform ist ein wenig "empfindlicher" als das Frontend: wenn hier Felder z.B. nicht mit dem richtigen Feldtyp gesetzt sind, dann bricht der gerne mal ab. man erkennt das daran, dass alle Felder über dem betroffenen Fehlerhaften Feld neu berechnet wurden, und alle darunter nicht.
Er geht also durchaus "von oben nach unten, von links nach rechts" wie ein F9 im Frontend.

ABER: eine ganz grosse Einschränkung hat er seit R6: Computed for Display- Felder werden nicht mehr berücksichtigt. In R5 war es so, dass Formeln basierend auf Computed for Display- Feldern korrekt berechnet wurden, inzwischen ist es als ob das Feld nicht existiert (was im Backend ja auch korrekt ist). Deshalb die manchmal "seltsamen" Ergebnisse des ComputeWithForm.

Im Grossen und ganzen ist zu sagen, dass ich es ab und zu als "Quick&Dirty"- Methode verwende um Dokumente neuzuberechnen, und meistens funktioniert es einwandfrei (oben genannte Bedingungen ausgeschlossen), aber wenn es nur um wenige Felder geht, dann programmiere ich deren Formeln lieber in einem Formel- Agenten bzw. Script- Agenten nach.

Besonders bei grossen Datenmengen kann man so schon mal die ein oder andere Stunde Agentenlauf verhindern...

Gruss
Tode

atbits:
Ich kann das bei mir auch nachvollziehen,
Berechnete Felder mit @DBLookup oder @DBColumn werden bei ComputeWithForm definitiv nicht berechnet.

Echt ein Sch***

Aber gut, dass hier schon darüber diskutiert wurde, das verschafft mir die Gewissheit, dass deer Fehler nicht bei mir zwischen den Ohren liegt ;-)

Grüße David

Navigation

[0] Themen-Index

[*] Vorherige Sete

Zur normalen Ansicht wechseln