Verkettung von Dialogboxen

[Driri]

Hallo,

ich versuche mich gerade an einer Anwendung, mit der Checklisten verwaltet und ausgefüllt werden können. Meine Idee war, die einzelnen Fragen einer Checkliste in Form von einzelnen Dokumenten anzulegen und diese dann via Dialogbox durch die Anwender ausfüllen zu lassen. D.h. beim Start der Funktion wird für den Anwender ein Set Dokumente angelegt und das erste aus der Reihe öffnet sich in einer Dialogbox.

Und jetzt fangen die Probleme an.  

Ich habe keine Möglichkeit gefunden, in der Dialogbox ein neues Dokument zu öffnen. Daher wird man vermutlich das Dokument schließen müssen und anschließend das nächste Dokument in der Reihe in einer neuen Dialogbox öffnen.

Aufruf erste Dialogbox:

Call ws.DialogBox("CLDialog",True,True,True,False,False,False,"Checkliste",firstdoc,False,True,False)

In der Dialogmaske habe ich eine eigene Schaltfläche hinzugefügt, die einfach nur ein Close absetzt :

Dim ws As New NotesUIWorkspace
ws.CurrentDocument.Close   

Im QueryClose der Maske für die Dialogbox habe ich ein NotesUIWorkspace.RefreshParentNote() eingebaut, um die Eingabewerte in das Backend zu schreiben. Das funktioniert aber nicht, die Werte im Dokument bleiben unverändert.

Im Aufruf der Dialogbox habe ich die Änderung aber zugelassen (siehe oben) und die Feldnamen in der Dialogmaske sind identisch zu denen in der Dokumentmaske.

In den Dokumenten gibt es eine Indexnummer für die Reihenfolge der Fragen. Ich wollte jetzt im QueryClose der Dialogbox die aktuelle Indexnummer abgreifen, die nächste ermitteln (soweit vorhanden), darüber das entsprechende Dokument holen und in einer neuen Dialogbox öffnen.

Funktioniert natürlich nicht. Das fliegt mir mit der Meldung "NotesUIDocument object is no longer valid." um die Ohren. Ich vermute, es passiert an dieser Stelle :

Set doc = Source.Document
docindex = doc.GetItemValue("CL_E_SortOrder")(0)

Ansonsten wird das UIDocument im QueryClose gar nicht angefaßt.

Zwei Fragen :

1) Hat jemand eine Idee, warum die Werte nicht ins Backend zurückgeschrieben werden ? Wenn ich die Designer-Hilfe richtig verstehe, ist RefreshParentNote ja genau dafür gedacht.

2) Ist das mit der Verkettung der Dialogboxen so überhaupt möglich ? Oder bin ich mit der Idee völlig auf dem Holzweg ?

[Tode]

Prinzipiell ist das alles möglich, aber trotzdem kommt mir das alles sehr "wirr" vor... also erstmal:

Refreshparentnote ist nur dann notwendig, wenn du das aktuell geöffnete Dokument als Dialogbox öffnest (also den Document- Parameter leer lässt).

Ich verstehe nicht, weshalb Du den Stunt brauchst, aus dem Dokument auszulesen, welche Indexnummer es hat...
Im prinzip durchläufst Du im aufrufenden Script die einzelnen Dokumente und zeigst die einzeln nacheinander im Dialog an... dazu brauchst Du kein Queryclose etc.... Du musst halt nur prüfen, ob die Dialogbox gecancelt wurde, und wenn nicht -> firstdoc speichern...
Dann nächstes Dok aus Deiner collection holen und als DIalog anzeigen...

[Fineas]

Hallo,

2.) ja, zumindest grundsätzlich. Ich habe verkettete Dialogboxen alsWizzard im Einsatz und abgesehen von dem nervigen öffnen/schließen klappt das super. Vor, zurück, fertig. Eine andere Lösung als ein reOpen der Dialogbox habe ich aber auch nicht.

1.) keine Idee, aber einen Gegenvorschlag: wenn Du für alle Dialogboxen immer das gleiche NotesDocument benutzt und lediglich die Form wechselst, kannst Du nach Abschluß der Dialogfolge das Ganze korrekte und sauber auswerten und im normalen Programmablauf die Werte übernehmen, die Du benötigst. Auf RefreshParentNote würde ich in dieser Konstellation einfach verzichten.

Gruß, Heiko

[Driri]

Vielen Dank für die Rückmeldungen.

Vielleicht habe ich es schlecht erklärt, ich versuche es mal so.

Struktur :
- 1 Hauptdokument zur Verwaltung einer Checkliste
- n Antwortdokumente mit den einzelnen Fragen der Checkliste

Aufruf :
- Auswahl der Checkliste
- Erstellen von Kopien der Antwortdokumente als neue Hauptdokumente
- Kopieren der Dokumente in einern SPOFU-Ordner (wird vorher ggf. noch geleert)
- Ermittlung des ersten Dokumentes (also der ersten Frage der Checkliste)
- Öffnen des Dokumentes in einer Dialogbox

