Leserfeld mittels LS füllen

[DrNotes]

Hallo Leute,

ich bin am verzweifeln:

Meine Testumgebung:
----------------------------
Eine Maske hat ein Feld "AlleLeser" das mittels einer Schaltfläche gefüllt werden soll (also die Schaltfläche kopiert den Inhalt des Strings Text in das Feld AlleLeser .

*AlleLeser: Typ = Leser, Bearbeitbar, Mehrfachwerte zulassen, Werte trennen bei Eingabe von Komma

* Schaltfläche:
Sub Click(Source As Button)
Dim session As New NotesSession
Dim db As New NotesDatabase( "", "" )   
Dim workspace As New NotesUIWorkspace
Dim uidoc As NotesUIDocument
Dim Text As String

Set uidoc = workspace.CurrentDocument

Text = "User1/Domain, User2/Domain, User3/Domain, User4/Domain, User5/Domain, User6/Domain, User7/Domain, User8/Domain, User9/Domain, User10/Domain, User11/Domain"
Call uidoc.FieldSetText( "AlleLeser", Text)
End Sub

Wenn ich die Schaltfläche drücke, steht im Feld AlleLeser lediglich:
"User1/Domain, User8/Domain, User9/Domain, User10/Domain, User11/Domain"

Das ganze funktioniert lediglich, wenn ich für
Text="User1/Domain, User2/Domain, User3/Domain, User4/Domain, User5/Domain" definiere.

Sobald das Feld Text größer ist, beinhaltet das Feld AlleLeser nicht mehr den kompletten String.

Ich blick echt nicht durch?

Könnt ihr mir vielleicht helfen, oder ist das wieder einmal eine Laune des 5.0.2.c Clients?

Danke im voraus!

[TMC]

Ich muss sagen, dass ich mit der FieldSetText-Methode eigentlich nie arbeite, ich persönlich bevorzuge da das Backend. Daher kann ich auch das Verhalten nicht bestätigen, aber grundsätzlich klingt es beim ersten Lesen Deines Code für mich so, dass es funktionieren sollte.

Na ja, ich würde es über ein Array lösen, also:

Dim doc as NotesDocumet
Set doc = uidoc.Document

Dim strTextArray(9) as String
strTextArray(0) = "User1/Domain"
strTextArray(1) = "User2/Domain"
...
strTextArray(9) = "User10/Domain"

Call doc.ReplaceItemValue("AlleLeser", strTextArray)

[Semeaphoros]

Call doc.ReplaceItemValue("AlleLeser", strTextArray)

Da würde ich dann aber so:

item = doc.ReplaceItemValue("AlleLeser", strTextArray)
item.isReaders = True

[TMC]

danke, das hat Sinn (auch wenn hier vermutlich wohl letztendlich dann über @Commands / Frontend gespeichert wird).

[Semeaphoros]

Es macht vor allem deshalb Sinn, weil man ja nicht ausschliessen kann, dass dann doch plötzlich ein Prozess per Backend speichert. Ich hab jetzt aber keine Ahnung, ob das Speichern übers Frontend bei einem bestehenden Item, das im Frontend nicht geändert wurde, auch tatsächlich setzt. Man kann Gründe für beide Verhaltensweise geltend machen .... vielleicht hat das ja schon jemand probiert?

[TMC]

Meines Erachtens müsste beim Frontend-Speichern (z.B. @Command) ein Error kommen, wenn man zuvor in ein Nummernfeld per Backend ein Textstring gesetzt hast, weil dann beim speichern übers Frontend bzw. Refresh die Validierung zuschlägt.

[Semeaphoros]

Wieso Nummernfeld?

[TMC]

War nur ein Beispiel: Wenn Du ein Nummernfeld hast, und dort einen Text reintippst und das Notes-Dokument speicherst per @Command, dann meckert Notes und lässt Dich nicht speichern, weil die Validierung zuschlägt.

[koehlerbv]

Klar ist, dass sich Operationen im Front- und im Backend immer gegenseitig beeinflussen können.
Was die Eigenschaften IsReaders oder IsAuthors angeht, wünschte ich mir, ich hätte mehr Zeit, hier die gegenseitige Beeinflussung von Front- und Backend mal näher untersuchen zu können. Die fehlt mir aber leider, und ich sage mir hier: Es gibt wichtigeres ...
Ich finde Semeaphoros' Ratschlag, die Property explizit zu setzen, extrem wichtig - ich mache dies immer und ohne ausnahme so, dass Backend-Items unter allen Umständen diese Properties übergebügelt bekommen. Dazu sind diese Properties für die Sicherheit einfach zu wichtig.
Vor Jahren (war R5.0.3 ?) habe ich u.a. Agents für Gedys-Applikationen geschrieben, die dort diese Properties wieder gerade gezogen haben, nachdem diese durch den Code des Herstellers verloren gehen konnten. Wie gesagt: Ich hätte dies gerne untersucht, aber die Lösung des Problems an sich war mir wichtiger. Ich ahnte (! Mehr nicht !) damals, dass ein Formel-Agent, der Inhalte entsprechender Felder änderte, während betroffene Dokumente im FrontEnd noch offen waren, dafür verantwortlich war.

Wichtig ist m.E. auch, dass man gerade bei Readers- oder Authors-Items alles dafür tut, dass diese ihre Properties behalten. Lieber eine Zeile zuviel als zuwenig. Zumal ich in letzter Zeit (wieder mal) feststelle, dass sich das Verhalten von Notes von Unterversion übel ändern kann. Letzte Woche: Zugriff von einem 6.5.3er Client auf einen 5.0.8er Server (fremde Domäne - keine nicht empfohlene Installation) (NotesView.GetAllEntries) - Red Screen of Death. 6.5.1 ging noch, 6.5.4 scheint wieder zu gehen. Dann: Zuweisung einer Currency-Variable im Backend an ein Zahlen-Feld (Darstellungsform Currency): Im Life-Betrieb (innerhalb einer Applikation) freute sich NSD über Arbeit, in einer Testumgebung (diese Funktionalität pur) wurde das Item überhaupt nicht gefüllt. 6.5.1 ging, 6.5.3 war das Problemkind, 6.5.4 geht wieder.
IBM hat da momentan ein Qualitätsproblem, das nicht zu übersehen ist. Wir hatten das in frühen 5.xer Versionen auch schon mal. Momentan nervt es mich aber und hält mich massiv von meiner Arbeit ab.

Bernhard

PS: Sorry, dass es abschliessend off-topic wurde.

[TMC]

Danke für die Ausführung Bernhard.
Ich muss zugeben, dass ich da bisher teilweise etwas nachlässig war, aber man lernt ja ständig hinzu 

Generell hab ich mir das gerade angesehen:
Setzt man ein Item im Backend, und speichert im Frontend, so wird lt. meinem Test der Feldtyp (nicht Item!) genommen, der in der Maske definiert ist. Dies bestätigt also meine oben gepostetes.

Nichtsdestotrotz kann ich Euch beiden (Jens und Bernhard) nur zustimmen: besser die Item-Property setzen. Man weiß ja auch nie: vielleicht fällt jem. in 1 Woche ein den Code zu modifizieren und das Backend-NotesDocument nach dem Setzen des ItemValues dann im Backend zu speichern.

[Semeaphoros]

Bernhard, Danke für Deine Ausführungen, ich hatte gehofft, dass Du das vielleicht weisst. Meine Strategie ist die gleiche. Vielleicht hats ja sonst jemand mal getestet.

Matthias: verstehe, denke aber, dass Feldvalidierung und die Feldattributte "Reader"/"Author" nicht zwingend identisch behandelt werden, deswegen stutzte ich über Deine Bemerkung.

Nachtrag, nachdem Matthias eben probiert hat: Danke für die Infos und Deine Bemerkung wegen Speichern im Backend entspricht ja dem, was ich oben schon geschrieben hat. Muss ja noch nicht einmal im gleichen Kontext passieren, kann ja sein, dass jemand in irgend einem anderen Event oder in einer Action via Backend speichert.

[DrNotes]

Call doc.ReplaceItemValue("AlleLeser", strTextArray)

Da würde ich dann aber so:

item = doc.ReplaceItemValue("AlleLeser", strTextArray)
item.isReaders = True

So ich hab's jetzt mit ReplaceItemValue versucht, habe aber exakt das gleiche Problem.

Ich vermute ja ganz stark, dass das "AlleLeser"-Feld die Trennung der einzelnen User im String mittels Beistrich nicht checkt.
Wenn ích z.B. einen String mit
Text = "Hallo1 Hallo2 Hallo3 Hallo4 Hallo5 Hallo6 Hallo7 Hallo8 Hallo9 Hallo10 Hallo11 Hallo12 Hallo13 Hallo2 Hallo14 Hallo15 Hallo16 Hallo17 Hallo18 Hallo19 Hallo20 Hallo21 Hallo22 Hallo23 Hallo24 Hallo25 Hallo26 Hallo27" definiere, übernimmt er den kompletten String.

Hat vielleicht dazu jemand eine Idee?


Grüße.....Tom

[Semeaphoros]

Die Idee hat Matthias schon gegeben. Essentiell ist, dass die Namen als Array und nicht als einzelner String übergeben werden. Mach das genau so, wie Matthias das vorgegeben hat und es funktioniert. Wenn Du nur einen String übergibst, ist das genau ein String gleich ein Eintrag. Auflösungen für Felder mit Mehrfachwerten passieren im Frontend und lassen sich per Script nicht zuverlässig nachvollziehen, ist aber auch nicht nötig, da das über Arrays wunderbar funktioniert.

[koehlerbv]

Um das ganze einfacher und dynamischer zu halten, kannst Du Deinen kommagetrennten String auch mittels Evaluate ("@Explode ...") in ein Array umwandeln und dieses dann dem Leserfeld zuweisen.

Bernhard

[DrNotes]

Essentiell ist, dass die Namen als Array und nicht als einzelner String übergeben werden. Mach das genau so, wie Matthias das vorgegeben hat und es funktioniert.

Vielen Dank an alle für Eure Hilfe - mit der Array-Variante funktioniert es.

LG.....Tom