AtNotes Übersicht Willkommen Gast. Bitte einloggen oder registrieren.
17.02.19 - 04:21:49
Übersicht Hilfe Regeln Glossar Suche Einloggen Registrieren
News:
Schnellsuche:
+  Das Notes Forum
|-+  Lotus Notes / Domino 9
| |-+  ND9: Entwicklung (Moderatoren: Axel, eknori, Thomas Schulte, koehlerbv, m3)
| | |-+  QueryOpen wird nicht ausgeführt
« vorheriges nächstes »
Seiten: [1] Nach unten Drucken
Autor Thema: QueryOpen wird nicht ausgeführt  (Gelesen 225 mal)
FrankLU
Junior Mitglied
**
Offline Offline

Geschlecht: Männlich
Beiträge: 66



« am: 08.02.19 - 15:29:15 »

Hallo,

ich bin auf ein Problem gestoßen, dass mir nun wahrscheinlich das Wochenende vermiesen wird, weil mir keine Lösung einfallen will.

Ausgangssituation:
Wenn ich in einer Datenbank ein Dokument öffne, lege ich in einer zweiten Datenbank ein SperrDoc an. Im QueryOpen des uiDoc wird anhand der doc.UniversalID geprüft, ob in der Sperrsatz-DB ein SperrDoc mir einer solchen UNID vorhanden ist. Wenn ja, kann bekommt der User einen Hinweis und kann das Dokument nicht öffnen.
Im QueryClose wird das SperrDoc dann über die UNID gefunden und gelöscht.

Problem:
Das Dokument ist geöffnet, das SperrDoc erstellt. Nun möchte ich per Masken-Knopf eine Dokumentenverknüpfung in ein RichTextFeld (RTF) einfügen. Das Knopf-Scribt ruft die Function DokLnkEinf in einer Scriptlibrary auf. Das klappt auch alles wunderbar.

Um nun das neue bzw. geänderte RTF nun auch im uiDoc sichtbar zu machen, wird zum Schluss des Knopf-Scripts das Hintergrund-Dokument gespeichert, das uiDoc geschlossen, um dann gleich neu geladen zu werden. Das klappt auch. Aber:

Beim Schließen des uiDocs wird der QueryClose ausgeführt und das SperrDoc gelöscht. Beim erneuten Öffnen des uiDocs wird aber der QueryOpen nicht wieder ausgeführt, das heißt, es wird kein neues SperrDoc angelegt. Warum?

Code:
(Declarations)
Dim ws as NotesUIWorkspace
Dim doc as NotesDocument
Dim uiDoc as NotesUIDocument

Sub Initialize
Set ws = New NotesUIWorkspace
End Sub

Function DokLnkEinf
Set uiDoc = ws.CurrentDocument
Set doc = uiDoc.Document
...
Call doc.Save(True, False)
Call uiDoc.Close(True)
Set uiDoc = ws.EditDocument(True, doc)
End Function

Ich habe es auch schon mit Löschen des uiDocs versucht oder mit dem Nachlesen des Docs aus der DB.

Code:
DocUID = doc.UniversalID
Call doc.Save(True, False)
Call uiDoc.Close(True)
Set uiDoc = Nothing
Set doc = db.GetDocumentByUNID(DocUID)
Set uiDoc = ws.EditDocument(True, doc)

Auch hier wird das angezeigte Doc geschlossen, und das Doc in einem neuen Reiter geöffnet. Das sieht man, wenn das bearbeitet Doc, das seinen Reiter zwischen anderen Reitern hatte, mit einem mal im letzten Reiter angezeigt wird.

Auch ein zweites uiDoc, wie
Code:
Set uiDocNeu = ws.EditDocument(True, doc)
als letzte Zeile hat nicht geholfen.

Ich habe in den Code für den QueryOpen und den QueryClose einen
Code:
Print "QueryOpen"
bzw
Code:
Print "QueryClose"
eingefügt, aber ein zweites "QueryOpen" wird nicht in der Statuszeile ausgegeben.

Wie bekomme ich den QueryOpen ausgeführt? Ich wollte ungerne den Code im QueryOpen nochmal in das Knopf-Script einfügen.

Schönes Wochenende!
Frank
« Letzte Änderung: 11.02.19 - 16:10:29 von FrankLU » Gespeichert

Frank Lohöfer
MD Medicus Holding GmbH
Client (User): 8.5.3
Client (Admin): 9.0
Server: 9.0 auf Linux
Tode
Moderatoren
Gold Platin u.s.w. member:)
*****
Offline Offline

Geschlecht: Männlich
Beiträge: 6156


Geht nicht, gibt's (fast) nicht... *g*


« Antworten #1 am: 08.02.19 - 15:58:44 »

Das Problem kommt daher, dass ein Dokument, das neu erstellt wurde und nach dem speichern noch nicht wieder geschlossen und erneut geöffnet wurde irgendwie einen "seltsamen" Status in Notes hat.


Ich glaube nicht, dass Du das umgehen kannst, deshalb würde ich das Problem andersrum aufzäumen: ich würde in meinem Reopen- Script eine z.B Umgebungsvariable setzen.
Im QueryClose würde ich dann abfragen, ob die Variable gesetzt ist, und wenn ja: Lock- Doc nicht löschen....

