FindFirstElement(RTELEM_TYPE_TABLE)

[jBubbleBoy]

Der Link enthält nur ein IBM-Beispiel um eine Tabelle auszulesen. Das habe genutzt um einen einfachen und schnellen Test durchzuführen, dabei konnte ich keine Einschränkungen feststellen - Notes 9.0.1 FP6.


Du hattest doch geschrieben, das die Verwaltung eine Tabelle pflegt, in dieser Vorlage sollte man an die "nicht drucken" Eigenschaft herankommen.

Oder alternativ halt eine eigene, richtige Tabelle nutzen und das mit der Verwaltung abstimmen. Das wäre nach wie vor mein Favorit!

[bredemeier]

Die Funktion geht ja grundsätzlich, aber nur so lange das Dokument nicht im Frontend bearbeitet wurde (auch, wenn das Richtextfeld mit der Tabelle nicht bearbeitbar ist und im Frontend nicht bearbeitet wurde).

Es handelt sich hier um ca. 250 Dokumente die normalerweise mit kpl. Tabelle ausgedruckt werden. Nur für einen zusätzlichen Ausdruck soll die Tabelle gekürzt werden und da kann ich von keinem erwarten, dass jedes Dokument manuell angepasst wird. Zur Zeit läuft es so, dass die Verwaltung die Dokumente öffnet, den Inhalt der letzten zwei Spalten löscht, ausdruckt und ohne zu speichern schließt. Das dauert Stunden.

Gibt es in letzter Zeit wirklich so wenige, die sich für Notes interessieren? Sind die Dinos wirklich ausgestorben?

[jBubbleBoy]

Also die Verwaltung besteht auf eine Zeiterfassung in einem Richtext, um dann viel manuelle Zeit in den Druck zu investieren? Und Du hast den schwarzen Peter, weil keine Lösung in Sicht ist, bzw. wurde dieser Vorgang vorher nie getestet und abgenommen? Nun das hat man davon!

Wenn sonst nichts weiter hilft - über DXL / XML kommt man noch an die Tabellendaten ran.

[Ottmar]

Ich hatte mal in LotusScript ein ähnliches gelagertes Problem. Den RichTextfeldern war einfach nicht beizukommen. Soblad ein Dokument im Front-End bearbeitbar geöffnet ist, ging über Scripten nichts mehr. Ich habe das seinerzeit auf eine nicht sauber funktionierende Synchronisation zwischen Frontend und Backend zurückgeführt. (Das war allerdings noch Release 8.x) Es ging darum, über eine Schaltfläche eine bestimmte (berechnete) Serie von Anhangdokumenten in ein Rich-Text-Feld eiinzufügen.

Wenn man über Agenten im Backend was ändert, gehen die Änderungen beim Speichern aus den Fontend komplett verloren und es ging seinerzeit alles nur kaputt.

Meine Lösung war die strikte getrennte Programmierung von Frontend und Backend.
Das lief seinerzeit so:
-> Auslagerung des Scriptcodes aus der Schaltfläche in einem Agenten (der mit "@command([ToolsRunMacro]; Agent)" aufgerufen wurde)
-> Im Agenten Universal-ID (bzw. View-Key) des aktuellen Dokumentes auslesen und in einer temporären Variable speichern.
-> Dokument bzw. RichText-Feld im Backend wie gewünscht bearbeiten, speichern und schließen.
-> Danach Im UIDoc (Frontend) das Feld "SaveOptions" hinzufügen und mit "0" belegen.
-> UIDoc im Frontend schließen.
-> ggf. Refresh auf die Ansicht
-> Mit Hilfe der gemerketen Universal-ID das Dokument neu aus dem Backend holen und in das Frontend überführen.

So wurde dann verhindert, dass sich Frontend und Backend in die Quere kommen. Der Bildschirm hat nur einmal kurz geflackert und der Anwender hat nach Click auf der Schaltfläche seine "Änderungen" sofort gesehen. Das mag zwar etwas hemdsärmlich wirken, aber nur so habe ich das Ganze seinerzeit in den Griff gekriegt.

Möglicherweise ist diese Vorgehensweise ja auf dieses aktuelle Beispiel anwendbar.

 

[bredemeier]

Die Zeiterfassung läuft über einzelne Dokumente, dass habe ich doch schon geschrieben. Es wird dann aus den Dokumenten ein Stundennachweis erzeugt. Natürlich kann ich den Nachweis aus den einzelnen Dokumenten noch einmal erzeugen und die entsprechenden Felder in den Tabellen nicht füllen, aber dann habe ich die in anderen Feldern erstellten Änderungen nicht mit drin. Natürlich könnte ich die Kopie des Nachweises erstellen und nur die Tabelle im Richtextfeld aus den Stundendokumenten holen.

Es ist doch auch eigentlich egal. Die Frage ist ja immer noch die Gleiche:

