Beiträge von MacMac

Mh, allein für den Ausdruck wäre das eine Option - allerdings:
Wenn ich die Forms für beide Medien (=Screen, Print) im gleichen Dokument habe, dann habe ich auch nur ein postOpen-Event.

Beim Öffnen für den Ausdruck soll das Dokument aber sofort gedruckt und wieder geschlossen werden - was für das Öffnen zur Anzeige/Bearbeitung wohl eher suboptimal ist...

Edit:
Eine Variante (die ich aber eher für unschön halte) wäre folgende:
Im Action-Button für den Ausdruck setzt man eine Umgebungsvariable (oder ein Feld in einem Profildokument - wobei es dort Caching-Probleme geben kann), öffnet das Dokument und setzt im Anschluss die Umgebungsvariable wieder zurück.
In der Masken-Formel prüft man auf den Wert der Umgebungsvariable und öffnet abhängig davon Form1 oder Form2.

Ich bin mir allerdings nicht sicher in welchem Geltungsbereich Umgebungsvariablen wirken (Notes-Session? Windows-Sitzung? Workstation? Global?) - und wie verläßlich die serielle Ausführung von setzen, drucken, rücksetzen ist.

Hallo Experten,

ich stehe gerade ein wenig auf dem Schlauch:
Wie kann ich denn ein vorhandenes Dokument mit einer beliebigen Maske (!= Wert des FORM-Feldes, != Wert der Maskenformel) öffen?

Ich suche soetwas wie bei der FilePrint-Methode - dort kann die zu verwendende Maske mit angegeben werden.

Hintergrund des ganzen:
Druckt man mit Notes 7 ein Dokument aus einer View heraus, ergibt sich ein Delay von einigen Sekunden, bis gedruckt wird. Öffnet man das zuerst das Dokument im UI und druckt es dann, existiert dieser Delay nicht. Ansatz: Bei klick auf "Drucken"-Action wird das Dokument in der Druck-Form geöffnet, per PostOpen gedruckt und sofort wieder geschlossen.
Druck-Form und normale Anzeige/Bearbeitungs-Form sind unterschiedlich.

Das ist es!!
Und nochmal Danke!

Das heißt, die Weiterleiten-Funktion sucht gar nicht nach einem Formular mit dem Namen "Memo", sondern nimmt immer die Vorgabemaske der MailDB die im aktuellen Arbeitsumgebungsdokument eingetragen ist !?!

Nein, der lautet auch "Memo_backup"...

Mh - ok, hab das 'Problem' erkannt...
In meinem Fall wird offenbar nicht das Memo-Formular in der MailDB gezogen, sondern ein Formular Memo_Backup. Ist im Script-Debugger erkennbar.

Warum er allerdings dieses "Memo_Backup" zieht, was sicher nichts standardmäßiges ist, muss ich noch klären.

Dank Dir.

Ich vermisse Anpassungen (z.B. zur Angabe eines FAX-Empfängers) im Weiterleitungs-Memo. Compose ich eine normale Mail in der Mail-DB (die im Umgebungsdokument eingetragen ist), sehe ich diese Felder - beim Weiterleiten nicht.

Testweise habe ich am Ende des Memo-Formulars (Mail-DB) einfach mal ein wenig Text ("...") ergänzt und sichergestellt, dass dieser nicht versteckt wird. Der Effekt ist der gleiche - beim composen sehe ich den Text im UI-Dokument - in der Weiterleitungsmail sehe ich's nicht.

Speichere ich dann allerdings ein Weiterleitungs-Dokument (ohne zu senden) und öffne dieses dann erneut, sehe ich auch die erwarteten Änderungen.

Hallo Experten,

meines Wissens wird beim Verwenden der Systemaktion "Weiterleiten" das aktuelle Dokument in ein neues Memo-Dokument eingebettet. Dieses neue Memo wird in der Mail-Datenbank des aktuellen Users erstellt.

Nehme ich jetzt allerdings Änderungen an der Maske "Memo" in der Anwender-Mail-Datenbank vor, so werden diese bei der Weiterleitung einer Mail nicht sichtbar (in neuen Mails die ich direkt in der Mail-Datenbank erzeuge, sind die Änderungen sichtbar).

Daher die Frage: Wird dafür überhaupt das (eventuell angepasste) Memo-Formular aus der Mail-DB verwendet? Oder wird dabei immer ein 'Standard'-Memo-Form benutzt. Wenn letzteres: Kann man dieses 'Standard'-Memo-Form auch noch verändern?

