Größe eines Richtextfeldes (in Bearbeitung) prüfen

[ghostmw]

Moin zusammen,

ich bin wieder auf eine spannende Frage gestossen, nämlich folgende:

Kann man ein Richtextfeld, dass in Bearbeitung ist auf Größe validieren?

Voraussetzungen:

Notesclient 8.x oder höher, ein normales Richtextfeld (kein RT-Lite), validiert werden soll die Gesamtgröße, d.h. Attachments, Text und eingefügte Screenshots

Was ich schon probiert habe:

...
dim ws as new NotesUIWorkSpace
dim uiDoc as NotesUIDocument
dim doc as NotesDocument
dim rtItem as NotesRichTextItem
dim lngRichTextSize as Long
dim lngRichTextAttachmentSize as Long

set uiDoc = ws.CurrentDocument
set doc = uiDoc.Document

call uiDoc.Refresh ( true, true, true )
call uiDoc.Reload

set rtItem = doc.getFirstItem ( "body" )
if rtItem is nothing then exit function

lngRichTextSize = rtItem.ValueLength ' ==> liefert aber nur die Größe des ersten RT-Items (es kann ja mehrere geben)

if doc.hasEmbedded then
    forall eo in rtItem.EmbeddedObjects
        lngRichTextAttachmentSize = lngRichTextAttachmentSize + eo.FileSize
    end forall
end if
...

lngRichTextAttachmentSize und lngRichTextSize liefern zusammen die Gesamtgröße des RT-Feldes (fast), solange es wirklich nur ein Richtextfeld gibt).

Auch ein Loop über alle Items (... forall item in doc.items ...) und summieren der Größe des RT-Feldes Body bringt nix, da immer nur ein Body-Feld in der Schleife vorhanden ist.

Irgendwie scheine ich nicht an die benötigen Feldgrößen der Body-Felder 2 ... x zu kommen, sondern immer nur an die Größe des ersten.

Hat jemand noch Vorschläge o. Tips?

Anmerkung:
Wird der Inhalt des Richtextfeldes größer als 64k, werden entsprechend weitere Richtextfelder im Dokument angelegt und der Inhalt geteilt. Das sieht man im Eigenschaftenfenster des Dokuments.

[pram]

len(rt.getUnformattedText) + alle Attachments

An Screenshots kommst du aber mit LS nicht ran.

ODER: Du kopierst das RT-Feld in ein neues leeres tempDoc und fragst doc.size ab

Gruß
Roland

[eknori]

An die Screenshots kommst du mit LS2CAPI ran. Ist nicht trivial. habe ich auf dem letzten EntwicklerCamp gezeigt. Eine DemoDb mit dem ganzen Code für die RT Bearbeitung findest du hier http://www.eknori.de/2011-02-22/entwicklercamp-session-samples/
Gucke dir die Sachem mit den embedded images an. Das sollte weiterhelfen.

[ghostmw]

... schade.

Das mit dem Kopieren in eine leeres und abfragen, probiere ich mal aus.

@eknori: das mit ls2capi schaue ich mir nachher mal an.

Danke erstmal an alle 

[ghostmw]

@eknori:

Die Sample-Datenbank ist gut, leider stecke ich fest.

Zum einen werden meine einfügten Screenshots aus der Zwischenablage nicht als embedded images erkannt, noch gibt es im rtContainer-Objekt eine public Eigenschaft, wo man die Größe rausbekommen kann, alles etwas unbefriedigend.

Bitte nicht falsch verstehen, die Scriptlibs sind richtig gut und können eine gute Basis sein, aber mir hilfts momentan nicht weiter.

Mein Beispielcode ist folgender:

...
   Dim s As New NotesSession
   Dim db As NotesDatabase
   Dim col As NotesDocumentCollection
   Dim doc As NotesDocument
   Dim ITEM_OBJ As String
   Dim result As Variant
   
   Dim img As rtGraphic
   Dim ctxDump As New rtContainer
   Dim RTI As NotesInlineImage
   
   Set db = s.CurrentDatabase
   Set col = db.UnprocessedDocuments
   Set doc = col.GetFirstDocument
   
   ITEM_OBJ =  "Body"
   
   Set RTI = New NotesInlineImage ( doc, ITEM_OBJ )
   
   Call ctxDump.getRichTextItem(doc, ITEM_OBJ)
   Set img = ctxDump.getFirstElement (RT_OBJ_GRAPHIC)
   
   If  Not img Is Nothing Then
      Do While Not img Is Nothing
         Stop
      '   img.nfilesize ist private, geht nicht
         ' ... hier sollte die Auslesung folgen
         Set img = ctxDump.getNextElement (RT_OBJ_GRAPHIC, img)
      Loop
   End If
...


Auch gibt es keine Auflistung der Konstanten RT_OBJ_GRAPHIC u.ä.

[pram]

lngRichTextSize = rtItem.ValueLength ' ==> liefert aber nur die Größe des ersten RT-Items (es kann ja mehrere geben)

mir ist dazu noch was eingefallen.
an das 2./3. ... kommst du ran, wenn du das item löscht (zum Auslesen von $Scriptlib funktioniert dieser Trick, könnte aber bei RT-Items wieder anders sein):

while doc.hasItem(itName)
  set it = doc.getFirstItem
  length = length + it.valueLength
  call it.remove()
wend

Sollte man natürlich in einer KOPIE machen. ValueLength enthält nicht die Attachment-länge, diese stehen in den zugehörigen $FILE-Items

Was willst du eigentlich machen/erreichen

Gruß
Roland

[eknori]

Die Property Get EmbeddedImageSize in der NotesRichTextApi Lib gibt dir die Grösse aller embedded images in einem RTI zurück.

