HCL Notes / Domino / Diverses > Entwicklung

Umschalten von uiDocs funktioniert nicht (mehr)

(1/2) > >>

FrankLU:
Hallo Notes-Gemeinde,

seit vielen Jahren läuft bei uns ein Code ohne Probleme. Seit dem ich mit V12 entwickele, gibt es an einer Stelle ein Problem.

Als medizinischer Servicedienstleister existieren in einer unserer DB Patieten-Dokumente (docPat), zu denen Gesprächs-Dokumente (docGes) als Antworten erstellt werden.
Wird ein solches Gespräch als "beendet" gekennzeichnet, so müssen Daten, wie Anamnese, Diagnose oder ein ICD10-Schlüssel in die Stammakte übernommen werden, um bei einem Folgegespräch zur Verfügung zu stehen.
Für Dokumente, die zum Lesen geöffnet werden, werden Sperrsätze erzeugt bzw. geprüft, ob ein Sperrsatz exitiert. Wird das Dokument wieder geschlossen, wird der Sperrsatz gelöscht.

Situation: Das Gesprächs-Dokument ist im Edit-Modus geöffnet und soll mit dem Status "beendet" gespeichert und geschlossen werden. Dabei kann die Situation bestehen, dass

* das Patienten-Dokument durch einen anderen MA im Zugriff ist; Sperrsatz da, Rückgabe: "gesperrt"
* man selber das Patienten-Dokument im Read-Modus geöffnet hat; Sperrsatz da, Rückgabe "selbst"
* man selber das Patienten-Dokument im Edit-Modus geöffnet hat; Sperrsatz da, Rückgabe "selbst"
* kein Sprrsatz da, Rückgabe: "frei"; Sperrsatz für docPat wird dann angelegt
Im ersten Fall wird eine Meldung ausgegeben und ggf. die Verarbeitung beendet (siehe Schleife "Versuch").
Bei Fall zwei und drei wird auf das Vordergrund-Dokument des Patienten-Dokuments umgeschaltet, um den EditMode festzustellen:
Ist das Vordergrund-Patienten-Dokument im Read-Modus (zweiter Fall), wird es geschlossen und nur im Hintergrund erneut geöffnet.
Ist das Vordergrund-Patienten-Dokument im Edit-Modus (dritter Fall), wird wieder auf das Vordergrund-Gesprächs-Dokument umgeschaltet.

Der Code dazu ist folgender:

--- Code: --- Set uiDocGes = ws.CurrentDocument
Set docGes = uiDoc.Document

...

'Lesen und Prüfen, ob docPat gesperrt ist;
Set docPat = db.GetDocumentByUNID(docGes.PatDocUID(0))

Versuch:
Call CreateLck(docPat.PatDocUID(0), EditStatus, docPat.PatID(0)) 'EditStatus = "frei", wenn nicht im Zugriff

If EditStatus = "gesperrt" Then
antwort = Messagebox("Zur weiteren Bearbeitung muss die Stammakte bearbeitbar sein." + Chr(13) _
+ "Sie haben die Stammakte freigeben lassen und wiederholen den Versuch -> Ja?" + Chr(13) _
+ "Das Gespräch wird nur gespeichert, es erfolgt KEINE Datenübernahme in die Stammakte! -> Nein", _
+ mb_yesno + mb_iconquestion, "TEO - Stammakte gesperrt - Freigeben lassen?")

If antwort = 6 Then 'Yes
Goto Versuch
Else
NoLck = False
End If
Else
If EditStatus = "selbst" Then

'Umschalten auf das Register mit docPat, um EditMode zu prüfen
+++ Fehler Set uiDocPat = ws.EditDocument(False, docPat,,,, False)

'>>> neu eingefügt, als der Debugger zeigte, dass zwar zum Register mit docPat umgeschaltet wird, aber uiDocPat leer blieb
Set uiDocPat = ws.CurrentDocument

If uiDocPat.EditMode = False Then 'geladenes Dokument im Read-Modus; es muss zur Aktualisierung geschlossen werden
uiDocPat.Close(True) 'Sperrsatz wird im QueryClose gelöscht
PatDocEditStatus = False
EditStatus = ""
Set docPat = db.GetDocumentByUNID(doc.PatDocUID(0)) 'durch uiDoc.Close wird das Objekt docPat zerstört, darum Nachlesen
Call CreateLck(docPat.PatDocUID(0), EditStatus, docPat.PatID(0))
Else
PatDocEditStatus = True 'geladenes Dokument im Edit-Modus; Aktualisierung geschieht automatisch in der Anzeige
End If

'wieder zurück umschalten auf das Register mit docGes
Set uiDocGes = ws.EditDocument (False, docGes,,,,False)

'>>> neu eingefügt, als der Debugger zeigte, dass zwar zum Register mit docGes umgeschaltet wird, aber uiDocGes leer blieb
Set uiDocGes = ws.CurrentDocument
Else
PatDocEditStatus = False 'EditStaus = "frei", docPat nirgends geladen
End If
NoLck = True
End If

...

--- Ende Code ---
Der Fehler tritt an der Stelle auf, an dem auf das uiDocPat umgeschaltet werden soll. Der OnError gibt eine Meldung ins Agents Log "Unable to find Document Window" Eine Suche hier im Forum ergab den Fehlercode 4405. Aber ob es wirklich der Fehler 4405 ist, kann ich nicht sagen, da leider keine Fehlernummer ausgegeben wird, obwohl dies im LogError-Befehl codiert ist.

Ich hatte nach 4405 im Forum geguckt, und hatte die Erkenntnis gewonnen, dass der Fehler auftreten kann, aber nicht unbedingt die Verarbeitung abbrechen muss. Nachdem der Debugger zeigte, dass das Umschalten zu uiDocPat trotz Auftreten des Fehlers gelang, uiDocPat aber "nothing" war, habe ich einen ws.CurrentDocument hinterhergeschoben. Dann war auch das uiDocPat da.

Inzwischen vermute ich, dass es leider doch nicht der Fehler 4405 ist, nachdem ich für ihn eine eigene Fehlerroutine programmiert habe, die aber nie angesprungen wurde. Und auch die Verarbeitung bricht ab. Aber welcher Fehler ist es? Der Fehler tritt auch nicht immer auf. In meinen Tests trat er nie auf! Und warum funktioniert der Code seit vielen Jahren fehlerfrei und mit einem Mal öfter nicht mehr?

Für Tipps wäre ich dankbar.

Liebe Grüße
Frank

CarstenH:
Hab mal einen Blick in die StringTable geworfen, das sollte der passende Code sein (siehe Screenshot).

Der Rest klingt nach einem Fokus Problem zwischen offenen Fenstern, Frames usw. Der Verursacher muss nicht mal im Notes liegen.

HTH
Carsten

FrankLU:
Hallo Carsten!

Danke für Deinen Hinweis. Ich kann es auch mal mit der Abfrage des Fehlercodes 12272 probieren, frage mich aber, warum der Fehlercode nicht im LogError ausgegeben wird. Der Befehl ist ja nun nicht so kompliziert:

--- Code: ---Call logfile.LogError(Err, "Beendet " + Error$ + " in line " + Erl)
--- Ende Code ---

Ich habe mal hinter fast jeden Befehl in meinem gesendeten Code-Ausschnitt einen LogAction-Befehl gesetzt, um sicher zu sein, dass die Zeilenangabe im LogError-Befehl stimmt. Und siehe da: Das Programm tut, was es soll, findet seine Fenster, liefert keine Fehler und schaltet zwischen den Registern richtig hin und her. Nur wird jetzt das Agents Log zugemüllt, was ich auch nicht so toll finde.

Was mache ich jetzt?  ??? Die LogAction-Befehle drinlassen? Oder hat der Interpreter ein Problem, bzw. ist die Ausführungsebene zu langsam? Wurde der Code durch die vielen Änderungen erst jetzt "richtig" übersetzt? Soll ich Sprünge zu Speudo-Functions machen, um Zeit zu schinden?  ;)

Was könnte das Verhalten denn noch verursachen? Die Grafikkarte?

Schönen Dienstag
Frank

CarstenH:
Hallo Frank,

ich selbst hatte das Problem noch nicht. Nachdem ich mich da gestern mal durch diverse Foren geklickt habe fand ich einen APAR bei IBM der das Verhalten auf den Punkt bringt:


--- Zitat ---You have an application that has a LotusScript action in a
document that composes a new document in a separate frame.
This action works fine in the Notes basic client but fails in
the Standard client.
Also if you debug the code with the LotusScript Debugger then
the it works as expected
--- Ende Zitat ---

Quelle: https://www.ibm.com/support/pages/apar/LO59636

Es ist also ein Problem des (langsameren) Eclipse Clients, der hier scheinbar nicht hinterher kommt.

Vermutung/Idee: Verschafft man dem Ecplipsegeraffel Zeit, indem man das Framework mit dem Debugger oder zusätzlichen Befehlen (wie du mit dem Log) "beschäftigt" klappt es. Vielleicht reichen ja schon ein paar vereinzelte Sleep Statements an den richtigen Stellen statt wirklich aktiv was zu tun oder wiederholt SetTargetFrame einfach 2-3x damit es auch wirklich ankommt ;) Da würde ich jetzt ansetzen.

HTH
Carsten

Werner Götz:
Sleep usw. würde ich hier nicht unbedingt einsetzen.

Ich habe bei mir in solchen Situationen meist entweder eine MsgBox eingebaut mit einem Hinweis, der zwar etwas nervt aber die Situation halt rettet ("Das Patienten-Dokument wurde geöffnet, Sie können jetzt ...") oder einen sich selbst wieder schließenden Dialog, der sowas anzeigt wie "Interne Verarbeitung, bitte warten ...". Dies konnte solche Fokus-Probleme meist retten.

-Werner

Navigation

[0] Themen-Index

[#] Nächste Seite