Ich öffne also nicht das aktuell geöffnete Dokument in einer Dialogbox, sondern ziehe mir ein Backend-Dokument und bringe das via Dialogbox zur Bearbeitung.

Die Struktur mit den Dokumenten und dem Ordner hatte ich mir überlegt, weil ich dann nicht im Speicher mit einer DocumentCollection arbeiten muß. Daher auch die Indexnummer, um das jeweils vorherige oder nächste Dokumente identifizieren zu können.

Ich bin da aber auch für Alternativen offen. Manchmal sieht man ja auch den Wald vor lauter Bäumen nicht mehr 

Ziel ist es jetzt, die Eingaben in der Dialogbox in dem Dokument im Backend zu speichern und dann das nächste Dokument aus der Kette via Dialogbox zu öffnen.

Wenn ich das richtig verstanden habe, komme ich also mit RefreshParentNote nicht weiter. Dann müßte ich also stattdessen die Werte aus dem Frontend auslesen und in das Backend-Dokument schreiben. Anschließend schließe ich die Dialogbox und öffne das nächste Dokument der Kette. Korrekt ?


@Heiko :

Deinen Gegenvorschlag habe ich nicht verstanden. Wie meinst Du das mit "Form wechseln" ?

[Mitch]

Der Code aus deinem Anfangsposting ist eigentlich korrekt, die Items sollten gemäß der Dialogmaske gefüllt oder geändert werden. Das Ergebnis müsstest du aber natürlich noch abspeichern, hast du das vielleicht vergessen?

Und/Aber: Das "RefreshParentNote" vor Schließen der Dialogbox (über eigene Buttons) ist meiner Erinnerung nach sehr wohl erforderlich, da damit ein "OK-Button" simuliert wird. Lässt man das weg gilt die Dialogbox als "Abgebrochen", liefert False zurück und ändert entsprechend auch keine Items.

Ich würde also einfach in deinen Schließen-Button ein "RefreshParentNote" vor die Zeile mit dem "Close" setzen. Aus dem QC kann das dann verschwinden.

Gruß,

Mitch

Edit: Ggf. reicht es ja auch, deinen Schließen-Button als OK-Button zu definieren. Das geht über dessen Eigenschaften.

[Driri]

Hi Mitch,

danke für die Info. Das werde ich mal ausprobieren.


Ansonsten habe ich mir gerade einen alternativen Ablauf ausgedacht, bei dem ich auf eigene Buttons verzichte und die OK/Cancel-Buttons der Dialogbox nutze. Den Status kann ich ja abfragen und entsprechend darauf reagieren. Dann müßte ich die ganze Verarbeitung aus der aufrufenden Funktion heraus steuern.

Ich vermute auch, daß genau das das Problem bei dem von mir gebastelten Konstrukt ist. Im QueryClose der Maske der Dialogbox habe ich offensichtlich keinen Zugriff mehr auf das Dokument und kann somit auch nicht das nächste in der Reihe ermitteln und via Dialogbox öffnen.

[Peter Klett]

Ich habe sowas mal so gebaut, dass ich schon die Fragen in der Dialogbox frei definieren kann, das Ganze Datenkonstrukt wird dann in einer xml-Datei gespeichert und vom Befragten wieder rückwärts interpretiert. Dabei ist alles Mögliche drin, mit Bedingung, ob eine Frage übersprungen wird, die Antwort korrekt ist, die Antworten auswählbar oder frei zu tippen sind usw... Falls Dich da ein paar Ansätze interessieren, melde Dich gerne per PM, ich möchte solche Internas nicht zu öffentlich ausstellen. Vielleicht am Ende der Diskussion ein paar Knackpunkte.

Nachtrag: Das Ganze funktioniert, ohne dass die Dialogboxen jeweils geschlossen und wieder geöffnet werden, bei Betätigen der entsprechenden "Weiter"- und "Zurück"-Schaltflächen werden im Hintergrund nur die Informationen in den Feldern ausgetauscht.

[Peter Klett]

Um auf Deine konkrete Frage zu dem Index und zum Öffnen der nächsten Dokumente einzugehen, würde ich die Steuerung nicht innerhalb, sondern außerhalb der Dialogbox machen. Etwa so:

Suche erstesDokument
Set aktuellesDokument = erstesDokument
Do While not aktuellesDokument Is Nothing
   If Not workspace.Dialogbox (.... aktuellesDokument ....) Then
      Exit Do
   End If
   Set aktuellesDokument = nächstes Dokument (wie immer Du das ermittelst)
Loop

