Domino 9 und frühere Versionen > ND8: Entwicklung

Nachhilfe beim Exiting-Event

<< < (2/3) > >>

jBubbleBoy:

--- Zitat von: Peter Klett am 24.04.17 - 22:13:31 ---Dann würde bei einem Postrecalc das Dokument 15 mal gespeichert, wenn alle 15 Felder auf OK stehen.
--- Ende Zitat ---
das stimmt ;)  dabei ist mir eine viel einfachere Lösung eingefallen, im PostRecalc:

--- Code: ---If Instr(Lcase(source.CurrentField),"feldname_")=1 Then
If source.Document.GetFirstItem(source.CurrentField).text = "OK" Then source.Save
End If

--- Ende Code ---
Das Problem beim OnChange-Event ist, das dieser beim Klick (und setzen des Wertes) nicht ausgelöst wird, das passiert erst bei einem F9-Refresh, Feldeigenschaft "aktualisieren" reicht nicht. In so einer Konstellation (Wenn ich in das Feld klicke, wird ja immer gespeichert) könnte der Nutzer "rausgehen" ohne dabei zu speichern, das gleiche Problem gibt es aber auch beim Exit-Ereignis. Deshalb denke ich mal wäre PostRecalc, auch weil man nur einmal Code schreiben muss, der beste Weg ;)

Boox:
Vielen Dank für die guten Tipps! Ich werde es mal testen :)

Vermutlich werde ich dann aber den Feldnamen einfach anpassen, das ist wohl dann doch am einfachsten ;)

thkn777:
Frage:
Warum nicht in der Maske auf die Änderung des Feldes reagieren?

Hintergrund:
Ein doc.Save speichert das ganze Dokument. Bevor ich das tue, möchte man vielleicht noch andere Prüfungen vornehmen. Ich stelle mir eine Datenbank mit Masken, in denen irgendwelche Felder eingebaut sind, die vielleicht bei bestimmten Wert-Änderungen das Dokument speichern, ziemlich support-unfreundlich vor.

Lösungsvorschlag:
In Deinem Fall (15 Optionsfelder feld1 .. feld15) könntest Du im QueryRecalc der Maske folgendes schreiben:

--- Code: ---Sub Queryrecalc(Source As Notesuidocument, Continue As Variant)
If Left$(Lcase(source.CurrentField),4)="feld" Then
Print "MACH WAS"
Else
Print "ist mir egal"
End If
End Sub

--- Ende Code ---

Den Print Befehl kannst Du natürlich auch durch etwas anderes ersetzen ;)

Damit hast Du an einer Stelle Deine Prüfungen/Save's verwaltet, Schreibaufwand ist minimal und falls Du mal eines der Optionsfelder ganz zufällig ;) in eine andere Maske kopierst, fängt diese nicht einfach aus heiterem Himmel an, manchmal das Dokument zu speichern.

Viel Erfolg,
Th.

JoeeoJ:
Hallo zusammen,

UIDocument.CurrentField liefert im Exiting Event des Feldes leider schon den Namen des nächsten Feldes(!) und nicht des Feldes das man gerade verlässt !!! Den muss man in Entering Event abgreifen, da stimmt es.

Nehem an, das bei IBM\Lotus bei der Programmierung jemand nicht so ganz die Uebersicht hatte und vor dem Exiting Event den nächsten Feldnamen ermittelt und(!) in Currentfield geschrieben hat.

Gruss, Joe

koehlerbv:

--- Zitat von: JoeeoJ am 11.11.17 - 14:24:47 ---Nehme an, daß bei IBM\Lotus bei der Programmierung jemand nicht so ganz die Uebersicht hatte und vor dem Exiting Event den nächsten Feldnamen ermittelt und(!) in Currentfield geschrieben hat.

--- Ende Zitat ---

Falsch. Im Entering-Event ist der Wert von NotesUIDocument.CurrentField das gerade erreichte Feld, im Exiting wird das Feld verwendet, wohin das Exiting geht. Oder eben keins, wenn beispielsweise eine Schaltfläche bestätigt wird. Im Entering kann man sich einfachst in einer globalen Variablen merken, wo man gerade herumhüpft. Somit weiss man im Exiting, woher man kommt und wohin man geht.
Genau das ist auch in der DesignerHelp dokumentiert.
Welche grundsätzliche Designentscheidung hättest Du denn für Entering und Exiting getroffen? Wie hättest Du gelöst, dass man als Programmierer erfahren kann, wohin im Exiting die Reise geht?

Bernhard

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete