Beiträge von Tammo

Hab's gefunden. Die DB ist vom Typ "DB-übergreifende Suche". Setzt man die Eigenschaft auf "Standard" geht's.

Gruß Ralf

die DB wurde ursprünglich mit 7.0.3 erstellt, dann aber sowohl mit 8.0.2 als auch mit 8.5 weiterbearbeitet. Der Fehler taucht aber in allen Versionen auf. Wenn ich das Ganze mit der NotesViewEntryCollection mache geht's.

Hallo zusammen,

ich habe ein merkwürdiges Problem:

Ich möchte eine DocumentCollection mit ...View.GetAllDocumentsByKey(key) aufbauen. Die Ansicht hat die notwendige sortierte Spalte. Die DocumentCollection wird auch scheinbar erstellt (Count=3), wenn ich aber mit ...Col.GetFirstDocument das erste Dokument ansprechen will, bekomme ich kein Objekt/Dokument zurück.
Wenn ich das erste Dokument mit ...View.GetDocumentByKey(key) suche geht's. Die Ansicht zeigt mir alle Dokumente an, wenn ich sie direkt aufrufe. Hat jemand eine Idee woran es liegen könnte?

Sollte diese Frage schon tausendmal beantwortet worden sein, sorry! Ich habe zumindest nichts Passendes gefunden...

Super - das war's!!! Musste die Sun JRE als Addon aktivieren - Tausend Dank....

Hab's gelesen, aber wie bekomme ich das Applet im den Cache? Mein IE öffnet auch keine anderen Views mit Applet, unabhängig davon, ob die Lokal gespeichert sind oder auf einem Domino-Server. Hab das jetzt mit diversen Datenbanken ausprobiert, immer dasselbe Ergebnis, Mozilla geht (Opera übrigens auch), IE nicht...

OK, das kann sein - ich kriegt diesen Source dann wohl aufgrund der Eigenschfaten der View nicht zu fassen. Sei's drum - ich habe jetzt festgestellt, daß Safari es auch nicht macht, obwohl Mozilla-basiert und Java- und Javascript erlaubt sind (so wie bei meinem IE auch). Aus irgendeinem Grund scheint das View-Objekt dort nicht anzukommen.

Muss wohl noch ein wenig tiefer bohren...

Um es mal deutlich zu sagen: Ich weiss es nicht!

Aber - in aller Naivität - wieso kann's Mozilla und der IE nicht? Wiese hat Mozilla überhaupt einen anderen Quelltext als IE? Hab's zur Ansicht mal drangehängt...

äh.. Jaaah. Zum Testen schon !?

weiter geht's

5 Zeilen drüber wird folgendes referenziert:
!--script src="/domjava/WriteHtmlArgument.js" type="text/javascript">
/script>

Den Pfad "/domjava/WriteHtmlArgument.js" gibts aber auf meinem Rechner nicht (erwähnte ich schon, daß ich lokal arbeite?).
Der Quelltext unter Mozilla sieht ganz anders aus (möchte ich hier jetzt nicht alles posten).

Hi, danke erstmal für die Antwort. Die Ansicht ist eine "stinknormale" Adressansicht. Es funktionieren aber aacu die anderen Ansichten nicht. Die DB wurde ursprünglich auf Basis eines Notes-Adressbuchs erstellt und angepasst.
Im Quelltext des IE's finde ich unter der angemeckerten Zeile folgendes:

