UI-Document schließen ohne User-frage nach Speichern - wie geht das?

  • Hi,


    gibt es eine Möglichkeit, ein UI-Document, welches im EditMode geöffnet wird und anschließend wieder geschlossen wird, ohne das der Benutzer nach dem Speichern gefragt wird.


    Ich habe eine Routine, welche x-markierte Doc´s durchläuft und diese aktualisiert.
    Wenn ich das UIDoc dann schließe mit UIDoc.Close, dann wird der Benutzer nach dem Speichern gefragt,
    obwohl mein Dokument schon per QuerySave gespeichert wurde.


    Auch möchte ich nicht UIDoc.Save im Script verwenden, da dieses Funktion dann doppelt ausgeführt wird (Performance dauert dann zu lange).


    Gibts hier ein Flag, welche ich auf Flase oder so setzten kann?
    Bei Excel-Makro gibts ja sowas.


    Danke
    Frank

    • Offizieller Beitrag

    Willkommen im Forum!


    Setze vorher ein Feld mit dem Namen "SaveOptions" auf den Wert "0" (muss Text sein). Danach kommt die Frage nach dem Speichern nicht mehr und es wird auch nicht gespeichert.


    Gruß
    Dirk

    Rein logisches Denken verschafft uns keine Erkenntnis über die wirkliche Welt.
    Alle Erkenntnis der Wirklichkeit beginnt mit der Erfahrung und endet mit ihr.
    Alle Aussagen, zu denen man auf rein logischen Wegen kommt, sind, was die Realität angeht, vollkommen leer.
    Albert Einstein

  • Danke für die Antwort.


    Leider habe ich mich wohl falsch ausgedrückt.
    Das Dokument soll schon gespeichert werden, aber halt ohne den
    User-Hinweis "Speichern?".


    Das ganze läuft in einer Routine ab.
    Dim doc As NotesDocument
    Dim docUI As NotesUIDocument
    Set db = session.CurrentDatabase
    Set dc = db.UnprocessedDocuments
    Set doc = dc.GetFirstDocument


    While Not(doc Is Nothing)


    Call wks.EditDocument(True, doc,,,, False)
    Set docUI = wks.CurrentDocument
    docUI.Refresh
    docUI.Close


    Set doc = dc.GetNextDocument(doc)

    Wend


    Beim Close wird dann das Sub Querysave Event des Formulars ausgelöst.
    Entweder wird der User beim Schließen des Doc´s nach den Speichern gefragt, oder aber mit SaveOptions=0 wird nicht gespeichert.


    Lieder muß ich das Dokument einmal refreshen, da in einem Feld eine @DBLookUp Funktion ist, die aus eine andere DB Daten einfügt.
    Sonnst würd ich das ganze ohne UIDocument realisieren.


    Ich bräuchte ne Lösung, was speichert, aber ohne Nachfragen.



    Hat da jemand eine Idee oder einen Trick ?


    Danke Frank

    • Offizieller Beitrag

    Du speicherst das Dokument nicht.


    Also zuerst Dokument speichern, dann das erwähnte Feld setzen und dann kommt Close.


    Gruß
    Dirk

    Rein logisches Denken verschafft uns keine Erkenntnis über die wirkliche Welt.
    Alle Erkenntnis der Wirklichkeit beginnt mit der Erfahrung und endet mit ihr.
    Alle Aussagen, zu denen man auf rein logischen Wegen kommt, sind, was die Realität angeht, vollkommen leer.
    Albert Einstein

  • Hi,


    vielleicht bringt es Dir ja etwas, nur auf dem doc zu arbeiten. Ein doc.computewithform erschlägt auch schon ziemlich viel. Ggf. kannst Du aber auch versuchen, Dein DBLockup per evaluate() ins Script zu "retten"

    Für jedes Problem gibt es eine einfache Lösung, die es noch schlimmer macht.

  • Dim doc As NotesDocument
    Dim docUI As NotesUIDocument
    Set db = session.CurrentDatabase
    Set dc = db.UnprocessedDocuments
    Set doc = dc.GetFirstDocument


    While Not(doc Is Nothing)


    Call wks.EditDocument(True, doc,,,, False)
    Set docUI = wks.CurrentDocument
    docUI.Refresh
    call doc.Save(True, False, True)
    doc.SaveOptions="0"

    docUI.Close


    Set doc = dc.GetNextDocument(doc)


    Wend

  • Solch ein Procedere (Dokumente aus dem Backend ins Frontend holen bzw. massenweise Frontend-Aktionen auszuführen) ist nicht das prickelnste. Deine Anmerkung NotesUIDocument.Save + NotesDocument.Save ist das nicht die wirkliche Performance-Bremse. Wirklich nicht ...


    Ich gehe davon aus, dass Du mit Code, der nur im Frontend (Maske) vorliegt, Backend-Dokumente updaten willst. Das genaue Vorhaben solltest Du aber beschreiben, sonst reden wir ganz schnell aneinander vorbei.


    Ich empfehle hier folgende Möglichkeiten - und immer möglichst im Backend:
    - Wie schon vorgeschlagen, ComputeWithForm verwenden. Das erledigt aber nicht alle im FrontEnd angeordneten Updates! @dbLookup sei da nur genannt und Items, die auf ComputedForDisplayed-Feldern basieren.
    - Mehr erreicht man mit der Formelsprache (oft unterschätzt): @Command ([ToolsRefreshAllDocs]) übertrifft ComputeWithForm (schafft aber auch nicht alles).
    - Sicher ist nur, sämtliche im Frontend programmierte Refresh-Operationen im Backend nachzuprogrammieren. Daran geht ggf. kein Weg vorbei. Wer das nicht glaubt, dem liefere ich entsprechenden Code ;)


    Wenn man denn doch den masochistischen Weg über das Frontend gehen will, dann sollte man nicht auf NotesUIDocument.Refresh schielen, sondern auf das meist völlig verkannte NotesUIWorkspace.ViewRefresh: Dieses, und nur dieses führt (fast identisch) das aus, was wir via Tastatur über F9 erreichen.


    HTH,
    Bernhard

  • Hallo,


    Zitat

    Beim Close wird dann das Sub Querysave Event des Formulars ausgelöst.


    Das ist mir neu xD


    Also normalerweise wird Querysave beim versuch das Dokument zu speichern ausgelöst. Du machst doc.save(False,False), dann geht er in das Querysave und nachdem er mit dem Querysave durch ist, speichert er erst wirklich. Nach dem eigentlichen Speichern wird Postsave aufgerufen. Wenn du nicht speicherst gibt es auch kein Aufruf des Querysave's.


    Dem nach denke ich hatte uwevino schon ganz recht mit seinem Code:
    call doc.Save(True, False, True) ' Wobei ich als Parameter (False,False) übergeben würde.
    doc.SaveOptions="0"

  • NotesUIDocument.Close triggert sehr wohl das QuerySave-Event, wenn die Property ModifiedSincedSaved True ist. Und das scheint ja der Fall zu sein.


    Was Du allerdings mit NotesDocument.Save und dem QuerySave-Event meinst, erschliesst sich mir nicht. Da das ist eine backend-Methode ist, wird natürlich nicht das QuerySave-Event dabei getriggert.


    Bernhard

  • Hallo Bernhard,


    erstmal bitte ich um Entschuldigung. Und möchte dir Danken, dass ich jetzt wieder etwas dazu gelernt habe.


    Ich habe mir gleich mal schnell eine Testmaske gebaut um zu überprüfen, was du geschrieben hast und ja, nur das Save des Front-Ends (UIDoc.Save) ruft das Querysave auf. Das Back-End tut dies nicht!


    Allerdings war meine Suche nach dem ModifiedSincedSaved nicht sehr erfolgreich. Somit konnte ich nicht überprüfen ob ein Close wirklich das Querysave aufruft, wenn ich kein Save des Front-End mache. Habe zum testen aber auch hier einmal das Close vom Front-End aufgerufen (UIDoc.Close). Da ich wie gesagt die Property ModifiedSincedSaved nicht finden konnte, hat er das Querysave an der stelle natürlich nicht ausgeführt. Es sei denn ich habe bei der Frage ob ich die Änderungen speichern möchte "Ja" Gewählt, wobei hinter dem "Ja"-Button aber auch eigendlich wieder nur ein UIDoc.Save liegt.

  • NotesUIDocument.ModifiedSinceSaved ist (leider) undokumentiert, wenn auch schon immer da: Sowie ein Dokument im Frontend eine Veränderung erfährt, wird diese Property True. Diese Property ist Read-only.


    Wenn die Property True ist, führt ein Close immer vorher zur Speichernabfrage (und dann ggf. zum QuerySave) - wenn nicht ein Item "SaveOptions" den Inhalt "0" hat.


    HTH,
    Bernhard

  • Demnach ruft ein UIDoc.Close aber immer noch nicht das Querysave auf. Das Close sorgt nur dafür, dass abgefragt wird, ob gespeichert werden soll, wenn die Property ModifiedSinceSaved True ist. Wenn in dieser Abfrage "Ja" gewählt wird, liegt hinter dem "Ja" Button so etwas wie ein UIDoc.Save, welches dann das Querysave aufruft.


    Sry, aber irgendwie haben wir aneinander vorbei geredet.


    Gruß Gerrit