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:

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

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  

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.

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)

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

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.

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

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

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".

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