Domino 9 und frühere Versionen > ND7: Entwicklung
Kollision zwischen OnHelp und Continue = False in Querysave
Peter Klett:
Hallo,
folgendes Problem ist bei einem Kunden aufgetreten, das ich mit einer Testdatenbank auf das Wesentliche eingrenzen konnte. Vielleicht kennt jemand eine Umgehung für das Problem.
In einer Maske wird das OnHelp-Event für den Client mit einem Script belegt, z.B.:
Sub Onhelp (Source As NotesUIDocument)
Print "F1 gedrückt"
End Sub
In einer Teilmaske, die in die Maske eingebunden ist, wird im Querysave das Speichern unterbunden, z.B.:
Sub Querysave (Source As NotesUIDocument, Continue As Variant)
Msgbox "Speichern verboten"
Continue = False
End Sub
Beim Versuch, das Dokument mit der Maske zu speichern, wird zwar die Fehlermeldung "Speichern verboten" ausgegeben, das Dokument aber trotzdem gespeichert.
Entfernt man das Script aus dem OnHelp der Maske, kann das Dokument, wie gewünscht, nicht gespeichert werden.
Gleiches Problem tritt auf, wenn zwei Teilmasken in der Maske eingebunden sind und in der ersten Teilmaske das OnHelp ein Script enthält (die Maske selbst enthält nichts im OnHelp), während die zweite Teilmaske im Querysave das Speichern verhindert.
Dreht man jedoch die Reihenfolge der Teilmasken um, also erst die Teilmaske, die das Speichern verhindert und dann die Teilmaske mit dem OnHelp, funktioniert alles so, wie es soll.
Nachvollziehbar ist das Problem unter 7.03 und 8.5.0.
Nun frage ich mich, was ein OnHelp-Event mit dem Continue des Querysave zu tun hat.
Vielen Dank vorab für Eure Beiträge
it898ur:
Hallo,
mit dem Setzen von Continue = false im QuerySave von Teilmasken hatte ich auch schon diverse Probleme (Notes 7.0.2), daher habe ich mir angewöhnt alle Prüfungen in einer Scriptbibliothek zu sammeln und diese im QuerySave der Maske abzuhandeln.
Wenn man Code aber gezielt auslagern will, reicht es oft schon aus ein "Validierungsfeld" einzufügen, welches bei Fehlern aus Teilmasken gesetzt wird. Dann kann man darauf im zentralen Code abfragen.
Gruß
André
Peter Klett:
Hallo André,
vielen Dank für Deinen Beitrag. Habe Deinen zweiten Lösungsvorschlag nachgebaut (der erste kommt aufgrund der Modularisierung durch Teilmasken nicht in Frage).
In der Maske setze ich im Querysave Continue auf False, wenn das Validierungsfeld nicht leer ist.
In einer Teilmaske setze ich im Querysave einen Wert in das Validierungsfeld.
Wenn das Dokument gespeichert wird, durchläuft es erst das Querysave der Maske. Das Validierungsfeld ist leer, also wird Continue nicht auf False gesetzt. Dann wird das Querysave der Teilmaske ausgeführt, welches das Validierungsfeld setzt. Das Dokument ist damit gespeichert. Erst beim nächsten Speicherversuch schlägt die Validierung der Maske zu - zu spät.
Mit dem Setzen des Continue auf False in Teilmasken hatten wir noch nie Probleme (das zugrundeliegende System läuft seit 1999, begonnen unter OS/2 und Notes 4.5.x). Es handelt sich um einen modular aufgebauten Baukasten mit unterschiedlichen funktionalen Teilmasken (Workflowteilmaske rein -> Dokument kann Workflow, Workflowteilmaske raus -> Dokument kann kein Workflow usw.). In jeder Maske befinden sich mindestens 2 Teilmasken (Kopf und Fuß) und dazwischen, je nach Bedarf, 1-5 weitere. Der Kunde kann selbst Teilmasken erstellen und parametrisiert in die Maske einfügen. Zur Validierung wird in jeder (relevanten) Teilmaske im Querysave eine Function verwendet, die eine globale Variable mit Fehlermeldungen füllt. Die letzte Teilmaske (Fuß) überprüft dann die Variable und setzt das Continue auf False (das nur zur ungefähren Beschreibung des Umfeldes).
Durch die Verwendung von OnHelp in der kundeneigenen Teilmaske wurde dann die Validierungssystematik ausgeknippst.
Wenn man das weiß, kann man damit umgehen (früher ging es ja schließlich auch ohne OnHelp), aber merkwürdig finde ich das Verhalten schon. Der Vorteil von OnHelp wäre, dass man auch Hilfen direkt zu aktuellen Feldern aufrufen kann, die sich nicht in der eigenen Teilmaske befinden, ohne die fremden Teilmasken zu ändern, was nicht im Sinne des modularen Baukastens wäre.
BigWim:
Wie wäre es denn mit der Idee, den Ablauf über das Validierungsfeld zu steuern:
1. "Save" wird ausgelöst
2. Wenn Status des Validierungsfeld <> "ja, speichern" dann QuerySave(Maske)-Continue auf False
3. QuerySave der Teilmasken machen ihre Prüfungen
3a. Im "Fehlerfall" wird Validierungsfeld auf Status "nicht speichern" gesetzt.
3b. die weiteren QuerySave in den Teilmasken bräuchten u. U. Ihre Validierung gar nicht mehr ausführen.
4. QuerySave der letzten Teilmaske (Fuß) macht (ggfs.) ihre Prüfungen
4a. bei "OK" - setzt Validierungsfeld auf "ja, speichern"
4b. löst erneutes Speichern aus
5. QuerySave der Maske Continue auf True
6. QuerySave der Teilmasken können bei diesem Status Ihre Validierungen überspringen
7. Dokument gespeichert
Ich hoffe, ich konnte meine Idee einigermaßen verständlich beschreiben.
Markus
Peter Klett:
Hallo Markus,
auch Deine Idee (vielen Dank dafür) habe ich nachgebaut. Allerdings führt das zuerst gesetzte Continue = False in der Maske dazu, dass das Speichern sofort beendet und das Querysave in den Teilmasken nicht ausgeführt wird.
Man könnte die Validierung in das Postrecalc verlagern und in das Querysave der Maske ein Source.Refresh einfügen, dann stimmt die Reihenfolge. Das hätte dann aber wieder andere Nachteile, z.B. den, dass Werte von Feldern, die nur berechnet zur Anzeige sind, im folgenden Script nicht mehr im Zugriff sind (in solchen Feldern befinden sich allerdings einige wesentliche Daten zu dem aktuellen User im aktuellen Umfeld).
Wirtschaftlich wäre das ganze nicht vertretbar, da dazu in etwa 100 Schablonen alle individuellen Masken und Teilmasken angepasst werden müssten, und dazu noch alle von den Kunden selbst gebauten Teilmasken.
Da ich auch nicht mehr selbst an dem Baukasten aktiv beteiligt bin, hoffte ich auf eine Lösungsmöglichkeit ausschließlich in der kundeneigenen Teilmaske. Da trotz OnHelp das Querysave in allen Teilmasken ausgeführt und nur nicht auf das Continue reagiert wird, scheint es so, dass dadurch entweder die Variable Continue zerstört oder die Verarbeitung der Variablen gestoppt wird.
Es bleibt wohl nur zu hoffen, dass IBM das Problem behebt. Bis dahin ist OnHelp in diesem Kontext tabu.
Navigation
[0] Themen-Index
[#] Nächste Seite
Zur normalen Ansicht wechseln