Gruß,
Mac

*auf Erledigt gesetzt*

Mh, nun gut - bzw. schade...

Zitat

und verbietest die manuelle Löschung komplett ?

Indem ich es im QueryDocumentDelete-Event abwürde?!
Oder gibt es da auch noch eine weitere Methode die ich noch nicht kenne?

Zitat

Und wieso schaltest du dann die SoftDeletions nicht einfach aus und verbietest die manuelle Löschung komplett ?

Weil die Anwender weiterhin die Möglichkeit haben sollen, gelöschte Dokumente wiederherstellen zu können?!

Ziel ist es ja nur in dem Moment wo ein Dokument wirklich gelöscht wurde (also auch aus dem Papierkorb) die externe Referenz zu bereinigen.

Die Referenz beim 'löschen in den Papierkorb' zu bereinigen und beim eventuellen Wiederherstellen wieder zu regernieren ist leider im vorliegenden Fall nicht möglich.

Alternativ müsste ich halt andersherum vorgehen und von der externen Datenbank aus prüfen ob die referenzierten Dokumente noch existieren. Da ich dafür aber alle Mail-DBs der User durchlaufen müsste, würde ich das gern vermeiden.

Zitat

Auf das manuelle Löschen reagiert er auch aus dem Trash nicht anders wie auf das aus anderen Ansichten.

Mh, ich hab im QueryDocumentDelete + PostDocumentDelete ein einfaches "MsgBox" drin stehen - nur um mitzubekommen, wann der Code ausgeführt wird.

Lösche ich nun ein Dokument in einer "normalen" (shared) View
werden beide MsgBox-Ausgaben ausgeführt.

Lösche ich nun ein Dokument aus einer "nur gelöschte Dokumente"-View, oder aus einer Kopie der SoftDeletion-View aus dem Mail-Template, kommt noch die Sicherheitsabfrage - der MsgBox-Code wird aber offenbar nicht mehr ausgeführt.

Hab ich dich noch irgendwo missverstanden?

Zitat

Nur die automatische Löschung musst du eben abschalten

Mit der "automatischen Löschung" meinst du die UndeleteExpireTime? Die läßt sich (zumindest über die Database-Properties) scheinbar nicht auf 0 setzen. Oder gibt es noch einen anderen Weg sie wirklich zu deaktivieren?
Es ging dir dabei nur darum, dass die Dokumente nicht per Backend gelöscht werden, oder?

Hallo Taurec,

"Database Scripts" war schonmal ein sehr gutes Stichwort.
Leider bringt es mich trotzdem noch nicht wirklich zum Ziel.

Das Event PostDocumentDelete wird offenbar in dem Moment ausgelöst, in dem der Anwender das Document löscht und in ein SoftDeleted-Document überführt.

Der Code muss aber an die Stelle, an der nun das SoftDeleted-Document seinerseits gelöscht wird. (Aus dem "Optimalfall" im ersten Post ist inzwischen der "Einzig mögliche Fall" geworden).

Alternativ: Läßt sich das Löschen aus der (SoftDeletion)-View unterbinden? So, dass entgültiges Löschen nurnoch über einen Agenten möglich ist?

Außerdem: Mir ist der Zusammenhang zwischen der SoftDeletion-View und dem Trash-Folder noch nicht ganz klar. Wie ist der realisiert?

Hallo,

ich suche nach einer Möglichkeit um ein Stückchen Code (LS?!) immer dann auszuführen, wenn ein Dokument aus einer Datenbank gelöscht wird - unabhängig davon ob die Löschung per Action-Button (das wäre ja noch problemlos), per Löschen in einer View oder per Löschen aus dem Papierkorb (manuell oder durch Ablauf der SoftDeletionTime) gelöscht wurde.

Optimal wäre es also, Code genau dann ausführen zu können, wenn ein Dokument in die "hard-deletion" übergeht.

Hintergrund:
Es gibt eine zweite DB, die auf die Dokumente in der Mail-DB referenziert. Beim Löschen sollen diese Referenzen ebenfalls bereinigt werden.

Edit: Präfix auf "offen" gesetzt.

taurec:
Ja, das war das Szenario aus diesem Posting

hurtz:
Ich hab das ganze jetzt an verschiedenen Arbeitsplätzen - u.A. mit lokalen Admin-Rechten ausprobiert. Seitenformat-Einstellungen bleiben leider unberührt.

Der Drucker auf den ich Drucke ist als Standarddrucker gesetzt.

Aber:

Zitat

