IsUIDocOpen bzw. Responses

[AC]

Mal wieder eine Frage.

Hab schon einiges im Forum zum Thema gefunden, nichts trifft aber meinen Fall.

Hab hier via
IsUIDocOpen  schon im Forum gesucht, aber nicht das richtige gefunden.

Bei mir funktioniert IsUIDocOpen nur, wenn eben jenes Dokument schon mal gespeichert wurde.

Isses neu und frisch, dann lauf ich ins Leere.
Ich will es aber auch nicht schon beim Öffnen speichern lassen, damit mein IsUIDocOpen suaber funktioniert.


Hat jemand eine Idee?

Hintergrund ist folgender.

Ich hab ein Parentdokument das der User offen hat .
Dieses Parentdokument kann n response Dokumente haben.

Wenn der Benutzer das Parent offen hat und gewisse Dinge , dann will ich abprüfen, ob
nicht eins der responses auch im UI offen ist.

Ich lauf dann in einer Schleife die doccollection der Responses durch und prüfe ob eins offen ist.

Klappt eben leider nicht, wenn die Response zwar erzeugt wurde am frontend, aber noch nicht gespeichert ist.

Hat jemand eine Idee?

Merci
AC

[Glombi]

Meines Wissens nach gibt es keine Methode per Script, um herauszufinden, ob ein anderes Dokument offen ist.

Das IsUIDocOpen kommt da nur bedingt in Frage, denn in der Hilfe steht:

Read-only. Indicates whether a NotesDocument object (back-end document) is accessed through a NotesUIDocument object (front-end document).

Ich habe das allerdings noch nie benutzt...

Was vielleicht ginge: Hard-Locking für die Datenbank aktivieren und dann mit
doc.LockHolders
abfragen, ob jemand das Dokument gesperrt hat.

Andreas

[AC]

Morgen Glombi,

danke für die Antwort.

So wie es in der Hilfe steht, würde es ja funktionieren, wenn ja wenn siehe oben - das Dokument nicht neu wäre.

Problem ist schon, daß ich mit meiner
dc= doc.responses Abfrage
frische am UI offene ungespeicherte responses nicht erwische.


Mist, irgendwas muß ich mir überlegen um Userfehler abzufangen.

Locken brauch ich nichts, weil es jeweils nur ein User offen hat und ich nicht die Problematik habe, daß ein anderer Benutzer gerade darauf zugreift.

Alexander

[umi]

Ich denke das geht so nicht.
Da ja der Kontext unterschiedlich ist: Person A hat das Dokument offen und Person B hat die Response offen, da gibts keine Verbindung dazwischen. (vor allem wenn Person A lokal und Peson B das Dokument auf dem Server geöffnet hat...)

Ist es denn möglich, dass ein neues Dokument schon Responses hat ?

[AC]

Ich denke das geht so nicht.
Da ja der Kontext unterschiedlich ist: Person A hat das Dokument offen und Person B hat die Response offen, da gibts keine Verbindung dazwischen. (vor allem wenn Person A lokal und Peson B das Dokument auf dem Server geöffnet hat...)

Ist es denn möglich, dass ein neues Dokument schon Responses hat ?

Guten morgen

Ich habe nicht das Problem, daß mehrere Benutzer in dem Fall herumfuhrwerken (jeder schreibt seine eigenen Aufträge und eh meistens lokal offline auf seiner Replik).

Im Hauptdokument das grade im frontend ist, gibt es eine aktion die dann via Backend nochmal in den responses was neuberechnet und dann die Responses neu speichert.

Was ich nicht will, dass diese Aktion dann berechnet wird, wenn ein responsedocument noch "offen" im edit mode am desktop ist.

deshalb hab ich zuvor eine Prufung  wie oben beschrieben, ob was offen ist.
Klappt auch ganz gut, bis auf en Fall dass meine jeweiligen user grade ein neues responsedoc anlegen, dann wieder zurückwechseln ins hauptdoument und dann die AKtion auskösen.

Das hätte ich gerne elegant abgewickelt.


Merci, AC

[umi]

Wie werden die Responses erstellt? Kannst Du da nicht ein Flag setzen beim Erstellen/Öffnen der Response?
z.B. in ein Profile (Ob jetzt als NotesProfileDocument oder über die Profil klasse sei mal dahingestellt)

[AC]

Wie werden die Responses erstellt? Kannst Du da nicht ein Flag setzen beim Erstellen/Öffnen der Response?
z.B. in ein Profile (Ob jetzt als NotesProfileDocument oder über die Profil klasse sei mal dahingestellt)

Die Responses werden auch via einen Button aus derm geöffnetem Hauptdokument jeweils erstellt (per script).

Ansowas was DU schreibst habe ich auch gedacht. Wollte nur wissen, ob es nicht einfacher auch geht.

