rtlib: Änderungen in geändertes Dok übernehmen ?

[Tode]

Ich bin gerade dabei ein wenig mit rtLib rumzuprobieren (da kann man so schön Hide-Whens on the fly setzen, was ich für eine Applikation brauche.

Dummerweise gilt hier (scheinbar) das gleiche wie immer, wenn man mit RT- Items arbeitet:
Änderungen werden im Frontend erst sichtbar nach dem Schliessen und erneuten öffnen.

Hat jemand schon mit dem Tool gearbietet und weiss, ob das hier vielleicht anders geht ?

Mein Problem:
Ich möchte die HideWhens beim speichern (QuerySave) setzen. Dummerweise werden dabei die Änderungen am Backend nicht im Frontend gespeichert ( uidoc.Reload / uidoc.Refresh tun's nicht).

Ohne rtLib würde ich mir selbst antworten "vergiss es, das geht nur mit reOpen", aber vielleicht bietet ja rtLib da ne Funktionalität... Leider werde ich aus Doku und Beispielen zu dem Tool dahingehend nicht schlau.

Thanx
Tode

[koehlerbv]

AFAIK (! Ich könnte da auch was übersehen) bleibt auch mit RTLib das Problem, dass gerade bei QuerySave das FrontEnd gnadenlos das mit RTLib-Funktionalitäten bearbeitete BackEnd überbügelt. Es bleibt der klassische Konflikt.

Bernhard

[Tode]

ja, ich habe auch keine Möglichkeit gefunden, das zurückzupumpen.
Ich behelfe mir jetzt mit folgendem Workaround:

im QuerySave wird ein Flag-Feld auf "1" gesetzt.
Im Terminate der Maske wird auf dieses Flag- Feld abgefragt und dann folgendes gemacht:

Ein Agent wird gestartet. über die unid des Dokuments hole ich mir das Dokument aus der Db, führe meine Hide- When- Korrekturen durch, und speichere es im Hintergrund.

Warum verwende ich nicht Source.Document ?

Nun: es ist ja durchaus denkbar (wenn auch nicht sehr wahrscheinlich), dass ein user das Dokument abspeichert (zur Sicherheit, mache ich per Strg + S auch immer mal wieder), dann weitere Änderungen macht, und dabei merkt: hoppla, jetzt habe ich aus versehen zu viel gelöscht (löschen von Tabellen kann nícht rückgänig gemacht werden z.B.). Er schliesst das Dokument und beantwortet die Abfrage "Speichern ?" mit nein, weil er ja die letzten Änderungen nicht mehr speichern will...

nehme ich jetzt "Source.Document", dann mache ich seine Auswahl unwirksam. Mit doc über unid speichere ich nur das nochmal, was sowieso schon auf der Platte liegt, nicht das Dok im Speicher...

Falls jemand mal ähnliche Probleme hat...

Gruß
Tode

P.S.: Für diejenigen, die mit regelmässigen Abstürzen des Clients rechnen, wodurch das Terminate nicht immer ausgeführt wird: man kann jetzt als zusätzliche Sicherheit einen periodischen Agenten laufen lassen, der auf das flag- feld abprüft und diese Dokumente abarbeitet... Das Flag- Feld wird nämlich nach erfolgreicher Bearbeitung immer zurückgesetzt...

[koehlerbv]

Hallo Torsten,

warum nimmst Du für das Feld eigentlich ein Item und keine maskenglobale Variable? Wegen der Möglichkeit, nach Chrashs nachzuarbeiten?

Bernhard

[Tode]

exakt deswegen...

Richtext- Verarbeitung ist nun mal immer noch ein recht "wackliges" Gebilde, und der Notes- Client ist in den 6.5er Versionen leider alles andere als stabil. Deshalb möchte ich ein Fallback- Szenario haben. Sonst gebe ich Dir natürlich recht: eine globale Variable wäre "sauberer", weil man das Design nicht mit Flag- Feldern vollpflastert.

Gruß
Tode