LS: Grösse eines RTItems ermitteln

[koehlerbv]

Hallo zusammen,

ich habe vermutlich ein Brett vor dem Kopf - oder es ist wirklich nicht trivial:
Gegeben sei ein RTF von mehreren. Zu diesem einen RTF muss die Grösse à la NotesItem.ValueLength ermittelt werden. Im RTF können durchaus
- importierte Bilder (= mehrere RTItems)
- Attachments (viele $Files)
- OLE-Objekte (auch viele $Files)
stecken.

Seh' ich nur momentan den Wald vor lauter Bäumen nicht, oder ist mit "NotesItem.ValueLength zeigt die Grösse des letzten Items, das mit GetFirstItem gefunden wurde, an - und sonst gar nichts." wirklich Ende Gelände ?

Vielen Dank im Voraus.

Bernhard

PS: Wie oben angedeutet, kommt wegen mehrerer RTFs ein workaround via NotesDocument.Size nicht in Frage.

[eknori]

hmm, wirklich nicht trivial, wenn du die exacte Groesse ermitteln willst; ein Fall für die NotesAPI. Aber das schüttele ich momentan auch nicht so aus dem Ärmel. Den Spezialisten in RTItem kennst du ja  ..

Oder unscharf: FormattedText + AttachmentLenght .. irgendwie so in der Richtung

[koehlerbv]

Danke Ulrich. In die Richtung API gingen meine Gedanken auch (und da könnte man auch Normunds fragen, denke ich), aber eben nur als "letzte Massnahme". Mein "brett vor'm Kopp" ist also wohl doch nicht sooo dick ...

Die unscharfe Lösung geht übrigens nicht, da ja durchaus auch Images und OLE-Objekte vorhanden sein können und eben nur eines von mehreren RTIs überprüft werden müssen ...

Bernhard

[eknori]

ähm, eines ginge noch. @DocLength - @Sum ( aller NonRTFelder )    Zur Not

[TMC]

Habe mich in der Vergangenheit auch schon öfter mit solchen und ähnlichen Dingen beschäftigt, mir fällt aber jetzt auch nichts ein.

Höchstens ab ND6: Dokument in DXL-Stream und von dort aus dann analysieren. Feldinhalte sind dort easy speziellen Feldern zuzuordnen gemäß den Tags. Dann Länge auslesen und in Bytes/KB etc. umwandeln.

Frage am Rande: Warum brauchst Du das denn für ein spezielles RT-Item (von mehreren)?
Haben die restlichen RT-Items fixe Werte, oder sind die auch dynamisch von der Größe her?
2. Frage: Brauchst Du das zur Laufzeit, also z.B. beim Öffnen/Speichern eines Docs? Dann könnte auch meine ab ND6 vorgeschlagene DXL-Lösung kritisch sein aus Performancesicht.

[eknori]

wenn ich Bernhard richtig verstanden habe, möchte er die Grösse eines RT Feldes ermitteln; OK da soll in LS erfolgen, ich mach e mal den Anstz in @Formula ( oder so ein Mix daraus )

@DocLength liefert ja die ( ungefähre , 64 kb Unschärfe ) Groesse des kompletten Docs zurück..
GetFormattedText(RTItem) gibt die Groesse des Textanteils eines RTitems zurück.

Also ist tmp:= @DocLength ( oder doc.size ) - GetFormattedText ( RTItem) = Groesse aller der Attachments incl $file Items des gefragten RTItems,

Daraus folgt daß tmp + @Length(GetFormattedText (RTItem)) die Grösse des betreffenden RTItem liefert. 

[TMC]

@Ulrich: aber Bernhard hat ja glaub ich mehrere RT-Items im Dokument, die vielleicht auch noch dynamische Größen haben? (siehe auch meine Frage oben)

NotesItem.ValueLength zeigt die Grösse des letzten Items, das mit GetFirstItem gefunden wurde, an - und sonst gar nichts.

Hier muss ich nochmal nachbohren:
Hast Du evtl. mehrere Items mit gleichem Namen, bzw. willst Du das abfangen?
Hier könnte man doch die Items Property der NotesDocument-Klasse nutzen, und alle Items über eine Schleife abarbeiten. Soweit ich weiß hat diese Property *alle* Items als Array. D.h. gibt es z.B. mehrere Body-Items, so sollten in dem Array auch mehrere Items "Body" verfügbar sein. Diese könnte man dann durchloopen und mit NotesItem.Name dann abfragen, ob es einem definierten Namen entspricht. Wenn ja: lngCount = lngCount + NotesItem.ValueLength

[koehlerbv]

Danke für Eure Mithilfe. Ich denke, ich habe eine (zwar unscharfe, aber durchaus brauchbare Lösung gefunden):
Das Loopen durch die Items bringt leider nix - es heisst ja "GetFirstItem". Ein eingefügtes Bild kann durchaus schon mal mehr haben ... Und selbst puren Text können Labersäcke ausdehnen bis zum geht nicht mehr. Folge: x Items gleichen Namens. OLE gibt viele $Files und ein kleines RTI, ein Attachment ein $File (was man nett auslesen kann) oder ggf. auch mehrere (jetzt ohne Garantie).

Ich mache jetzt folgendes:
Temporäres Dokument erzeugen
NotesItem.CopyToDocument
und nun die Grösse dieses temp. Dokuments ermitteln (NotesDocument.Size. Das ist bis auf den üblichen Overhead für meine Zwecke genau genug (ca. 100 Byte Overhead bei RTI mit importierten Images, durchaus 1 kB bei Attachments oder OLE-Objects).

Nochmals vielen Dank für Eure Mühen.

Bernhard

PS: Ich hätte dies vermutlich schon dreissig Minuten eher posten können. Da kam mir die Idee mit dem temp. Document, und ich dachte mir: Darauf ein Wieninger ! Im Flur (zappenduster) raschelt es. Hä ? Ich hatte doch erst zwei Wieninger  Da raschelt es wieder. Licht an - und wer grinst mich an: Rufus, einer unserer vier Gerbils. Ausgebrochen aus einem Terrarium, welches durch ein dichtes, sehr stabiles Alunetz abgedeckt ist. Das Loch im Netz war aber beeindruckend. Und das hat er in höchstens dreissig Minuten geschafft (fast so lange habe ich auch gebraucht, das Viech wieder einzufangen !). Nun sitzen die vier zur Strafe in einem Käfig aus Stahl ...

[koehlerbv]

Zum Thema siehe auch diesen Beitrag von Andreas "Glombi":
Werte mehrerer Items mit gleichen Namen auslesen

Das Verfahren brachte auch nix (nachdem ich vorher schon probierte hatte, das über ein temp. Document zu machen und dann nach dem Auslesen / Aufsummieren die Items zu löschen - aber NotesItem.Remove knallt ja korrekterweise gleich alle Items diesen Namens 'raus).

Bernhard

[TMC]

Bernhard, die Idee des temporären Docs hatte ich im Hintergrund auch noch, aber wußte nicht ob Du das zur Laufzeit brauchst oder nicht, daher meine Frage. Denn Hintergründe hatten leider in Deiner Frage gefehlt.

Das Loopen durch die Items bringt leider nix - es heisst ja "GetFirstItem"

Schau Dir noch mal meine letzte Antwort an. Ich meinte Items Property.

Items property 
Read-only. All the items in a document. An item is any piece of data stored in a document.

Also "All the items in a document". Meines Erachtens bekommst Du damit alle Items, unabhängig von "GetFirstItem".

Weiß jetzt aber auch Anhieb nicht, ob Dir damit auch die systeminternen $File-Items berücksichtigt werden via ItemLen-Property.

[koehlerbv]

Nö, passt schon Matthias. Aber NotesDocument.Items durchgeschleift bringt Dir das Item auch nur einmal, auch wenn es mehrfach auftaucht. An sich ist das ja auch vollkommen korrekt.
Keine Ahnung, ob es eine Version gibt, wo sich dies anders verhält, glaube ich aber eher nicht.

Und ja: Stecken EmbeddedObjects in einem RTI, werden die ganz brav auch mit berücksichtigt. Das funktioniert ja auch bei CopyItemToDocument, das nimmt auch $File oder $OLEOBJINFO mit. Nur das ValueLength liefert eine absolut unbrauchbare Aussage im Falle von RTIs.

Nochmals danke,
Bernhard

[TMC]

OK, also kann man das abgehaken. So wie ich Deine Erfahrungen hier jetzt deute, ist dann mit der Laufzeitberechnung via LS unter R5 keine Möglichkeit vorhanden (außer eben der Umweg über TempDoc - was aber zur Laufzeit mir sehr ungünstig erscheint).

[koehlerbv]

Jo, ich glaube auch, das kann man abhaken.
Allerdings ist dies kein R5-Problem, R6 verhält sich das genauso. Und das ist ja (bis auf NotesItem.ValueLength) vollkommen korrekt: Ein Item > 64kB wird auf mehrere (interne) Items verteilt. Es wäre jetzt ja übel, wenn man diese bei entsprechenden Operationen alle einzeln ansprechen müsste. Nur sollte dann auch irgendwo die tatsächliche Grösse bezogen auf ein tatsächliches Item zurückgegeben werden.

Du sprichst jetzt immer von "Laufzeit". Damit haben wir es doch immer zu tun, oder übersehe ich da was ? Eine negative Beeinflussung durch ein TempDoc kann ich aber nicht wirklich erkennen - das Objekt ist ja sowieso instantiiert, und es wird lediglich eine Abbildung im Speicher erzeugt. Dazu nur von einem einzigen Item des originalen Docs. So what ?

Bernhard

[datenbanken24]

Hallo Bernhard,
man staunt ja immer wieder in diesem Forum...

Mongolische Wüstenrennmaus.
Einwandfrei. 

Hört sich an wie ein Protagonist in irgend einem verrückten Computerspiel,
und so was gibt es wirklich...

Danke für den Lacher in der Abendstunde.

Gruß,
Uwe

[TMC]

Bernhard:

Wegen "Laufzeit":
Unglücklicher Begriff meinerseits. Meinte da "On the fly", also sowas wie @Attachments von der Performance her. Z.B. ausgeführt wenn User Doc speichert, öffnet oder was auch immer, und kein scheduled Agent.

Wegen

Aber NotesDocument.Items durchgeschleift bringt Dir das Item auch nur einmal, auch wenn es mehrfach auftaucht.

Das kann ich jetzt nicht bestätigen, gerade mal schnell getestet:

Code

Sub Click(Source As Button)
	
	Dim uiws As New NotesUIWorkspace
	Dim session As New NotesSession
	Dim doc As NotesDocument
	Dim strTest As String
	
	Set doc = uiws.CurrentDocument.Document
	
	Forall itm_loop In doc.Items
		strTest = strTest & itm_loop.Name & " -- Length: " & Cstr(itm_loop.ValueLength) & Chr(10)
	End Forall
	
	Msgbox strTest, 64, "Itemlist according to NotesDocument.Items"
	
End Sub

Das in einem Button eines Dokuments, welches in einem RTF mehrere Attachments enthält, listet u.a. mehrere $File-Items unterschiedlicher Länge. Meines Erachtens kann man damit also durchaus gezielt Items ansprechen, wenn die selben Namen mehrmals vorkommen, erscheinen diese auch mehrmals. Bin ich auch froh drüber, damit stimmt wieder die Doku.

[koehlerbv]

Ich habe das eben auch noch unter R6.5.3 mit exakt Deinem Code getestet, Matthias. Und nein: Das bringt nix - es zeigt nur jeweils die Werte eines einzelnen Items an, auch wenn dieses mehrfach vorkommt. Bei $File wird - wenn es sich um ein Attachment handelt - logischerweise nur der Overhead angezeigt, nicht aber die wirkliche Attachment-Grösse.

Und trotzdem denke ich, dass die Doku nach wie vor stimmt. Nur eben ValueLength nicht. Unten ein Schirmschuss - wie gesagt, mit Deinem Code (den ich ja anfangs auch hatte in der Art.
InventoryFigures sind in Wirklichkeit 3 Items wegen des Bildes und hat ca. 67 kB ...

Bernhard

[TMC]

Kann jetzt sein, dass wir komplett aneinander vorbeireden, Bernhard.

Meine Intension war: Es gibt ja "GetFirstItem". Ich bekomme damit nur das 1. Item "$File". Will ich alle $File-Items auswerten oder was auch immer: keine Chance.
Abhilfe sehe ich in NotesDocument.Items. Damit bekomme ich alle Items eines Dokuments. Gibt es z.B. $File mehrfach, somit kann ich auf jedes einzelne $File-Item einzeln zugreifen.

Ich vermute Du meinst was anderes, Bernhard?

Unten ein Screenshot von mir, wie zu sehen, werden mehrere $File-Items gelistet (die Enten mögen mir das verzeihen  ).

*edit*: das ganze unter Notes 6.5.3

[koehlerbv]

Hallo Matthias,
ich glaube, wir reden nicht aneinander vorbei und verwenden jetzt den exakt gleichen Code. Du hast aber x Attachments und zwei RTFs, daher auch mehrere $File.
Und kontrolliere mal, ob die Grössenangaben so stimmen. Die Enten in Body 1 4310 Bytes, in Body 2 (attached) 35.814 ?
Solche Angaben bekomme ich ja auch, aber sie stimmen nicht mit der Realtität überein. Und nochmals: An sich ist das ja alles richtig, was Notes da macht - bis auf den Zusammenhang von GetFirstItem und ValueLength ...

Bernhard

[TMC]

Ich meinte wg. Vorbeireden: "GetFirstItem". Hatte aus Deine Frage auch (warum auch immer) interpretiert: wie bekomme ich alle Items eines NotesDocuments in Zusammenhang mit GetFirstItem. Da liegt natürlich doc.Items auf der Hand, denn damit kann man auf mehrere gleichnamige Items eines Docs zugreifen.

Body 1:
JPG hat eine Größe von 34 KB. Das ZIP-File hat 43KB.

Lt. Document Properties:
Body1: Data Length: 4308 bytes
$File: Data Length: 61 bytes
$File: Data Length: 63 bytes

Body 2:
Grafik ist importiert (stammt aus JPG von Body 1, also Größe von 34 KB).
Lt. Document Properties hat Body 2: Data Length: 35812 bytes

D.h. die Dokumenten-Eigenschaften von Body1 stimmen schon mal nicht. ValueLength scheint sich an diesen Eigenschaften zu orientieren und zeigt ähnliche (falsche) Werte.

[koehlerbv]

NotesDocument.Items liefert Dir das aber nur bei $Files - nicht bei doppelten RTFs, Matthias.

Wie man es dreht und wendet - man kriegt kein Item zu fassen, von dem man sicher sagen, dass die Grösse exakt angegeben wird. Die grösste Annäherung, die ich bisher gefunden habe, ist eben ein temp. Dokument, in das man genau dieses Item kopiert (und das zieht alle embedded objects mit - Notes ist ja letztlich doch wieder freundlich  )
Mit dem overhead muss man dann leben, und TempDoc vorher / TempDoc nachher als Vergleich liefert natürlich immer noch keine exakte Angaben. Das ist aber - da es ja um RTIs geht - sowieso nicht möglich, hier gibt es ja sogar zwischen den Client-Versionen (geringe) Unterschiede). Auf 1 kB genau reicht mir das dann schon 

Bernhard