Zu Deinem Vorschlag:
Hab mir grob überlegt, wenn ich es dann mit einem Flag machen müsste, diesen Flag beim erstellen des responses dann zu setzte.
Im Terminate beim responsedoc müsste ich dann das Flag wieder löschen (egal ob das response gespeichert wird oder der User es wieder verwirft und nicht speichert).

Schliesslich müsste ich auch noch abfangen, wenn mir der client mal crashen sollte. dass ich dann beim erneuten Öffnen der DB nachgucke und eventuell Leichen noch beseitige......

Und was weiß ich an welche Eventualitäten ich dann noch denken müsste, wenn ich das mit einem Flag löse.

Auch muss ich dann mehrere Flags in eine liste setzen, wenn meine User auf die Idee kommen, n responses auf einmal aufzumachen und nix zu speichern (alles schon erlebt) .

So ein Heidenaufwand für so eine winzige Kleinigkeit. <seufz>
Da ich das ganze natürlich eher gestern als heute brauche (siehe meine Uhrzeit des Postings heute nacht) , wäre mir ein "schneller" zu programmierende Lösung lieber .
 
Wenn jemand noch einen Geistesblitz hat (meine Kretaivität ist wegen Schlafmangel gerade auch eingeschränkt) dann rufe ich laut welcome.

AC

[Glombi]

Wenn es ein neues Antwortdokument ist, dann im Querysave die Info aus dem Hauptdokument holen.

Andreas

[AC]

Wenn es ein neues Antwortdokument ist, dann im Querysave die Info aus dem Hauptdokument holen.

Andreas

Versteh ich jetzt nicht was Du meinst.
Ich hab ja nur das Problem dass ich nicht feststellen kann, ob ein responsedoument geöffnet ist, wenn es noch NICHT gespeichert ist.
Dann nützt mir doch das qs im Responsedoc nicht.


Problem nur, wenn User ein neues response anlegt, das nicht speichert, wieder zurückgeht ins Hauptdokument, wo ich eben abprüfe, ob eine der responses "offen" ist.
Und hier kriegen ich eben nicht das noch nicht gespeicherte noch offene response mit.

Oder seh ich was falsch auf Grund der Müdigkeit? <auch gut möglich>

Alex

[umi]

Also für die n Responses genügt es anstatt einem Binären Flag ein zähl Flag zu verwenden
0 = keine Antwort
1 = eine
n = n antworten

Und zum Thema crash: evtl. könntest Du im QueryOpen der DB das Flag resetten....

[AC]

Also für die n Responses genügt es anstatt einem Binären Flag ein zähl Flag zu verwenden
0 = keine Antwort
1 = eine
n = n antworten

Und zum Thema crash: evtl. könntest Du im QueryOpen der DB das Flag resetten....

Das mit dem Crash ist klar.genau queryopen der db dann das säubern triggern.

Jaaaa, ein Zähler im Kopfdokument, den ich beim erstellen der responses jeweils erhöhe.
Bekomme ich, dann bei meinem dc.count für doc.responses weniger, dann weiß ich, dass ein noch nicht gespeichertes offen sein muß.

Richtig?

Hab Brett vor Kopf und Scheuklappen auf um noch denken zu können.

Danke :-))
AC

[umi]

Null Problemo.

[AC]

Schönes Wochenende allen hier !!!!

Alex

[Tode]

jetzt mal ganz blöde gefragt:

Warum willst Du wissen, ob responses offen sind ?

Willst Du Feld- werte in die Responses schreiben, wenn das Hauptdokument gespeichert wird ?
Oder willst Du das speichern des Haupt- Dokumentes verhindern, wenn noch Antworten offen sind ?

Für den ersten Fall kannst Du doch ganz simpel mit Document- Locking arbeiten:

set dc = doc.Responses
dc durchlaufen, prüfen, ob das Dokument gelockt ist, und wenn das der Fall ist, dann nichts tun.
Die "offenen" Dokumente werden ja auch irgendwann mal wieder geschlossen, und dann kannst Du ja dort die Felder "nachfüllen", die nicht gefüllt werden konnten, weil das doc offen war...


Oder liege ich da völlig falsch !?

Tode

[AC]

Ich will beides erreichen.

Was die ganze Sache nicht einfacher macht, daß ich auf eine bereits lange existierende Lösung aufsetzen muß und eben die  Gegebenheiten berücksichtigen muß.

Im Hauptdokument habe ich Informationen wie Währung, Kundenpreislistenkennzeichen, Auftragsdatum (auch wichtig für Preisfindung)
Und dann Gesamtmenge und Gesamtpresie.


In den Responses habe ich die einzelnen Artikel mit Preis

Nun hängt aber der Preis eben von den ganzen Faktoren des Hauptdoumentes ab.