[ghostmw]

@pram:

lngRichTextSize = rtItem.ValueLength ' ==> liefert aber nur die Größe des ersten RT-Items (es kann ja mehrere geben)

mir ist dazu noch was eingefallen.
an das 2./3. ... kommst du ran, wenn du das item löscht (zum Auslesen von $Scriptlib funktioniert dieser Trick, könnte aber bei RT-Items wieder anders sein):

while doc.hasItem(itName)
  set it = doc.getFirstItem
  length = length + it.valueLength
  call it.remove()
wend

Sollte man natürlich in einer KOPIE machen. ValueLength enthält nicht die Attachment-länge, diese stehen in den zugehörigen $FILE-Items

Was willst du eigentlich machen/erreichen

Gruß
Roland

Ich muss abfangen, dass das RT-Item inkl. aller Attachments und Screenshots darin nicht mehr als 1 MB beim Speichern wird.
Die Attachments habe ich schon verarztet, passt.
Nur das RT-Item erweist sich mit seinen embedded images und mehrfachen Vorkommen eines RT-Items mit gleichem Namen.

@eknori:
bei mir leider nicht, habe testweise mal einen Screenshot gemacht und reingehängen, der wird nicht gefunden ... leider.

[ghostmw]

... habs gefunden, wie's funktioniert.

Man schnappt sich ein leeres Dokument und schiebt das Richtext-Item in das neue Dokument per CopyItemToDocument-Befehl.

Damit werden alle Screenshots und Attachments auch das aktuell noch nicht gespeicherte mitkopiert und man kann anhand der Dokumentengröße die Größe des RT-Inhalts ermitteln.

Danke für die Tips eknori und pram

P.S.: es gibt eine kleine Ungenauigkeit, da das Dokument ja selber auch einen gewissen Platz braucht, aber wir sind verdammt dicht dran.
Man muss noch im uiDoc den Befehl uidoc.Refresh ( true, true, true ) absetzen vor dem Kopieren und das rtItem mit rtItem.Update auch noch aktualisieren, dann aber klappts zuverlässig.

[koehlerbv]

Ich mache sowas mit privaten ProfileDocuments: Altes RTI dort löschen (so vorhanden), Grösse bestimmen vom "Rest", das zu RTI messende RTI rüberwerfen und erneut messen, den ermittelten ProfileDoc-Grössenrest abziehen - fertig.

Zwar stimmt auch das noch nicht (da in der ProfileDoc-Verwaltung ggf. neue Informationen entstanden sind), aber mit Bordmitteln dürfte man es wirklich nicht genauer hinbekommen. Vier Byte mehr oder weniger, bei denen sich eigentlich gar nicht so genau bestimmen lässt, wozu die nun gehören ...

Bernhard

[pram]

@Bernhard:

sofern das Dokument im Anschluss nicht gespeichert werden muss, reicht doch ein

Code

dim doc as new Notesdocument(db)

oder hat ein Profildoc auch hier einen Vorteil?
Der einzige Nachteil den ich kenne ist, dass bei obigen Vorgang eine UNID 'verbraten' wird, was u.U. zu vorgehenden Uhren führen kann wenn so sehr viele Dokumente in kurzer Zeit erzeugt werden.

Ansonsten stimme ich zu, dass man Dokumente wiederverenden soll, anstatt sie nach getaner Arbeit zu löschen, was jedes mal einen Deletion-Stub erzeugt. Da finde ich die Idee mit dem Profildoc ganz gut.

@Marco
vor uiDoc.refresh(True) wird hier ja öfters gewarnt und ich kann bestätigen dass die Funktion etwas buggy ist.
wenn im Dokument ein "SaveOptions" Feld (mit leerem Inhalt) vorhanden ist, dann passieren merkwürdige Dinge, z.B. wird ein PostSave-Event der Maske ausgelöst (aber kein querySave), ebenso wenn Felder zur Verschlüsselung enthalten sind (Publicencryptionkeys/SecretEncryptionkeys)

Gruß
Roland

[ghostmw]

@Bernhard:

sofern das Dokument im Anschluss nicht gespeichert werden muss, reicht doch ein

Code

dim doc as new Notesdocument(db)

oder hat ein Profildoc auch hier einen Vorteil?
Der einzige Nachteil den ich kenne ist, dass bei obigen Vorgang eine UNID 'verbraten' wird, was u.U. zu vorgehenden Uhren führen kann wenn so sehr viele Dokumente in kurzer Zeit erzeugt werden.

Ansonsten stimme ich zu, dass man Dokumente wiederverenden soll, anstatt sie nach getaner Arbeit zu löschen, was jedes mal einen Deletion-Stub erzeugt. Da finde ich die Idee mit dem Profildoc ganz gut.

@Marco
vor uiDoc.refresh(True) wird hier ja öfters gewarnt und ich kann bestätigen dass die Funktion etwas buggy ist.
wenn im Dokument ein "SaveOptions" Feld (mit leerem Inhalt) vorhanden ist, dann passieren merkwürdige Dinge, z.B. wird ein PostSave-Event der Maske ausgelöst (aber kein querySave), ebenso wenn Felder zur Verschlüsselung enthalten sind (Publicencryptionkeys/SecretEncryptionkeys)

Gruß
Roland

@pram:
Ich werde die Sache mit dem uiDoc.refresh(True) mal genauer betrachten, vielleicht kommt man auch ohne aus.
SaveOptions werden in dieser einen Applikation nicht benutzt und gelöscht wird das temp. Dokument auch nicht.
Aber der Tip mit dem Profildokument ist gut, werde ich mal prüfen.