Seitenformat Einstellungen, diese gelten nur für den definierten Standarddrucker

Wenn dem so wäre, dann wäre ja alles gut!
Dann könnte ich den 2. Drucker (=nicht Standard-Drucker) ja andersweitig einstellen und wäre dort unabhängig von den Seitenformat-Einstellungen.

Genau dies stelle ich aber in der Praxis nicht fest. Egal auf welchen Drucker ich drucke, es wird immer die Ausrichtung aus den Seitenformat-Einstellungen gezogen.

Wenn ich die Seitenformat-Einstellungen öffne steht in der Titelleiste des Dialogfensters übrigens auch nicht der Standard-Drucker, sondern der Drucker den ich in Datei-->Drucken zuletzt ausgewählt hatte - selbst dann, wenn ich diesen Dialog mit Abbrechen verlassen habe!

Hallo Diali,

das 2. Skript zeigt das gleiche Ergebnis wie wenn ich es in einem einzelnen Skript ausführe.
--> Der Setter-Script setzt die Eigenschaft offensichtlich erfolgreich.
--> Das Getter-Script kann den geänderten Wert später wieder auslesen.

Mir ist allerdings nicht klar, wo sich diese Einstellung niederschlägt.
Seitenformat-Einstellung und Durcker-Format-Einstellungen bleiben unverändert. Ein ws.curdoc.print ist davon weiterhin unberührt.

Hi hurtz,

dank dir für die Mühe.
Ich benutze 7.04.

2 ist Landscape - 1 ist Portrait.

Folgende Zeilen

val1 = getPrinterOrientation(printer)
		val2 = setPrinterOrientation(printer, 2) 
		val3 = getPrinterOrientation(printer)

liefern folgende Return-Werte:
val1 = 1
val2 = 1
val3 = 2

Sieht prima aus - genau das was ich will - die Ausrichtung wäre demnach von Hoch- auf Querformat geändert worden.
Schaue ich danach aber in Datei-->Seitenformat, so ist dort weiterhin "Hochformat" eingetragen.

Schicke ich hinter obigen Zeilen einen ws.curDoc.print hinterher, wird Hochformat gedruckt... - unschön.

---> Ich vermute übrigen, dass dieses Verhalten erst auftritt, wenn man Menü-Seitenformat für diese Datenbank mindestens einmal genutzt und mit OK bestätigt hat. <---

Guten Morgen zusammen,
und erstmal danke für die Postings!

@Dali:

Zitat

Aber Du kannst den Drucker 2 Mal im BS hinterlegen

Ich hatte gehofft das ginge aus meiner Problembeschreibung hervor... - ich HABE 2 Drucker eingerichtet - mit unterschiedlichen Ausrichtungen. Die Ausrichtungs-Einstellung der Drucker wird aber von der Einstellung in "Seitenformat" im Client überlagert.
Die 2 Drucker sind also nicht weiterführend.

hurtz:
Vielen Dank für das Script!!
Leider löst es mein Problem (nach erstem schnellen Testen) aber offenbar auch nicht. Ich habe die Zeile

Call setPrinterOrientation(printer, 2)

mit den Parametern 0 - 4 versucht - und immer wird genau so gedruckt, wie es in den Seitenformat-Einstellungen des Clients angegeben ist. - also kurz: :-|

Hallo taurec,

da ich mir nicht sicher war, wie die Drucker damals angelegt wurden, habe ich sie nochmal neu anlegen lassen - ausdrücklich ohne Kopie.

Das Problem bleibt unverändert - die Einstellungen unter "Seitenformat" überschreiben die Druckereinstellungen.
Seitenformat kann nicht pro Drucker gepflegt werden (obwohl die Überschrift des Dialogfensters dies suggeriert).

hurtz:
Das würde aber ja tatsächlich bedeuten, dass man innerhalb einer Datenbank (mindestens) per Script immer nur in der gleichen Ausrichtung drucken kann, bzw. die Ausrichtung gar nicht gezielt kontrollieren kann. Wenn Du die Scripten zum Workaround noch findest, würde ich mir das gern mal anschauen.

Arg,

ich sortier das dann mal wieder in der Kategorie "Frontend-Agenten sind gern mal wunderlich" ein...

Vielen Dank Stefan!
Klappt jetzt wie gewünscht.

Hallo Norbert,

für den Fall, dass Du hier im Forum (wieder Erwarten) nicht fündig werden solltest, schau dir doch mal folgenden IBM-Artikel an:

http://www-01.ibm.com/support/…ss?rs=899&uid=swg21110903