Backend - Frontend: Dialogbox

[TMC]

Hi,

ich habe einen kleinen Stunt vor - schöne Aufgabe für den Freitag Abend :-)

User befindet sich in einem Dokument. Nun klickt der User auf einen Button.

Der Button öffnet eine temporäre Dialogbox:

Code

Dim docTemp As NotesDocument
   Set docTemp = db.CreateDocument
   Call workspace.DialogBox( "box_CreateHotspot", True, True, False, False, False, False, db.title, docTemp, True, False)

Die Dialogbox hat im Postopen einen Code:

Und jetzt geht das Problem an:

Jetzt würde ich gerne im Postopen die gerade geöffneten Dialogbox als UIdoc definieren, damit ich dort Frontend-Zugriffe habe (z.B. Richtextfeld füllen etc.).

Eigentlich müsste ich ja wohl die Dialogbox vorher speichern, um als UI verfügbar zu sein, oder?
Konflikt: Das temporäre Dialogbox-Dokument soll danach wieder gelöscht werden - was aber wenn User gar keine Löschrechte hat?

Jetzt meine Frage:

Hat man eine Möglichkeit, ein Backend-Dokument (hier: docTemp) in ein Frontend-Doc umzuwandeln, um darauf zugreifen zu können, OHNE dass man das Backend speichert?

Ich hoffe meie Ausführung hier ist einigermaßen verständlich.......

Matthias

[TMC]

Sorry, man vergesse meine Frage.

Ich habe natürlich Zugriff.

Schließlich steht da
Sub Postopen(Source As Notesuidocument)

Und Source ist nunmal das UIDoc, also Frontend  

Matthias

[koehlerbv]

Wenn Du gerne schreibst und Dir "Source" nicht gefällt, hättest Du natürlich auch

Dim ws As New NotesUIWorkspace
Dim uidoc as NotesUIDocument
Set uidoc = ws.CurrentDocument
coden können (ab PostOpen)

Bernhard  

[TMC]

Danke Bernhard, aber in dem Kontext war UI leider das eigentliche Dokument.

User befindet sich in einem Dokument. Nun klickt der User auf einen Button

Eben dieses Dok war im Frontend für Notes, obwohl ich eine Dialogbox öffne.
Daher die Frage.......

Ciao,
Matthias

[Semeaphoros]

Das ist natürlich Definitionsfrage. Es gibt immer nur ein UI-Doc und das ist dasjenige, welches innerhalb des Client den Focus hat. Das Userdoc. an dem der User arbeitet, ist solange UIDoc, bis die Diabox aufgeht, dann wechselt das UIDoc auf die Diabox. Im Postopen ist das ja bereits der Fall, und der Code von Bernhard, wenn auch völlig korrekt, ist schliesslich nur Fahren mit angezogener Handbremse: Man verbrennt CPU-Zyklen mit Zuweisen von etwas, was man schon über Source im Zugriff hat. Schlimm ist es nicht, da die erstellten Referenzen nicht wirklich neue Instanzen bilden, sondern auf das bereits instantiierte UIDoc verweisen.

Ein Hinweis sei noch erlaubt: Wenn man sowas geschachtelt macht, sprich aus der Diabox eine weitere Diabox öffnet, dann zünden beim zweiten Durchlauf leider nicht alle Events, ein ärgerlicher Bug, den man nur indirekt feststellen kann, da ja der Debugger nicht dialogfähig .... eh .. Diaboxfähig ist.

[TMC]

Danke, aber back to the question:

Ein UIDoc NEU zu definieren geht wohl nicht ohne das Backend doc zu speichern, oder?

Mir ist dabei klar, dass es immer nur ein UI geben kann (wie Jens schon angemerkt hat).

Danke für Eure Unterstützung,

Matthias

[Semeaphoros]

In Deinem Beispiel hast Du es ja auch nicht gespeichert. Das geht sehr wohl ohne Speichern. Probleme gibt es höchstens mit RT-Feldern, wenn man die vorher im Backend befüllt. Aber RT-Felder verhalten sich ja sowieso immer etwas speziell, auch in Diaboxen, so werden sie ja nicht im Doc abgespeichert, wenn man eine Diabox über dem aktuellen Doc öffnet, alle anderen hingegen werden übertragen (sofern man es nicht abgewählt hat)

[TMC]

