Wie (Namens-)Liste einem anderen Namensfeld per LS zuweisen?

[Sascha Seipp]

Moin allerseits!

Folgendes Problem: Ich habe in einem Dokument ein Feld vom Typ 'Namen', in dem ein Auftraggeber drinsteht (heißt SupportName). Nun will ich dieses als Vorbelegung in einem neuen Dokument in das Feld 'Besteller' schreiben.
Mit
  Call uidoc.FieldSetText("Besteller", actbedoc.SupportName(0))
klappt das, dabei stört mich aber die (0). Denn das Ursprungsfeld könnte ja auch mehrere Namen enthalten (Mehrfachwerte sind zulässig). Da auch das Zielfeld vom Typ 'Namen' ist, sollte doch sowas
  Set uidoc.Document.Besteller = actbedoc.SupportName
eigentlich gehen - wo liegt mein Denkfehler, daß da ein "Type mismatch" dabei herauskommt?

Ciao
Sascha

[koehlerbv]

Ah, mein Freund, der Biber ... 

Sascha, im Frontend werden Felder (!) bedient, und die wollen immer "Text". Im Backend hast Du es mit unterschiedlichen Datentypen und immer (!) mit Arrays zu tun (ausser RTIs).
Ergo: Entweder, Du vermischst nicht Front- und Backend-Methoden
actbedoc.Besteller = actbedoc.SupportName

oder

Du bedienst die Frontend-Felder so, damit diese glücklich sind (per Split wird das Array im Backend zu einem Frontend-tauglichem String). Ah - wir sind bei R5 - dann musst Du Ersatz für Split finden (Evaluate über @Implode zum Beispiel).

Ich hoffe, ich konnte entwas Licht ins Dunkel bringen. Ich weiss, dass sowas am Anfang sehr verwirrend erscheint - aber das gibt sich!

Bernhard

[Sascha Seipp]

Hallo Bernhard!

Der FE/BE-Unterschied erleuchtet schonmal ein wenig.
Das hier:
  Set newbedoc.Besteller = actbedoc.SupportName
bringt aber auch einen 'Type Mismatch'.

Etwas mehr Drumrum:

Code

	Dim uiws As New NotesUIWorkspace  ' aktueller Workspace
	Dim uidb As NotesUIDatabase		' aktuelle FrontEnd-DB
	Dim uidoc As NotesUIDocument	       ' aktuelles FrontEnd-Document
	Dim db As NotesDatabase			  ' BE-DB
	Dim actbedoc As NotesDocument	     ' Ursprungs-BE-Document
	Dim newbedoc As NotesDocument 	   ' neues BE-Document
	Set uidoc = uiws.CurrentDocument     ' ermittle aktuelles FrontEnd-Document aus aktuellem Workspace
	Set uidb = uiws.CurrentDatabase	      ' ermittle aktuelle FrontEnd-DB aus aktuellem Workspace
	Set db = uidb.Database			    ' ermittle BE-Datenbank aus Frontend-DB
	Set actbedoc = uidoc.Document	       ' ermittle ursprüngliches BE-Document aus aktuellem FE-Document
	Set newbedoc = db.CreateDocument  ' erzeuge neues BE-Document
	newbedoc.Form = "InventarBewegung" 	' setze Form des neuen Document auf 'InventarBewegung'
	Call newbedoc.Save(False, True)			' speichere neues BE-Document (sonst kann's nicht als FE-Document genutzt werden)
	Set uidoc = uiws.EditDocument( True, newbedoc )	 ' setze aktuelles FE-Document auf eben neu angelegtes BE-Document
''	Call uidoc.FieldSetText("Besteller", actbedoc.SupportName(0))	' klappt
	Set newbedoc.Besteller = actbedoc.SupportName	                   ' klappt nicht :-(

Über's Backend zu gehen erscheint mir schon sinniger als übers Frontend - kann das sein, daß ich im BE nicht mehr fummeln kann, wenn ich das Document schon dem FE übergeben hab? Ansonsten bin ich etwas verwirrt.