Warum kann ich nach dem automatischen Erstellen der Nachweise mit FindFirstElement(RTELEM_TYPE_TABLE) auf die Tabellen zugreifen und die Zellen auslesen, aber nachdem man das Dokument in einem anderen Feld bearbeitet und dann gespeichert hat nicht mehr???

[jBubbleBoy]

Wenn Du nicht das Druck-Problem lösen möchtest, sondern die LS Funktion, dann mach doch ein Ticket bei IBM auf.

[Christian Kröll]

ein Dino hat dieses Thema auch verfolgt und es ist so, wie Peter sagte. Woher kommt das SIGN SEAL?

Ich habe in einer unserer Anwendungen nach SIGN SEAL gesucht und gefunden. Die Dokumente werden wie bei Euch im Backend erzeugt, mit Tabellen und Daten befüllt etc. Die Richtextfelder in den beteiligten Masken sind eindeutig nicht SIGN SEAL. Das Zieldokument dann aber schon und die erste von mehreren Tabellen kann man nicht per Script anfassen. Speichere ich dieses Dokument einmal ab, verschwindet das Flag und die erste Tabelle kann gelesen und manipuliert werden.

Setz doch mal das Flag für Signed und Encypted für das RTF auf False:
   Dim item As NotesItem
   Set item = doc.GetFirstItem("Body")
   If Item.IsEncrypted Then
      item.IsEncrypted = False   
   End If
(kannst das IF auch weglassen, war bei nur für den Test drin)
So kann ich bei unserem Dokument dann auch auf die erste Tabelle im RTF wieder zugreifen. Vielleicht hilft's

[Ottmar]

Also nochmal etwas genauer:

Wird ein Dokment mit einen Richtext-Feld über das Backend erstellt und in das Front-End überführt, so ist alles gut, solange das Dokument im Frontend nicht bearbeitet wird. Wechselt man das Dokument in den Bearbeiten Modus, so ist (nur im Frontend) das Richtext-Feld leer. Der Anwender sieht am Bildschirm zwar ein "richtiges" Dokument mit entsprechenden Inhalten im Richtext-Feld, da es ja aus dem Backend kommt, im Frontend ist das Richtext-Feld aber trotzdem immer noch leer. Das ist zumindest meine Beobachtung, die ich gemacht habe.

Ändert der Anwender jetzt ein Feld und speichert das Dokument, so überschreibt das "unvollständnige Forntend" das Dokument im Backend, d.h. die Änderungen im RichTextfeld "verschwinden", man kann nicht mehr mit Script drauf zugreifen und wenn man das Dokument neu öffnet, sind die Tabellen / Anhänge kaputt oder ganz weg. Mit der Synchronisation von Rich-Text-Feldern haben alle Systeme (nicht nur Notes) ihre Schwierigkeiten.

Es muss beim Spechern klar sein, wer der "Master" ist, damit es zu keinen Kollisionen kommt. Werden Änderungen (über Programmierung) im Backend gemacht, muss im Backend gespeichert werden; geschieht das Ganze im Frontend über Anwendereingaben, muss aus dem Frontend heraus gespeichert werden.

Bei "normalen Feldern" sind Mischformen gar kein Problem, bei RichText-Feldern aber schon. Deshalb nochmal: programmierter Änderungen im Backend speichern, Im Forntend über "SaveOptions" das Speichern unmöglich machen. Insbesondere wird das Feld "SaveOptions", wenn man es per LotusScript im Frontend einfügt, ja nicht mitgespeichert.

Nach dem Schließen im Front-End und dem Wiederholen aus dem Back-End kann man dann die "normalen Felder" editieren.
Ich habe zwar nie die Foren bemüht und versucht herauszufinden, warum die Front-End /Back-End Synchronisation zickt, insofern mag es sein, dass ich mich - was den technischen Hintergrund angeht - irre, aber ich hatte mit meineer Vorgehensweise seinerzeit entsprechenden Erfolg.

[Ralf_B]

Das kann ich auch bestätigen:
Wenn ein uidoc offen ist und im Backend Änderungen gemacht werden , ist es am besten das uidoc zu schliessen und neu zu öffnen.
Ein Refresh / Reload bei RTFeldern funktioniert nicht wirklich.
Wenn dass Backdok geändert wurde und das ((immernoch offene) Uidoc gespeichert wird sind die Änderungen im Backend weg, das UiDok hat Vorrang.
Hier mit saveoptions zu arbeiten ist ein Weg den ich auch gehe.
Die Erfahrung habe ich ebenfalls mit einer Tabelle im RTFeld  gemacht bei der im UI eine Aktion im Backend Zeilen einer Tabelle gelöscht / hinzugefügt hat und diese Änderung war dann plötzlich weg. Mit Saveoptions ging das dann.

[bredemeier]

@Christian: die Änderung der Flags hat keinen Einfluss auf das Verhalten

@Ottmar und Ralf_B: ich bin da immer mehr eurer Meinung, denn egal, wie ich es treibe, sobald das Dokument einmal im Frontend bearbeitet wurde, ist ein Zugriff auf die Tabelle im Richtext nicht mehr möglich