_domino_WriteHtmlArgument('
applet name="view" code="lotus.notes.apps.viewapplet.ViewApplet.class" codebase="/domjava" archive="nvapplet.jar" alt="Ansicht" width="756" height="100%" mayscript
param name="cabbase" value="nvapplet.cab">
param name="Database" value="dev/adressen.ntf">
param name="ViewName" value="MeinNAME">
param name="focus" value="true">
param name="PanelStyle" value="LINE_BORDER">
param name="ViewUNID" value="hier steht die UNID :-)"><param name="Expand" value="TRUE">
param name="bgColor" value="#FFFFFF">
param name="locale" value="de">
param name="IconPath" value="/icons">
/applet>');

(Musste einige Zeilen ändern um es anzeigen zu lassen!)

Hallo zusammen,

ich möchte eine Ansicht per Java-Applet (Notes-Standard) darstellen. Die Ansicht in eine Seite eingebettet. Leider funktioniert das im IE nicht(Script-Fehler: "Objekt erwartet"), in den Mozilla-Browsern schon. Kann mir da jemand weiterhelfen?

P.S. IE 7.0.5; Notes 7.02; JRE 1.0.6

Hab ich gemacht - funktioniert auch nicht ...

Ich glaub ich hab den Fehler
Die Form wird per Eigenschaft automatisch im EditMode geöffnet. Mein Script "ws.EditDocument(True, doc)" versucht den EditMode zusätzlich - was schon mal unsinnig war. Wenn ich "ws.EditDocument(False, doc)" verwende und anschließend per "uidoc.GotoField"... das Feld anspringe, habe ich zwar den Fokus auf dem Dokument - und auf dem Feld - der Cursor wird aber nicht auf das Feld gesetzt. sodaß ich mir das ganze Spiel wohl abschminken kann. Scheint mir ein echter Notes-Bug zu sein. Funktioniert im 7.0.3-Client auch nicht.

Trotzdem Vielen Dank an alle...

Gruß Ralf

Diali: Wenn ich das mache bekomme ich: "Zielrahmen ist Vorläufer des Scriptobjekts" - Ich habe auch versucht die Rahmen-Eigenschaft der Maske zu deaktivieren und per ws.OpenFrameSet resp. ws.SetTargetFrame zu umgehen - klappt auch nicht...

taurec: direkt nach dem ws.EditDocument(True, doc). Die Maske führt im Postrecalc einige Berechnungen am neuen Dokument aus, schreibt diese aber nur ins FrontEnd-Dokument (FieldSetText) ohne direkt zu speichern.

P.S.: Wenn den GotoField im Postopen o. Postrecalc der Form ausführen will, bekomme ich "Variant does not contain an object".

Hallo zusammen,

ich habe folgendes Problem:

Ich erstelle ein neues Dokument per Script (ws.EditDocument....). Die Form für dieses Dokument wird in einer (7-teiligen) Rahmengrupe geöffnet, welche beim Erstellen des Dokumentes durch die Form angezogen wird (Eigenschaft der Form gesetzt). Ich möchte beim Öffnen des Dokumentes den Fokos auf ein bestimmtes Feld setzen (uidoc.GotoField....). Ich bekomme aber die Fehlermeldung "Document command is not available". Meines Erachtens liegt das daran, daß der Fokus beim Öffnen der Rahmengruppe auf einem anderen Rahmen liegt und das Dokument nicht "gesehen" wird. Folgende Bedingungen sind gegeben:
In der Rahmengruppe ist für den betreffenden Rahmen die Eigenschaft "Anfänglichen Fokus setzen" aktiviert - für alle anderen Rahmen deaktiviert.
Das Feld, daß ich "anspringen" will ist bearbeitbar
Das neue Dokument wird nicht automatisch gespeichert.
Es erhält immer ein bestimmter Rahmen den Fokus - leider der falsche. Für die Seite, die in diesem Rahmen angezeigt wird, ist die Option "kein anfänglicher Fokus" gesetzt, ansonsten enthält die Seite keinerlei Felder, Scripte o. ä.

Kann mir jemand helfen???

Du könntest auch über ein neues Session-Objekt den DocumentContext auslesen und hast dann das doppelt geklichte Dokument voll im Zugriff...

2:00 Uhr: Hab's gefunden - glaub' ich zumindest
Das Problem ist folgendes:
Wenn ich w. o. beschrieben eine Kopfzeile in eine Maske einfüge, verhält sich die Option "Felder bei Schlüsselwortänderung aktualisieren" bei z. B. einer Dialogliste anders als wenn ich keine Kopfzeile in der Maske habe. Im ersten Fall scheint es so zu sein, das alle Felder im UI-Document wirklich neu berechnet werden. Im zweiten Fall - also mit Kopfzeile - werden offensicht stumpf die Werte aus dem BE-Document hochgeladen. Sehr subtil...
Das bedeutet wohl, das ich dieses Feature (!?) zwar benutzen kann, aber sehr vorsichtig mit meine Dialog-Feldern etc. sein muss. Die o. g. Option ist übrigens - kleiner Trost - standardmäßig nicht aktiviert, zumindest nicht in meinem 6.0.1-Client.
So, jetzt aber gute Nacht allerseits................................

Was die Kopfzeile betrifft: Man kann für eine Maske eine Kopfzeile definieren, dafür gibt's in der Property-Box einen extra Karteireiter. Im späteren Dokument wird diese Kopfzeile dann fix im Dokument verankert, soll heißen: wenn das Dokument etwas umfangreicher ist, kann ich nach unter scrollen und die Kopfzeile bleibt steh'n. Das ist eigentlich ein sehr schönes Feature, wenn ich nicht diese Probleme mit der Feldberechnung hätte.
Es muss nicht mal eine Formel sein. Wenn z.B eine Dialogliste erstelle und dort eine fixe Auswahl hinterlege kann ich den Feldwert nicht ändern. Es scheint so als würde das UI-Document immer wieder automatisch aus dem BE-Document refresht.

Hallo zusammen,

ich habe über die Property-Box einer Maske eine Kopfzeile für verschiedene Zwecke eingefügt. Leider werden jetzt in den Dokumenten keine formelbasierten Feldberechnungen ausgeführt, so das dieses Feature kaum zu gebrauchen ist. Ich hatte dieses Problem vor einigen Jahren schon mit R5. Kennst vielleicht irgend jemand eine Lösung, dieses Problem zu umgehen?

Hallo Becksy,

ich bin zwar nicht sicher ob ich das wirklich richtig verstanden habe, aber ich versuch's mal...

Du willst deinen Anwendern in einer Auswahlliste(?) verschiedene fest vorgegebene Werte anbieten. Neue Werte sollen nur von bestimmten Anwendern einstellbar sein. Diese neuen Werte sollen anschließend von allen Anwendern auswählbar sein, richtig?
Um diese Werte zu speichern hast du dir ein (oder mehrere?) Notes-Dokumente erstellt, die über @DBColumn ansprichst und editierbar machst, so der Anwender denn über die richtige Rolle verfügt.

Wenn das halbwegs richtig ist würde ich folgendes vorschlagen:

Für solche Zwecke bieten sich Profil-Dokumente an. Diese sind "direkt" addressierbar, d. h. du sparst dir die Ansicht, und sie brauchen in der Verwaltung der übrigen Ansichten nicht berücksichtigt werden (s. @Command([EditProfile]...))
Das Verbergen des "Admin"-Button kannst du doch auch über die Hide-When-Formel des Buttons regeln. Auch der Agent muss nicht sein...

Ich hoffe es hilft dir etwas weiter...