Nach @command([FileSave]) kommt trotzdem noch der Speicherdialog

[vrhsva]

Hallo zusammen,
Ich benötige etwas Hilfe bei einer eigentlich simplen Formel.
Ich habe eine Mailschablone 8.5 etwas modifiziert, so dass sie als eine Art Team-Mail-DB benutzt werden kann.
Dafür habe ich den Masken Memo und Reply ein zusätzliches Feld hinzugefügt vom Typ Namen (mehrfach Werte erlaubt), welches den Namen "Bearbeiter" trägt. Desweiteren eine Aktion, welche folgendes berechnetes Label hat:

Code

@If(Bearbeiter="";"Bearbeitung: noch Niemand";"Bearbeitung: "+@Implode(@Name([CN];Bearbeiter);", "))

Der Inhalt der Aktion ist eine Formel:

Code

docwasineditmode:=@False;
@If(@IsDocBeingEdited;@Set("docwasineditmode";@True);@Command([EditDocument];"1"));
FIELD bearbeiter:=@UserName;
@Command([ViewRefreshFields]);
@Command([FileSave]);
@If(docwasineditmode;"";@Command([EditDocument];"0"))

Also der User öffnet eine eingegangene Mail (üblicherweise im Ansichtsmodus), fühlt sich für den Inhalt der Mail verantwortlich und klickt oben auf die Schaltfläche "Bearbeitung: Noch niemand".
Folgendes passiert:
Das Dokument wird in den Editiermodus versetzt,
das Feld Bearbeiter bekommt seinen Wert zugewiesen,
die Felder werden refreshed,
das Dokument wird gespeichert.

Bis dahin alles schick. Nun soll das Dokument wieder in den Ansichtmodus versetzt werden, weil sonst ja die Standard-Schaltflächen "Antworten", "Weiterleiten",usw. ausgeblendet sind.
Doch obwohl die Aktion ja gerade gespeichert hat, wird trotzdem an dieser Stelle noch mal der Speicherdialog "Do you want to save your changes?" angezeigt.
Der Ordner ($Inbox)  hat übrigens eine neue erste Spalte erhalten: kategorisiert Bearbeiter.
Um zu prüfen, ob das Dok vor dem Speicherdialog bereits gespeichert wurde, habe ich die Mail in einem neuen Fenster geöffnet, so dass ich die geöffnete Mail und die Inbox zur gleichen Zeit im Überblick habe, um zu sehen, ob die Änderung in der Ordnerspalte bereits angezeigt wird. Und es ist so.

Wie kann ich jetzt also den Speicherdialog unterdrücken?
Mit SaveOptions=0, SaveOptions=1, SaveOptions="0", SaveOptions="1" hab ich auch schon rumgespielt, hat aber alles nichts gebracht.

Grüße
Volker

[Ralf_B]

Mal kurz gesagt:Ich würde es vermeiden in den Editmode zu wechseln.
Ich mach das normal so:
Mailin DB ($Inbox)um Aktionen(Button in Ansicht) erweitern "Bearbeiter 1;Bearbeiter 2...) mit jeweils @Setfield("Bearbeiter";"TBD").
Somit habe ich keine Probleme mit dem UIDOCUMENT und es wird auch gleich in der Ansicht angezeigt.
Oder gibt es einen speziellen Grund in den Editmode zu wechseln?

Gruß
Ralf

[Gutierrez]

Moin vrhsva,

wir haben auch eine Funktion, wo ein UIDocument in den Bearbeiten-Modus versetzt wird und wieder zurück. Damit gibt es hin und wieder Probleme. Die Funktion, die Ralf_B beschreibt, haben wir auch, weil es keine Probleme macht.

Beste Grüße
Gutierrez

[vrhsva]

Hallo,

erst mal schon mal Danke für eure Antworten.
Es ist so: Der User bekommt nach Eingang einer neuen Mail in seine eigene MailDB eine Nachricht, dass in der TeamMailDB eine neue Mail eingegangen ist. Diese enthält einen Document-Link. Der User klickt drauf und ist dann gleich in der Mail im Ansichtmodus. Jetzt liest er sich den Inhalt durch und fühlt sich zuständig. Also klickt er auf die Aktion. Um dann zu sehen, dass die Aktion erfolgreich ausgeführt wurde, sollte dann auf dem Label der Schaltfläche sein Name als Bearbeiter zu sehen sein.

Um mit @setfield oder field:= einen Wert in ein Feld eines geöffnetes Dokument zu schreiben, muss ich ja im Edit-Modus sein.

[koehlerbv]

Hast Du schon versucht, mit einem @PostedCommand ([FileSave]) die Reihenfolge der @Command-Abarbeitung zu beeinflussen?

Bernhard

[vrhsva]

Ja, hab ich auch schon. Gleicher Effekt

[Ralf_B]

Hmm....
Also, der Anwender hat das Mail im Lesemodus offen und drückt eine Schaltfläche(Aktion der Maske vermute ich mal).
-> Also per Uiworkspace das uidocument holen und per uidocument.document in dem backenddokument das Feld setzen.
Dann soll der Anwendername auf dem Button erscheinen.
-> Weiter Aktion mit HideWhen und nach einem uidoc.refresh /reload oder nach erneutm öffnen des uidocs sollte das doch klappen.
Ich sehe da eigentlich keine Probleme, solange nicht der Editmodus genutz wird.

Und ja, @SetField oder doc.replaceitemvalue funktionieren ohne in den Editmodus zu wechseln solange ich das Backend Dokument nutze und nicht das Ui Dokument, problemlos.

Gruß
Ralf

[vrhsva]

Gut, das hab ich mal probiert, also das Ganze per Script zu machen.
Feld im Backend gesetzt, uidoc schließen und wieder öffnen. Klappt wie gewollt einwandfrei.

Nur: Die erste Spalte in der Inbox ist ja kategorisiert (Bearbeiter). Wenn der Nutzer die Mail aus der Inbox öffnet, die Aktion durchführt und dann wieder schließt, aktualisiert sich die Kategorie in der Inbox nicht, ohne F5/F9 zu drücken. Das passiert nur, wenn ich das Dokument im Frontend speichere. Ich kann auch aus dem Script heraus, welches ich mit @command([ToolsRunMacro];"Agent") in dem Aktionsbutton aufrufe, nicht auf den im Hintergrund geöffneten Folder zugreifen, um dort die Inbox zu refreshen. Hab im Debugger die uiworkspace durchforstet nach notesuiview, aber da steht nichts drin. Komm ich also nicht ran. Oder kann man sich die notesuiview aus dem QueryOpenDocument der Inbox irgendwo merken, so dass sie dem Script im Agenten zur Verfügung steht?

[Gutierrez]

Hallo vrhsva,

du kannst die undokumentierte Funktion NotesUIWorkspace.ViewRefreshByDBid(Byval ReplicaID As String, Optional Byval ViewName As String, Optional Byval CalenderView) benutzen, um die Ansicht zu aktualisieren.

Beste Grüße
Gutierrez

[Ralf_B]

Sollte funktionieren.

Oder die dokumentierte Version:
https://www.ibm.com/support/knowledgecenter/en/SSVRGU_9.0.1/basic/H_VIEWREFRESH_METHOD.html

Viel Erfolg.