OK, danke, mal kurz zusammenfassend:

Um ein doc (also Backend) einem UI (Frontend) zuzuweisen, muss das Backend NICHT gespeichert werden (außer man behandelt Richtextfelder) ?

Matthias

[koehlerbv]

Matthias, sorry, ich wollte eigentlich nur einen Scherz machen ...

Natürlich kannst Du ein FrontEnd-Doc auf ein Backend-Doc instantiieren, ohne dass dieses vorher gespeichert wurde. Wie Jens schon sagte - es dürfen nur keine RT-Inhalte enthalten sein, diese werden wirklich erst nach dem Speichern greifbar.

Den Code, den ich geschrieben habe, war absolut "doppelt gemoppelt", daher auch der Spruch "wenn Du gerne schreibst und Dir 'Source' nicht gefällt ..."

Temporäre (nicht zu speichernde) Backend-Docs für FrontEnd-Operationen sind übrigens ein völlig übliches Verfahren.

Bernhard

[Semeaphoros]

Genau, Matthias, und was Bernhard schreibt ist völlig zutreffend.

[animate]

also ich habe die Woche folgende (überraschende) Erfahrung gemacht:

ich erstelle ein NotesDocument-Objekt und befülle einige Textfelder mit Werten. Und ich kopiere ein RTItem von einem existierenden NotesDocument in mein neues.
Dann öffne ich es im Frontend mit der EditDocument-Methode der NotesUIWorkspace-Klasse (ohne speichern des NotesDocument-Objekts).
Ich habe das gemacht, ohne mir ein Handle auf das UIDoc zu holen, also

Call ws.EditDocument(...)

anstelle von

set uidoc = ws.editDocument(...)


Alles bestens, sogar das RTFeld wird optimal angezeigt.

[Semeaphoros]

Und Ghandi hat heute das Gegenbleistift geliefert:

Quantentheorie

[TMC]

Na ja, hatte ich deswegen nicht als Scherz aufgefasst, weil ich mit Richtext arbeitete   (dies aber zuvor wohl leider nicht erwähnt habe).

Danke Euch beiden.

Eigentlich hatte ich das selbst schon öfter so umgesetzt, aber die Kombination Dialogbox & RTF hat nicht geklappt, daher habe ich gleich mal alles in Frage gestellt  

Wie auch immer, meine Lösung mit RTF habe ich über "Source" im Postopen gefunden, und Ihr habt mir nun bestätigt, dass ein Speichern nicht sein muss solange es sich nicht um RTF handelt (wie eigentlich schon oft hier im Forum gelesen).

Danke.
Matthias

[animate]

Und Ghandi hat heute das Gegenbleistift geliefert:

Quantentheorie

kann ich absolut nicht bestätigen. läuft alles völlig problemlos.
6er Client/Designer

[animate]

aber wie gesagt, ich kopiere ein existierendes RTItem und erstelle kein neues

[TMC]

Mir fehlt da immer noch - zusätzlich zur "Option Declare" - die "Option R5"  

Ist mein persönlicher Wunsch für Rnext.

Wenn ich "Option R5" eintrage, dann verhält sich Client wie in R5  

Nur dann kann man mit R6/R7/RwasWeissIch  vernünftig testen :-)

Matthias

[Semeaphoros]

Option R5 vor allem im Designer, dass er einem warnt, wenn man was nicht unterstütztes verwendet.

Thomas: das mit dem Kopieren kann der springende Punkt in der Geschichte sein. Darüber hinaus hat Ghandi ja auch noch nen Doklink im Spiel, noch so ein "heisses Eisen".

[animate]

Doclinks, Attachments, Bilder, ...
Alles kein Problem.


Wenn ich wieder nen Notes Designer habe, dann probier ichs auch mal mit nem neuen RTItem

[koehlerbv]

Bei einem existierenden (gespeicherten) RTitem kennt ja Notes bereits die on-disc-Daten, also genau das, was bei einem nicht gespeicherten Doc das Problem darstellt.
Aber aus Thomas' Entdeckung kann man was machen ...

Bernhard

[animate]

das scheint eine plausible Erklärung zu sein.

und mit einem neuen RTItem hauts echt nicht hin. ich habe gerade genau das gleiche erlebt, wie Ghandi.

Mit Debugger an klappts, ohne nicht. Seltsam.