Ein anderer Ansatz wäre: Du verwendest das (nicht dokumentierte) NotesUIDocument.ImportItem wie es in der InserSignature- Funktion der CoreEmailClasses in der Mailschablone verwendet wird:

Du baust Dir Deinen Doclink in einem Richtextitem in einem Profil- Dokument (inklusive speichern natürlich) und verwendet dann:

Code:
Call uiDoc.ImportItem(profileDoc, "Signature_Rich")

Voraussetzung: Dein Cursor steht im Richtextfeld und das ist editierbar...
Gespeichert

Gruss
Torsten (Tode)

P.S.: Da mein Nickname immer mal wieder für Verwirrung sorgt: Tode hat NICHTS mit Tod zu tun. So klingt es einfach, wenn ein 2- Jähriger versucht "Torsten" zu sagen...

Mit jedem Tag meines Lebens erhöht sich zwangsweise die Zahl derer...
... denen ich am AdminCamp ein Bier schulde... Wenn ich hier jemanden angehe: Das ist nie persönlich, sondern immer gegen die "Sparwut" der Firmen gedacht, die ungeschultes Personal in die Administration unternehmenskritischer Systeme werfen... Sprecht mich einfach am AdminCamp an, ich zahle gerne zur "Wiedergutmachung" das ein oder andere Bierchen an der Bar
FrankLU
Junior Mitglied
**
Offline Offline

Geschlecht: Männlich
Beiträge: 66



« Antworten #2 am: 11.02.19 - 11:28:35 »

Hallo Tode!

Vielen Dank für Deine Ideen! Die Woche ist jetzt schon gerettet!  Grin

Ich denke ich, werde das mit der Variable im ReOpen-Script umsetzen. Das ist am genialsten, da ich mehrere Dokumentarten habe, in denen ich DokLInks hinzufüge oder auch selektiv lösche und nur eine Function zum Anlegen des SperrDocs.

Ich habe das Problem übrigens auch bei "alten" Dokumenten, in die ich einen DokLink einfügen will, nicht nur bei denen, die eben erst erstellt wurden.

Danke nochmals! Schönen Start in die neue Woche!

Frank
« Letzte Änderung: 11.02.19 - 14:25:26 von FrankLU » Gespeichert

Frank Lohöfer
MD Medicus Holding GmbH
Client (User): 8.5.3
Client (Admin): 9.0
Server: 9.0 auf Linux
FrankLU
Junior Mitglied
**
Offline Offline

Geschlecht: Männlich
Beiträge: 66



« Antworten #3 am: 11.02.19 - 15:33:38 »

Hallo nochmal,

leider klappte das mit dem Setzen einer Variablen doch nicht so, wie ich es erhofft hatte. Es traten mehrere Probleme auf.

Das Hauptproblem: Der ws.EditDocument öffnet ein zweites uiDoc, anstatt erst das eine uiDoc zu schließen und dann das andere uiDoc zu öffnen, trotzdem der uiDoc.Close ein "True" enthält.

1. Problem

Code:
Call doc.Save(True, False)
doc.DelLock = "N"
doc.SaveOptions = 0
Call uiDoc.Close(True)
Set uiDoc = ws.EditDocument(True, doc)

Diese Version klappt nur bei uiDocs, die sich im Schreib-Modus befinden. Nur dann wird der Feldwert von DelLock an das uiDoc weitergegeben. Das ist aber wichtig, weil im QueryClose nur das uiDoc übergeben wird. Ein uiDoc.FieldSetText oder ein uiDoc.Refresh setzt ebenfalls ein uiDoc im Schreib-Modus voraus. Bei uiDocs, die nur im Lese-Modus ihr RT-Feld erhalten/verändert bekommen, wird ein leeres DelLock im QueryClose übergeben.

2. Problem

Es werden zwei uiDocs geöffnet, die beide den Feldwert DelLock = "N" enthalten. Das erste uiDoc wird geschlossen, das zweite bleibt mit gesetztem Feldwert stehen. Wie bekomme ich den Feldwert wieder zurück gesetzt? Wenn sich das uiDoc im Lese-Modus befände, könnte ich den Feld-Wert über einen Bearbeiten-Knopf zurücksetzen. Wenn aber der User das Dokument einfach schießt (egal, in welchem Edit-Modus), bleibt der Feldwert erhalten und das SperrDoc wird nie gelöscht. Und den Feldwert im QueryOpen zurückzusetzen funktioniert ja nicht und ist ja das grundlegende Problem.

3. Problem

Code:
Call doc.Save(True, False)
doc.DelLock = "N"
doc.SaveOptions = 0
Call uiDoc.Close(True)
Set uiDoc = ws.EditDocument(True, doc)
doc.DelLock = ""

Dieser Code funktioniert auch nicht, weil es zum Ausführungszeitpunkt zwei gleiche uiDocs gibt. In beiden (!) wird das Feld DelLock also zurückgesetzt, bevor er im QueryClose des ersten uiDoc verarbeitet werden kann. Das SperrDoc wird also auch hier immer gelöscht und bleibt nicht bestehen.

