Beiträge von helmie

Dann auch gleich hinterher Lob Nr. 3!

Sieht nicht nur viel schöner aus, auch die neuen Funktionen/ Einstellungen im Profil gefallen mir.

Vielen Dank für die Mühe!!!

Ich bin auch wieder ab Sonntag da.
Freu mich schon auf ein Gläschen "Wasser" :pint: mit euch...

Natürlich hat taurec Recht, als Sicherheitsfeature taugen die Maskenevents nicht. Dazu lassen sie sich zu einfach umgehen. Aber in ausgewählten Fällen können sie durchaus nützlich sein.

Dein Dokument lässt sich zwar "erstmal" nicht mehr in Bearbeitungsmodus nehmen, aber jeder Autor kann sich den Debugger anschalten und das Script abbrechen. Dann geht es halt doch wieder (zum Glück kennen den Debugger nicht viele...). Oder über eine einfache Aktion werden aus der View heraus Daten verändert. Wenn Du sowas echt verhindern willst, dann gehen definitiv nur Autoren-/ Lesefelder

Hi,

ich arbeite auch gern mit den Maskenevents. Um auf den Hinweis von ascabg zu antworten: Um den Fall abzugreifen, das der User STRG + B drückt schreibe ich das praktisch gleiche Script auch in das QueryOpen-Event. Allerdings dann natürlich mit

if source.editmode = true then
.
.

Natürlich wäre es in jedem Fall sicherer mit Autorenfeldern zu arbeiten, aber auf die o.g. Weise geht es auch.

Du benötigst da keine @if-Formel.
Trag Dein Feld "PA_PA_ID" bei "Einzelne Kategorie anzeigen" ein und schon sollte es gehen

dann musst Du die Eingabe (s. Post von taurec) irgendwo zwischenspeichern solange Du in der Formelsprache bleiben willst. Ich würde da aber eher auf Script umsteigen.
Stichworte Prompt und UnprocessedDocuments

Je nchdem was Du vorhast etwas mehr oder weniger aufwendig.
Soll nur ein Dokument geändert werden oder mehrere mit dem gleichen Wert der nur einmal abgefragt werden soll?

Dann hast Du was nicht ganz richtig gemacht. Bei mir funktioniert das in mehreren Anwendungen problemlos.

Du musst zunächst das Feld in eine Variable einlesen, dann das neue Dokument mit @command([Compose]; ...) anlegen, dann den @UpdateFormulaContext und zum Schluß mit FIELD xxx := die Variablen an die Felder wieder übergeben.
So läuft das auch ohne das zuerst gespeichert werden muss.

Meine Anmeldung ist auch schon da...

Wer von euch kommt noch? Und wer kommt schon wie ich am Sonntag?

An alle noch einen guten Rutsch in ein erfolgreiches neues Jahr!

Hast Du beim übertragen Deiner Formel vielleicht einen Fehler gemacht? Wenn nicht fehlt bei Deinem @MalSend ein Parameter.

Auszug aus Designerhilfe:
@MailSend(SendenAn ; KopieAn ; BlindkopieAn ; Thema ; Anmerkung ; Haupttextfelder ; [Flags])


@MailSend ("Name/Organisation"; ""; "";"Neuer Eintrag in Maschinen-DB"; "Link zum neuen Eintrag: "; [IncludeDoclink]);

Wenn ich das richtig sehe hast Du den Parameter "Haupttextfelder" vergessen...

Ist ja kein Problem.

Ich hab es jetzt auch so umgangen wie oben beschrieben. Aus der Quelle hole ich nur noch bestimmte Kopfdaten um das Dokument zu kategorisieren. Außerdem speichere ich die Dok-ID in meinem Anzeigedokument. Wenn dieses dann zum lesen geöffnet werden soll breche ich im Postopen den Vorgang ab und öffne stattdessen das eigentliche Quelldokument. Funktioniert prima.
Schade nur, dass das rendern nicht so ohne Probleme geht...

Trotzdem Dank für die Hilfe

Hallo Dirk,

danke für die Antwort.
Das temporäre Dokument hatte ich auch gespeichert, aber trotzdem wird beim rendern eben nichts "mitgenommen".

Die Maske im Dokument zu speichern halte ich auch für nicht wirklich zielführend. Die Nachteile überwiegen doch zu sehr.

Was ich an Deinem Post aber nicht verstehe ist der Satz

Zitat

Die Maske brauchst Du in der neuen DB, wie soll sonst das Dokument gerendert werden?