Wird nun nachträglich im Hauptdoument was geändert müssen natürlich des Responses auch nochmal neu berechnet werden (es wird ein anderer Kunde im Ausland gewählt mit anderer Währung und anderen Preisen).

Hier will ich abfangen, dass eben noch response Dokumente offen sind.

Im Endeffekt bedingen sich Haupt und Responsedokumente gegenseitig und  ich muß aufpassen, wenn jemand wie wild hier DInge gleichzeitig verändert.

Ferner hatten wir hier noch ein anderes Problem wo sich dann später für den LEI ein dopperlter Schlüsselwert ergeben hat, wenn der User eben nicht aufpasst. Aber das würde jetzt zu weit führen........

 
mit set dc = doc.responses kriege ich ja nicht die noch nicht gespeicherten neuen Responsedokumente. Das war ja mit das Kernproblem.

Nur das was DU mit Nachfüllen meinst, verstehe ich jetzt nicht ganz.
Und wie meinst Du das genau mit dem locken?

Dass ein anderer User auf ein solches Dokument (sei es die Response oder auch das Hauptdokument) zugreift, diese Problematik habe ich ja nicht.

Merci, Alex

[koehlerbv]

Kannst Du die Berechnungen nicht im QuerySave des ResponseDoc und im PostRecalc des ParentDocuments machen? Dann können die Leute doch wild hin- und herspringen ...

Bernhard

[AC]

Kannst Du die Berechnungen nicht im QuerySave des ResponseDoc und im PostRecalc des ParentDocuments machen? Dann können die Leute doch wild hin- und herspringen ...

Bernhard

Mach ich ja auch.
Was ist, wenn ein ungespeichertes offen ist, das Hauptdokument gespeichert wird, dann aber das ungeöffnete Response dann auch wieder gespeichert wird.

Hierzu müsste ich dann bei jedem Spiechern eines response dokumentes auch noch mal die Routine starten, die dann über ALLE responses rauscht und dann die SUmmen wiederum ins geschlossene Hauptdokument reinschreibt (und ggf im Hauptdokument nochmal überprüft,ob sich nicht irgendwelche Modalitäten im Hauptdokument nicht wieder durch Benutzeraktion geändert haben) .

Ginge auch, müsste dann das aber wiederum rein programmieren und sagen wir mal bei 30 oder 40 Responses würde ja auch genauso oft das berechnet werden müssen.

Eigentlich wenn ide User brav wären und das tun was ihnen gelernt wird, sollten sie das Hauptdokument erstellen, dann das erste Resonse, diese wieder schliessen und speichern, dann das nächste usw.
Am ende dann das noch offene Hauptdokument auch speichern und alles ist in Butter.
Gruß
Alex

[LN4ever]

Im Hauptdokument sitzt ein Button zum Erzeugen eines Response-Docs. Diese Schaltfläche ist nur im LESE-Modus zu sehen und erstellt ein Responsedoc nur, wenn im Profildokument nicht die UNID des Hauptdokuments steht.

Beim Erstellen des Response-Docs schreibst du in ein Userprofildokument die UNID des Hauptdokuments. Und im QUERYOPEN und QUERYMODECHANGE des Hauptdockuments prüfst du, ob im Profildokument die UNID des Hauptdokuments steht. Wenn Ja - CONTINUE=FALSE.

Damit ist gewährleistet, daß dieser User das Hauptdokument nicht bearbeitet, während das Responsedoc noch offen ist.

Im QUERYCLOSE des Response-Dokuments wird dann der Profildokumenteintrag gelöscht.

Zudem wird im Terminate der DB das Feld im Profildokument gelöscht (damit fängst du Crashes ab).

Man kann das noch ausbauen, indem du im Profildokument sowohl die UNID des Parents als auch die eigene einträgst. Dann kannst du den Fall behandeln, daß jemand gleichzeitig mehrere Responses vom Hauptdokument erstellt.

[Tode]

noch mal ein neuer Ansatz:
öffne alle Antwort- Dokumente grundsätzlich als Dialogbox.

Damit kann der Benutzer nichts anderes machen, so lange er die Antwort ausfüllt. und er MUSS das Antwort- Dokument schliessen, bevor er ein neues anlegt bzw. das Haupt- Dokument speichert.

Für ein wenig mehr Komfort kannst Du ja auch in die Dialog- Maske des Antowrt- Dokuments ein "speichern und nächstes" oder sogar eine ganze Navigation durch die Antwortdokumente einbauen...

HTH
Tode

[AC]

nochmal ein Danke, an beide Antworter (tode und LN4ever).

An LN4ever lösung hab ich auch gedacht, auf Todes Vorschlag wäre ich nicht gekommen - so kretaiv habe ich nicht gedacht.

Wieder was dazugelernt.

Gruß, Alex