Nein, ein Äquivalent wie in LotusScript mit der Übergabe der NoteID gibt es für das @Command nicht. Sehr viel Sinn würde das in der Formelsprache ja auch nicht ergeben.
A-Bär: Was willst Du denn erreichen? Ein Workaround wird sich sicher (gemeinsam) finden lassen.
Bernhard
Wenn du einen Agenten startest, dann hat dieser doch eh das aktuelle Dokumen im Zugriff. Dazu musst du ihm nichts übergeben.
Mal ganz grundsätzlich:
Wenn man nur Notes User hat, kann man Parameter von Macro zu Macro via Notes.INI übertragen.
Bei Web Usern mit Profildokumenten (natürlich auch bei Notes Usern).
Allerdings muss dann das aufgerufene Macro sich diese Info (die natürlich auch die DocID sein kann) "holen".
Ich habe das schon recht exzessiv gemacht, bis hin zu einer "temp" Datenbank, die zur Macrosteuerung benutzt wird.
Fraglich ist, ob es Dein Problem löst, weil Du ja offenbar auf Macros eines Drittanbieters zurückgreifst und wenn der nicht dafür ausgelegt ist, nützt das alles nichts.
Das wäre aber auch so, wenn Du Script benutzen würdest. Was das aufgerufene Script nicht "erwartet", also als Parameter auch verarbeitet, kannst Du auch nicht übergeben.
taurec: Es kommt darauf an, wo / von wem der Agent gestartet wird. Wenn ein User das anwirft (und nicht durch RunOnServer - aber das ist hier ja ausgeschlossen) sind Profildokumente schon die erste Wahl, insofern dies persönliche sind. Selbst, wenn ein User zwischen zwei PCs mit ein und er selben ID hin und her springt und lustig den Agent startet - gerade wegen dem Caching passiert da nichts, was dem Programmierer graue Haare bereiten würde.
Was die NOTES.INI angeht: Mit Recht haben mir da Mitte der Neunziger Admins mit Prügeln gedroht oder Freibier verlangt - ohne wirkliche Not hat da ein Programmierer nichts herumzuschmieren. Ich habe da meine Lektion gelernt: Wenn der Admin ein Problem mit einem Client hat, darf er sich da durch die ganzen Einträge durchwühlen - und das alles vollkommen ohne Grund (nur weil der Programmierer zu faul war, sich einen anderen Weg auszudenken). Alternativen gibt es genug.
Bernhard
Zu den Profildokumenten muss ich dir widersprechen.
jwege hat ja gesagt, daß er das für den Webzugriff so machen würde. Und gerade da kann es problematisch werden.
Ich hab da schon oft erlebt, daß die Werte durch das Caching eben nicht immer aktuell sind, vor allem wenn diese auf unterschiedliche Art und Weise gelesen und geschrieben werden.
Und wenn ich mit zwei Clients auf unterschiedlichen Rechnern arbeite, dann ist das definitiv ein Problem, denn wenn ich das Profildokument auf Rechner 1 verändere, dann ist es auf Rechner 2 noch gecacht und er bekommt die Änderung nicht mit.
Erst ein Cache bereinigen bzw Neustarten des Clients ändert das dann
Da haben wir uns aber missverstanden, taurec.
Zunächst: Im Web gibt es ggf. Probleme - volle Zustimmung.
Auf dem Client aber: Wenn - wie geschrieben - der Client auch den Agent ausführt, sorgt *gerade* das Caching dafür, dass das passt: Jeder Client schreibt die NoteID (oder UNID or whatever der Agent braucht) in seinen (!) Cache und führt dann den Agent aus. Irgendwann (spätestens beim Schliessen der DB) wird dann der Cache zurückgeschrieben ins ProfileDocument. Dass kann dem Agent aber vollkommen egal sein (und dem anderen Client, mit dem ich mit gleicher ID arbeite, auch).
Bernhard
Und hier ging es genau um die Verwendung von Profildokumenten zur Werteübergabe im Web. Also scheinst du mir in dem Punkt ja zuzustimmen.
Und zum Thema verschiedene Clients:
Ich hatte den Fall bei Profildokumenten schon häufig, daß Werte, die ich auf dem einen Client geändert habe, auf dem anderen erst da waren, wenn ich diesen neugestartet habe.
Und du stimmst mir da ja auch teilweise zu:
Zitat
Irgendwann (spätestens beim Schliessen der DB) wird dann der Cache zurückgeschrieben ins ProfileDocument.
Denn solange es nicht zurückgeschrieben ist wird der andere Client es nicht wissen was sich geändert hat
Aber gerade das Caching, was Profiledokumente für etliche Zwecke ungeeignet macht, hilft uns doch hier:
Client 1 schreibt Wert ins ProfileDoc und startet Agent (dessen Code der Client ausführt!), der sich den Wert aus dem ProfileDoc holt - eben aus dem Cache.
Was Client 2 zur gleichen Zeit macht, ist vollkommen egal - der hat ja seinen eigenen Cache.
Und wenn der Client Zeit und Lust hat oder die DB geschlossen wird, dann schreibt Client 1 (wie Client 2) den Cache zurück ins ProfileDoc. WAS da zurückgeschrieben wird, interessiert aber niemanden mehr - der Agent kriegt ja immer frische Daten.
Bernhard
Ich glaube du verstehst gerade nicht was ich meine:
Anhand deines Beispieles:
Client1 schreibt Wert in Profildokument.
Client2 startet Agenten, der auf Basis der Werte des Profildokumentes etwas tun soll. Dieser bekommt aber noch die alten Werte, eben wegen seines Caches.
Ich sach doch, wir missverstehen uns 
Warum sollte Client 1 den Wert schreiben, aber Client 2 führt den Agenten aus? Normal ist doch:
Client 1 schreibt Wert für Agent und startet diesen (dafür hat er ja eben den Wert bereit gestellt, den ER haben möchte.
Gleichzeitig oder zu einem anderen Zeitpunkt oder auch nie schreibt Client 2 seinen Wert für den Agent und startet diesen.
Die beiden werden sich (nicht im Web natürlich!) niemals ins Gehege kommen.
Bernhard
Wenn du meinst daß das nie vorkommen wird, gut
Aber ich kenne da genug Anwender bei denen solche ein Szenario fast schon zum normalen Arbeiten gehört.
Die arbeiten z.B. gleichzeitig lokal und in einer Citrix Umgebung mit Notes und wenn da die eine Aktion was ändert worauf die andere reagieren muss, dann ist da niemals sichergestellt, daß beide Aktionen auf dem gleichen Client ausgeführt werden.
Und wie ich schon mal sagte:
Der Antworter hat die Profildokumente als Lösung für die Werteübergabe im Web angegeben und da gibt es nunmal genug Probleme damit, um davon abzuraten.