Ich würde es dann auch wieder über ein temporäres Dokument machen, aber das habe ich schon ein paarmal beschrieben. Eventuell auch über einen ganzen Satz davon (List As NotesDocument), das hängt aber davon ab, was bei Abbruch passieren soll. Sollen dann die bis dahin beantworteten Fragen beantwortet bleiben oder nicht?

(Nachtrag: Hattest Du unter #5 schon selbst so beschrieben, hatte ich überlesen)

[Driri]

Danke, so wie in deiner zweiten Antwort skizziert, hatte ich mir das jetzt überlegt aufzubauen.

Ich finde das Arbeiten mit den Dokumenten ganz nett, weil dann beim Abbruch trotzdem die bisherigen Antworten erhalten bleiben würden, ohne daß ich da noch eingreifen muß.

[Fineas]

Hallo,

Das korrekte Stichwort hast Du selbst schon gegeben: Steuerung durch die aufrufende Funktion. Ob dann auf neu angelegte Unterdokumente zugegriffen werden muss ist wesentlich davon abhängig, wozu die Daten hinterher benötigt werden. Grundsätzlich würde ich auf unnötig viele Dokumente verzichten und die Informationen einmal auslesen und in einem zentralen Dokument sammeln. Aber wie gesagt: das hängt stark davon ab, was hinterher damit passieren soll. "Form" wechseln war unglücklich formuliert. Ich hatte dabei meine Lösung vor Augen und da geht es im wesentlichen darum, in mehreren aufeinanderfolgenden Dialogboxen mit unterschiedlichem Maskenaufbau Informationen abzufragen. Dabei kommt ein Dokument als Container zum Einsatz, das lediglich die Darstellung ändert, die Daten aber weiter trägt. Vorteil: der Dialog kümmert sich maximal um die Validierung, alles andere wird außerhalb erledigt. Jeder Schritt läßt sich gut isolieren und sichern. Die dynamische Variante mit dem Feldertausch hat aus meiner Sicht den Nachteil, dass die Logik im Dialog drin sein muss und erst wenn alles verarbeitet ist die Daten geliefert werden. Da kann man zwar auch zaubern, aber für meine Zwecke unnötig kompliziert.

Gruß, Heiko

[Peter Klett]

... Die dynamische Variante mit dem Feldertausch hat aus meiner Sicht den Nachteil, dass die Logik im Dialog drin sein muss und erst wenn alles verarbeitet ist die Daten geliefert werden. Da kann man zwar auch zaubern, aber für meine Zwecke unnötig kompliziert...

Das ist sicher vom Zweck abhängig, wie Du auch selber schreibst. Vorteil dabei aber ist, dass die Logik EINMAL im Dialog gebaut werden muss, und dann beliebig oft immer wieder verwendet werden kann. Bei uns steht im Hintergrund eine allgemeingültige Datenbank, die an die Kunden verteilt wird. Der Austausch der Fragebögen und deren Antworten erfolgt per Mail, zwischen uns und den Kunden gibt es ansonsten keine Replikation. Gestaltungsänderungen bedeuten daher immer ein Versenden von Schablonen mit dezentraler Aktualisierung. Das vermeiden wir, wo es nur geht. Mit der allgemeingültigen Lösung können wir alle möglichen Fragebögen erstellen und beantworten lassen, bis wir vielleicht auf eine Anforderung eines Fragebogens stoßen, an deren Umsetzung wir im allgemeingültigen Teil nicht gedacht haben. Nur dann brauchen wir ein Update (wenn es denn wirklich notwendig ist).

Änderungen und Erstellungen von Fragebögen erfolgen jetzt durch die Anwender und sind kein Eingriff in die Gestaltung. Ob das besser ist, ist eine philosophische Frage. Wäre es mein einziger Job, Fragebögen zu bauen, hätte ich das so natürlich nicht umgesetzt ...

Übrigens gehen bei uns die Antworten auch bei Abbruch nicht verloren, da bei Wechsel von einer Frage zur nächsten die Antworten in die xml-Struktur geschrieben werden. Hätte das gerne in einem Feld im Dokument getan, habe aber berechtigte Sorge wegen der 32k-Problematik. Deshalb liegt die Info in einer Textdatei, die schließlich wieder verborgen ans Dokument angehängt wird.

[Driri]

Kurze Rückmeldung :

Ich habe das jetzt so wie von mir in Antwort #5 skizziert und von Peter in Antwort #7 mit etwas Code versehen umgesetzt. Funktioniert auch problemlos.

Für die Weiterverarbeitung der Antworten greife ich nach Abschluß der Checkliste die Inhalte der Dokumente in einer Schleife ab, bastele sie mir als Tabelle in einem temporären Dokument übersichtlich zusammen und zeige das dann im Frontend an.

Da es sich aktuell nur um einen Proof of Concept handelt, habe ich da zunächst keine weitere Energie reingesteckt, um das Konstrukt flexibler zu gestalten.


Vielen Dank noch einmal an alle Teilnehmer der Diskussion