Das rendern geschieht in der Ursprungs-DB. Daher benötige ich in der Anzeige-DB die ursprünglichen Masken nicht. Das funktioniert auch bereits mit mehreren Datenbanken problemlos.

Die Fälle bei denen es nicht funktioniert sind, wenn das zu rendernde Dokument Teilmasken oder eben Zugriffsgeschützte Abschnitte enthält. Diese Teile werden leider nicht gerendert.

Bin jetzt aber dabei, eine Umgehung zu basteln, in der ich die ID des zu rendernden Dokuments übernehme sowie ein paar Kopfdaten (um was für die Ansichtenanzeige zu haben), beim öffnen des Dokuments den Workaround abgreife und das eigentliche Originaldokument öffne. Nicht wirklich elegant, scheint aber nach einem ersten Test zu funktionieren.
Wenn ich damit mein Problem gelöst haben sollte werde ich die Lösung noch posten.

Den Fehler mit dem "Eintrag im Index nicht gefunden" konnte ich beheben. Es lag daran, das in der Ursprungsmaske noch ein DBLookup ausgeführt wurde.
Aber das Ursprungsproblem bleibt nach wie vor bestehen.
Auch das RenderToRTItem vom temporären Dokument liefert nur leere Werte zurück...

Hallo,

nach langer Zeit mal wieder eine Frage von mir.

Ich habe eine Notes-DB, die über einen Agenten Daten aus anderen Notes-DB sammelt. Dazu werden die Dokumente aus der Original-DB per RendertoRTItem in die einsammelnde DB kopiert. Das funktioniert auch sehr gut und performant.
Jetzt habe ich eine neue DB zum auslesen dazugenommen. In der Maske der einzusammelnden Dokumente ist ein zugriffsgeschützter Abschnitt. Wenn die Dokumente, die mit dieser Maske erstellt wurden, kopiert werden, ist mein RTItem komplett leer. Da ich mich dunkel dran erinnere, das ein RendertoRTItem diese Abschnitte ignoriert, habe ich versucht erstmal ein temporäres Dokument zu erstellen. Dieses fülle ich per CopyAllItems und will dann das temporäre Dokument per RendertoRTItem in mein eigentliches Dokument kopieren. Hier kommt allerdings der Fehler "Eintrag im Index nicht gefunden" in der Codezeile

temp_doc.RenderToRTItem(rtitem)

Ich habe auch schon versucht, das temporäre Dokument erstmal zu speichern. Erfolglos, der Fehler bleibt der gleiche. Warum verstehe ich schon mal nicht...
Hat einer eine Idee, wie ich Dokumente sonst von einer DB in eine andere DB kopieren und anzeigen lassen kann, ohne die Masken mitzukopieren? Bzw. den Fehler beim RenderToRTItem umgehen kann? Oder wie ich den Fehler mit dem "Eintrag im Index nicht gefunden umgehe? Vielen Dank schon mal!

Welchen Typ hat denn die Zugriffsformel (Berechnet oder Berechnet zur Anzeige)?
Habe schon mehrfach beobachtet, das es vorkommt, das bei einer Änderung das Doc zweimal refresht werden muss damit die Formel zieht, wenn die Zugriffsformel auf "Berechnet" steht. Am zuverlässigsten arbeitet bei mir der Typ "Berechnet zur Anzeige"

PS: Glückwunsch zum 100.sten Posting!

alexhe: Sorry, das Problem ist bei uns bisher noch nie aufgetreten. Was für eine Version habt ihr denn im Einsatz? Bei uns ist es 9.0.6

Hi,

wir haben auch den OnTime im Einsatz. Sind damit überaus zufrieden. Performanceprobleme wie bei anderen Terminkalendern, die Einträge per Agent sammelt, gibt es nicht mehr, Einträge werden nahezu in Echtzeit ind den Gruppenkalender übernommen. Kann ich nur empfehlen.

Kannst Du meines Wissens nach nur per Script machen, beispielsweise im QuerySave. Oder eben in einer Schaltfläche, je nachdem, was Du vorhast.

Hast Du im Design des Feldes auch genau die Werte als Auswahl (Eigenschaften-Box) eingesetzt, die Du auch importierst? Oder wenn nicht, dann die Option "Neue Werte zulassen" gehakt?

Lass Dir doch die Ergebnisse Deiner Prüfung mal in 2 Variablen ausgeben um im Debugger zu prüfen, ob da wirklich exakt das gleiche steht.
Ich glaube wie taurec, das was an der Löschbedingung nicht zutrifft.