Lösung

Noch keine.  Cry

Bevor nicht alles an Scripten gelaufen ist, wird das erste uiDoc nicht geschlossen. Daher nützt es auch nichts, im Knopf zum Aufrufen der Erstellung/Änderung des RT-Felds abschließend quasi manuell einen neuen Sperrsatz durch Aufruf der entsprechenden Function anlegen zu wollen, nachdem alle Functions der Script-Library der RT-Feld-Änderung ausgeführt wurden. Denn der Sperrsatz ist schon da und wird dann gelöscht, wenn das erste uiDoc geschlossen wird.

Danke nochmals für Eure Hilfe.
« Letzte Änderung: 11.02.19 - 15:51:45 von FrankLU » Gespeichert

Frank Lohöfer
MD Medicus Holding GmbH
Client (User): 8.5.3
Client (Admin): 9.0
Server: 9.0 auf Linux
Peter Klett
Gold Platin u.s.w. member:)
*****
Offline Offline

Geschlecht: Männlich
Beiträge: 2575



« Antworten #4 am: 11.02.19 - 16:13:22 »

Wenn ich es richtig verstehe, ist das ReOpen das einzige Problem.

Wenn Du in der Aktion des ReOpen in das Sperrdoc den aktuellen User als ReOpen-User einträgst, könntest Du beim Schließen des Dokuments auf das Löschen des Sperrdocs verzichten, und beim Öffnen auf die Anlage/Überprüfung (immer unter der Voraussetzung, der User ist der ReOpen-User). Dann suchst Du noch das spätestmögliche Event des zu schließenden Dokuments (vielleicht das Terminate des ersten Dokuments oder das PostOpen des zweiten Dokuments?) um den ReOpen-User zu entfernen.

Ist nur eine Idee ohne sie jemals praktisch ausprobiert zu haben
Gespeichert
FrankLU
Junior Mitglied
**
Offline Offline

Geschlecht: Männlich
Beiträge: 66



« Antworten #5 am: 11.02.19 - 16:17:34 »

Vielen Dank für die Idee. Inzwischen bin ich selber auf eine andere Lösung gekommen.

Lösung

Nachdem ich meine Routine zur SperrDoc-Erstellung davon überzeugt habe, zuzulassen, ein zweites SperrDoc zu einem Doc anzulegen, funktioniert es. Zwar wird nach dem Schließen des ersten uiDocs ein SperrDoc gelöscht, aber dann ist schon ein zweites SperrDoc für das zweite uiDoc da, das ich zuvor im Knopf zur Erstellung/Änderung des RT-Felds erzeugt habe. Wird auch das geschlossen, sind alle SperrDocs weg.

Nun muss ich nur aufpassen, dass ich das zweite SperrDoc nicht erzeuge, wenn es der User sich anders überlegt und die Bearbeitung des RT-Feld abbricht, es also nicht notwendig ist, das uiDoc zu erneut zu laden.

 Grin
« Letzte Änderung: 11.02.19 - 16:22:14 von FrankLU » Gespeichert

Frank Lohöfer
MD Medicus Holding GmbH
Client (User): 8.5.3
Client (Admin): 9.0
Server: 9.0 auf Linux
Peter Klett
Gold Platin u.s.w. member:)
*****
Offline Offline

Geschlecht: Männlich
Beiträge: 2575



« Antworten #6 am: 11.02.19 - 16:30:24 »

Das Problem hast Du aber vermutlich immer. Ein STRG-Pause oder ein abgerauchter Client könnte ein Sperdoc stehen lassen. Räumt Ihr die heute manuell auf? Evtl. könnte man ein Sperrdoc mit enem zu definierenden Alter als nicht mehr relevant interpretieren
Gespeichert
FrankLU
Junior Mitglied
**
Offline Offline

Geschlecht: Männlich
Beiträge: 66



« Antworten #7 am: 11.02.19 - 17:33:55 »

Ein User kann seine von ihm erstellten SperrDocs immer selber löschen, der Rest wird manuell beseitigt.

Da eine Information über einen gesperrtes Dokument auch enthält, wer es sperrt, kann derjenige dann direkt gebeten werden, das Dokument zu schließen. Den Rest übernimmt ein User im Nachdienst, wenn er dann alleine in der DB arbeitet. Bisher gab es da kaum Probleme.

Leider lassen ein paar der lieben Kollegen Dokumente u.U. über viele Stunden offen, so dass man kaum die Chance hat, einen Agenten laufen zu lassen, um alte SperrDocs zu löschen, die ein gewisses Alter überschritten haben.
Gespeichert

Frank Lohöfer
MD Medicus Holding GmbH
Client (User): 8.5.3
Client (Admin): 9.0
Server: 9.0 auf Linux
Seiten: [1] Nach oben Drucken 
« vorheriges nächstes »
Gehe zu:  


Einloggen mit Benutzername, Passwort und Sitzungslänge

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2006, Simple Machines Prüfe XHTML 1.0 Prüfe CSS
Impressum Atnotes.de - Powered by Syslords Solutions - Datenschutz | Partner: