Foto per Agent kopieren (Richtext)

[PromITheus]

Hallo zusammen,

ich möchte ein Mitarbeiterfoto von einer Notes-App automatisiert in eine andere Notes-App kopieren (von Dokument zu Dokument).
Eigentlich werden nur Richtextinhalte kopiert, leider ist das Foto im Zieldokument nicht sichtbar!?

Code:
            'Falls Foto bereits vorhanden löschen
            Call matchbasedoc.Removeitem("rFoto")
            
            'Foto einfügen bzw. austauschen
            Set rtitem = doc.Getfirstitem("rFotopasst")
            Call rtitem.Copyitemtodocument(matchbasedoc, "rFoto")
            Call matchbasedoc.Save(true, false, true)


Der Feldinhalt sieht passend aus (siehe Bild), er scheint Daten in der passenden Größe kopiert zu haben.

Wie bekomme ich ein sichtbares Bild?

[PromITheus]

Hier noch eine Variante die auch nicht funktioniert:

         'Falls Foto bereits vorhanden löschen
         Call matchbasedoc.Removeitem("rFoto")
         Call matchbasedoc.save(True, False, True)
            
         'Foto einfügen bzw. austauschen
         Set rtitem = doc.Getfirstitem("rFotopasst")
         Set basertitem = matchbasedoc.Createrichtextitem("rFoto")
         Call basertitem.Appendrtitem(rtitem)
         Call basertitem.Update
         Call basertitem.compact
                     
         Call matchbasedoc.Save(true, false, true)

Hierbei ändert sich Feld-Flags: SIGN SEAL

[Tode]

Du bist sicher, dass das Bild nur 172 Byte hat? Ich glaube eher nicht... Ich habe gerade bei mir folgenden Code probiert:

Code

Dim docNew as NotesDocument
Set docNew = New NotesDocument( g_dbFocus )
docNew.Form = "Memo"
Dim rtBody as NotesRichtextItem
Set rtBody = g_docFocus.GetFirstItem( "Body" )
Call rtBody.CopyItemToDocument( docNew, "Body" )
Dim ws as New NotesUIWorkspace
Call ws.EditDocument( True, docNew )

Mit g_dbFocus = MailDatenbank, g_docFocus = Mail im Focus mit eingebettetem Bild

Nach dem Öffnen war "Body" im neuen Zieldokument identisch zum alten... also prinzipiell funktioniert das. Wenn das Bild ein Attachment und nicht eingebettet ist, musst Du aber ggf. noch das $File- Item mitkopieren...

[TRO]

Gibt es in dem Quell-Dokument $File-Items, deren Attachment-Namen mit "STG" anfangen?

[PromITheus]

@TRO: Nein, einen solchen Namen gibt es bei den Anhängen nicht.

Aber $File könnte die heiße Spur sein! Jetzt muss ich es nur noch hinbekommen es mit zu kopieren.

[Peter Klett]

Code

Forall item In quelldoc
   Select Case Lcase (item.Name)
   Case "$file", "foto"
      'nix
   Case Else
      Call quelldoc.RemoveItem (item.Name)
   End Select
End Forall
Call quelldoc.CopyAllItems (zieldoc)

Natürlich darf quelldoc dann nicht gespeichert werden, sonst ist es kaputt. Ggf. müssten die alten Felder im zieldoc vorher noch gelöscht werden.

Ich habe so etwas schon einmal genutzt, allerdings innerhalb der gleichen Datenbank. Ob das datenbankübergreifend funktioniert, muss ausprobiert werden. Habe witzigerweise heute exakt die gleiche Themenstellung in einem anderen Kontext, wenn ich irgendwelche Erkenntnisse daraus ziehe, werde ich das hier schreiben

[Werner Götz]

Ein Richtext-Item referenziert die darin enthaltenen Anhänge nur, diese Referenzen werden beim bloßen Kopieren des Items (bei Codevariante 1 oben) nicht mitkopiert.

Zu den Vorschlägen bzgl. Kopieren der Items $FILE: Das klappt halt nur, wenn man nicht mehrere Richtextitems mit Dateianhängen im Quelldokument hat. Sonst kopiert man auch diese Anhänge mit.

Ich mache das Ganze an zig Stellen mit dem Codevorschlag 2 von oben, also mit AppendRTItem
Das klappt eigentlich immer.
basertitem.Compact sollte aus meiner Sicht aber vor dem basertitem.Update aufgerufen werden.

-Werner

[eknori]

Ich hatte das Thema vor Jahren mal auf dem Tisch. Nach viel Rumprobieren habe ich letzlich folgene Lösung implementiert

Code

									Set rtiSource = attDoc.GetFirstItem( "fill_att" )
									If ( rtiTarget.Type = RICHTEXT And rtiSource.Type = RICHTEXT ) Then
										Set rtnav = rtiSource.CreateNavigator
										If rtnav.FindFirstElement(RTELEM_TYPE_FILEATTACHMENT) Then
											Do
												Set att = rtnav.GetElement()
												filepath = GetSystemTempFolder & "/" & att.Source
												Call att.ExtractFile(filepath)
												Set att = rtiTarget.EmbedObject ( EMBED_ATTACHMENT, "", filepath)
												Kill filepath
											Loop While rtnav.FindNextElement()
										End If
									End If

Also Zwischenspeichern von Anhängen und sauber wieder an das Zieldokument anhängen.

[Peter Klett]

Habe beide Methoden ausprobiert, sowohl meine mit dem CopyAllItems als auch die von Werner mit AppendRTItem mit Compact und Update. Werners gefällt mir besser

eknoris Methode passt in meinem Umfeld nicht, da ich nicht auf die Platte zugreifen darf.

<OT>
Ein Agent auf einem Server von einer REST-Schnittstelle aufgerufen darf das nicht (irgendwas mit restricted operation). Die Alternativlösung von IBM, den Agenten über eine URL aufzurufen, hatte ich vor Monaten mal ausprobiert und funktioniert. Es klingt nach einem voll durchdachten Sicherheits-Konzept, dass man beim Server den http-Task aktivieren muss, um auf die Platte zugreifen zu können. Wir ziehen es da vor, den http-Task wegzulassen und dann eben Methoden zu suchen, die keinen Plattenzugriff benötigen (in dem Fall von damals wird eine zu erstellende Datei dann eben per DXL in ein Dokument angehängt, ohne Zugriff auf die Platte). Kein weiterer Kommentar ...
</OT>

[PromITheus]

Danke schonmal für die vielen spannenden Vorschläge 

@Werner: Ich verstehen deine Vorgehensweise noch nicht!?
Auch wenn ich mein update und compact tausche funktioniert mein Code nicht.
$File enthält also noch die Bildatei, das ist verständlich. Da im Quelldokument zwei Anhänge hängen, sollte ich $File ja nicht komplett rüber kopieren?
Und selbst wenn ich $File als Richtextitem komplett anhängen (AppendRTitem) möchte, sperrt sich Notes (Type Mismatch) 

[Peter Klett]

Code

Set basertitem = matchbasedoc.Createrichtextitem("rFoto")
Call basertitem.Appendrtitem(rtitem)
Call basertitem.compact
Call basertitem.Update

So funktioniert das bei mir, die $Files brauchen nicht angefasst zu werden, die werden automatisch mit kopiert

[PromITheus]

Ich konnte die Ursache (aber bisher noch keine Lösung) finden warum es bei mir nicht funktioniert.

Das Quellfeld ist ein Richtextlite Feld!

Hintergrund:
Mitarbeiter sollen ihr Foto in einer separaten App direkt selbst einfügen können (mit Einverständnisserklärung). Dabei habe ich ein Richtextlite mit der Einschränkung Piktogramm 200x200 versehen.
So werden die Bilder direkt auf die passende Größe gebracht und speicherschonend abgelegt. Das Foto müsste dann nur noch in das Mitarbeiterverzeichnis kopiert werden.

Nach mehreren Tests habe ich festgestellt, dass es mit Richtextfeldern einwandfrei funktioniert, aber mit Richtextlite leider nicht.

[Werner Götz]

War das Dokument mit dem Bild-Anhang denn schon mal gespeichert und wurde es dann neu geöffnet oder passiert das Kopieren quasi in dem Moment, in dem der Anwender das Bild angehängt hat?

[PromITheus]

Der Benutzer erstellt sein Einwilligungsdokument (DB1), hängt sein Bild 2x an (einmal in Originalgröße (Richtextfeld) und einmal im Ritchtextlite (Piktogramm)).
Er speichert ab und schließt das Dokument.

Ein zeitgesteuerter Agent prüft und kopiert die Bilder in die Mitarbeiterapp (DB2). Bisher alles Testbetrieb nicht produktiv.

[Werner Götz]

Ok, der RT.Light-Typ "Thumbnail" macht tatsächlich beim Kopieren das angesprochene Problem, habe das Problem nachgestellt.

Ich denke, das müsste man mal bei HCL melden, denn für die anderen Typen funktioniert das Ganze ja sauber.

Und wenn man sich mal das DXL zu einem solchen Dokument ansieht, dann stellt man fest, dass im Richtextfeld gar kein Verweis auf das dort eingebettete Bild existiert:

Code

	<item name='foto'>
		<richtext>
			<pardef id='1'/>
			<par def='1'/>
		</richtext>
	</item>

Dass da anscheinend auch noch andere Sachen "strange" laufen sieht man daran, dass wenn man den Typ des Feldes abändert auf Richtext (was bei den anderen RT-Light-Typen ja kein Problem ist), anschließend das Bild nicht mehr dem Item zugeordnet wird und unten in der Maske als Anhang angezeigt wird.

Ich fürchte, dass dann auch der Ansatz von Ulrich (eknori), die Anhänge zu detachen, nicht funktionieren wird.

Eine Idee, das Problem zu "umschiffen" wäre, die Eingabe in einem Dialog zu machen (damit hat man das Feature des Verkleinerns auf 200x200, beim Schließen das Feld in die Zwischenablage zu kopieren und anschließend in ein RT-Feld der Maske zu kopieren. Wird aber bestimmt auch etwas umständlich...

-Werner

[PromITheus]

Danke für die Analyse

Ich werde versuchen es über eine Dialogbox anzugehen.

[PromITheus]

Ich habe nun eine Lösung gefunden. Die Dialogbox wurde etwas kompliziert. Für Alle die es interessiert, vielleicht etwas hemdsärmelig, aber einfach:

Der Benutzer fügt ja selber sein Foto ein. Dafür habe ich das Richtextlite Typ Piktogramm Feld beibehalten (das direkt auf die passende Größe verkleinerte Bild ist sehr praktisch!).
Wenn der Benutzer nun speichert, wird per Funktionsformeln im User Frontend der Inhalt in ein weiteres, normales Richtextfeld kopiert.

Anschließend können alle Agenten problemlos auf das Foto zugreifen (der Code oben funktioniert dann) und es in die Mitarbeiter-App kopieren.

Hier der Code im QuerySave:

@If(cKopiegemacht != "1";
                     @Do(@Command( [EditGotoField] ;  "rFotopassttmp"  ) ;
                     @Command( [EditSelectAll] ) ;
                     @Command( [EditCopy] ) ;
                     @Command( [EditGotoField] ;  "rFotopasst"  );
                     @Command([EditSelectAll]);
                     @Command( [EmptyTrash] );
                     @Command( [EditPaste] );
                     FIELD cKopiegemacht := "1");
                     "")