Und an der Stelle noch ne andere Frage, wenn sie auch nicht zum Thema paßt (aber doch zum obigen Code):
ich muß ja das neu angelegte Document erstmal speichern, damit ich es dem User zum Ausfüllen präsentieren kann.
Wenn der sich nun aber dafür entscheidet, daß das doch nicht seine Absicht war und das Dingen ohne Speichern schließt, hab ich ein Dokument mit lauter leeren Feldern, das keiner mehr braucht. Wie/wo kann ich das denn am besten wieder killen?
Geht da so ne Art AutoDestruct-Sequenz z.B. im Terminate-Ereignis der Maske, wenn ne bestimmte Bedingung erfüllt ist?
(wenn's in Zukunft eher gewünscht ist, für derlei in jedem Falle einen neuen Thread aufzumachen, dann bitte sagen, dann tu ich das fortan).

Ciao
Sascha

[koehlerbv]

Nein, dass passt schon zusammen, Sascha.
Antwort kommt gleich - muss nach was anderes fertig machen (sonst komme ich aus dem Konzept).

Bernhard

[Sascha Seipp]

Ich find's ja gleichermaßen erschreckend und (nicht zuletzt für mich) positiv, daß da noch jemand zu nachtschlafenden Zeiten noch bastelt... ;-)

Sascha

[koehlerbv]

Ich find's ja gleichermaßen erschreckend und (nicht zuletzt für mich) positiv, daß da noch jemand zu nachtschlafenden Zeiten noch bastelt... ;-)

Sascha

Naja, wenn der Kunde ein ernsthaftes Problem hat ... Dafür kann ich auch bestimmen, wann Sonntag ist oder wann der Wecker klingelt Und Ideen halten sich nicht an Tagespläne 

Jetzt aber zu Deinem Problem:
Das "Set" ist falsch: Du weisst ein Item einem anderen zu, also
doc1.Feld1 = doc2.Feld2.

Die Antwort auf die andere Frage folgt gleich.

Bernhard

[koehlerbv]

ich muß ja das neu angelegte Document erstmal speichern, damit ich es dem User zum Ausfüllen präsentieren kann.
Wenn der sich nun aber dafür entscheidet, daß das doch nicht seine Absicht war und das Dingen ohne Speichern schließt, hab ich ein Dokument mit lauter leeren Feldern, das keiner mehr braucht.

Nein, es gibt keinen Grund, das neu erstellte Dokument erst zu speichern, bevor es im Frontend geöffnet wird. Woher hast Du das?
Ich erstelle neue Dokumente meist zunächst über das Backend, da eine Menge Informationen aus dem Kontext der Erstellung heraus vorab zu ermitteln und abzulegen sind:
- In welche Organsationseinheit gehört der Ersteller, wer sind seine Chefs, wer deren Stellvertreter?
- Was die die Organisationshierarchie?
- Oder: Wie ist die Hierarchie der darüber liegenden Dokumente? Wer hat diese erstellt, wer darf diese lesen?
Und so weiter ...

Wenn all diese Angaben ermittelt sind, kann das im Backend erstellte und vorab befüllte Dokument mit NotesUIWorkspace.Edit im Frontend geöffnet werden - und eine vorherige Speicherung ist dafür vollkommen unnötig. Wenn dann der User nicht speichern will: Okay, er findet das normale Procedere vor.

Anders sieht es aus, wenn vorab RichTextItems befüllt werden müssen und diese dann in Richtext-Feldern (beachte den Unterschied zwischen Item und Feld!) sichtbar sein müssen. Dann MUSS das Dokument vorab gespeichert werden. Aber selbst das kann man in vielen Fällen umgehen. Aber das wäre nun wirklich einen eigenen Thread wert.

Auf jeden Fall aber gilt: Jegliches sinnloses Speichern von Dokumenten, die danach gleich wieder gelöscht werden, muss (und kann) man vermeiden - die Datenbank-Performance (und vieles andere) werden es einem danken.

Bernhard

[Sascha Seipp]

Hmja. Jetzt hab ich zwar kein 'Type Mismatch' mehr, aber dafür ein leeres Feld. Ein anschließendes
  Call uidoc.Refresh       '(spontane Eingebung)
hat schonmal nix gebracht. Versteh ich nicht recht, weil mit der FE-SetText-Variante geht's ja.


Zur anderen Frage:

Wenn man ein Dokument aus dem Backend in das Frontend konvertieren möchte, dann
muß das Frontend bereits geöffnet sein. Das Dokument, das im Frontend geöffnet
werden soll muß ebenfalls existent, zumindest gespeichert (STRG + S) sein

- so steht's im Lotus Script Tutorial auf der Homepage von A. Tauscher. (da kann ich leider keinen direkten Link anbieten, aber steht unter http://www.anton-tauscher.de/LotusScript/startdyn.htm => Dokumente\NotesDocument-Zugriff\Konvertierung

Sascha

[koehlerbv]

Tippfehler? Befüllst Du das Feld vor dem Öffnen im Frontend - oder ist dieses bereits geöffnet? Jetzt braucht es mehr Infos.

Bernhard

[Sascha Seipp]

Das war's! Hatte die Zuweisung nach dem geöffneten FE-Dokument gemacht (und mir ja schon gedacht, daß das nich sofort angezeigt wird - das Refresh ist hier wohl nicht das Mittel der Wahl).
Ich hatte es deshalb hinter dem EditDocument, weil ich ja vorher das FieldSetText benutzt hatte, was ja nur geht, wenn's FE-Dok da ist.
Richtige Reihenfolge hilft also ungemein!

Ich bedanke mich, du hast mir wieder mal sehr geholfen! Jetzt geh ich aber erstmal ins Bettchen... :-)

Ciao
Sascha

[koehlerbv]

Wenn Du im geöffneten Frontend-Dokument ein Refresh brauchst, ist NotesUIWorkspace.ViewRefresh ungemein hilfreich. Das wird häufig verkannt - und ist wegen des Namens schwer zu finden.

Gute Nacht! Und viel Erfolg!

Bernhard