ViewName ausgeben

[Heinrich]

Hi Programmierer,
habe ein kleines Problem.
In einem Navigator, über eine Schaltfläche möchte ich gerne den Namen der aktuell geöffneten Ansicht ausgeben.

Habe folgenden Script in der Schaltfläche hinterlegt:

Sub Click(Source As Navigator)
   Dim workspace As New NotesUIWorkspace
   Dim view As NotesUIView
   Set view = workspace.CurrentView
   Messagebox view.ViewName
End Sub


Leider wird die Fehlermeldung: "Object variable not set" ausgegeben.
Wo liegt denn der Fehler? 

[Glombi]

Hallo Heinrich, willkommen im Forum!

Hast Du das mal mit durch den Debugger gejagt.

Navigator, brrrrrr graus 
Vielleicht gibt es gar keine CurrentView !

Andreas

[Heinrich]

Sie Ansicht "Kunden" wird mit dem Navigator geöffnet.

[Glombi]

Geh doch mal Schritt für Schritt mit dem Debugger durch die Formel und poste, wo er dann hängen bleibt.

Andreas

[koehlerbv]

Wenn das eine Schaltfläche im Navigator ist, dann kann das auch nicht funktionieren, da dann der Fokus auf dem Navigator resp. der Schaltfläche ist.

Ändere mal den Code wie folgt, um das zu verifizieren, Heinrich:

Code

Sub Click(Source As Navigator)
   Dim workspace As New NotesUIWorkspace
   Dim view As NotesUIView
   Set view = workspace.CurrentView
   If view Is Nothing Then
      Messagebox "View not instantiated !"
   Else
      Messagebox view.ViewName
   End If
End Sub

Wozu soll das eigentlich gut sein ? Schaltfläche und ViewName anzeigen ? Warum Navigator anstatt Page / Outline ? Vielleicht findet sich ja eine ganz andere Lösung ?

Und: Willkommen im Forum, Heinrich !

Bernhard

[Heinrich]

Danke, für die schnellen Antworten. Ist wirklich super das schnelle Feedback.

@Bernhard
Mit Deinem Script wird die Meldung "View not instandiiated" ausgegeben.

@Glombi
Bei meinem Script meckert der Debugger bei der msgbox mit der o.g. Fehlermeldung

[koehlerbv]

Die Ausgabe der Massagekiste war logisch. Aber zurück zu meiner Frage: Wozu das ganze usw. ? Siehe oben.

Bernhard

[Thomas Schulte]

Hast du das Objekt view denn schon mal mit dem Debugger überprüft. Wetten das das nicht instanziiert ist. Und warscheinlich hast du den Navigator auch noch in einem Frame untergebracht. Wie soll er denn wissen wo im UIBereich er gerade ist. Für den Geschmack des Clients auf jeden Fall nicht in einer View und damit liefert dir diese Abfrage, auch wenn sie syntaktisch korrekt ist und die richtigen Klassen benutzt kein Ergebnis. Bau dir das zum Bleistift in eine Aktion in der Ansicht ein und du wirst sehen das es funktioniert.

Das haben dir die anderen beiden schon geschrieben aber löschen will ich das jetzt auch nicht mehr

[Heinrich]

Ist nur ein Teil eines Scriptes.
Hintergrund: Der User ruft über eine Schaltfläche eine Ansicht auf z. B. KundenNachName. Über diese werden mehrere Aktionen ausgeführt und darüberhinaus wird eine zweite Ansicht geöffnet. Zum Schluss sollte aber wieder die zuerst gewählte Ansicht geöffnet werden.
Deshalb brauche ich den aktuellen Ansichtsnamen in einer Variable. Und das ganze über eine Schaltfläche in einem Navi.

[Thomas Schulte]

Wenn das im Client ist dann nimm die Notes.ini,. gib dem Teil einen Feldnamen. Schreib das in die Ini rein und hol es nach dem Ende der Aktion wieder raus und lösch es anschließend.
Im Web wäre das ein ganz anderes Kapitel aber so dürfte das ganz einfach und ohne Kopfschmerzen gehen.

[Semeaphoros]

Aber unbedingt zwecks Verhinderung des Zumüllens der Notes.ini am Schluss den Eintrag wieder löschen, oder doch lieber ein Profildok dafür nehmen.

Und natürlich, Heinrich, willkommen im Forum

[Thomas Schulte]

wieder löschen

Sag ich doch, aber Profildokumente haben so ihre Tücken speziell in dem Fall den man denke ich hier als Gegeben annehmen muss.

[Semeaphoros]

Hier haben Profildokumente überhaupt keine Tücken, da sie ja in der gleichen Sitzung wieder gebraucht werden, wie sie gesetzt wurden, damit geht das alles über Memory und sind klar im Vorteil gegenüber der Notes.ini

[koehlerbv]

Jo, solange das ProfileDoc personenbezogen sind, sind sie gegenüber der NOTES.INI erste Wahl und völlig problemlos (da sie ja eh immer - ggf. sogar komplett, falls "Schwund" eintritt - neu aufgebaut werden, wenn sie benötigt werden).

Bernhard

[Semeaphoros]

Da es in dieser Situation sogar implizit personenbezogen ist, ist es noch nicht einmal erforderlich, das Profil-Doc explizit personenbezogen zu erstellen, womit auch gleich verhindert wird, dass unnötig Profil-Dokumente liegen bleiben.

[Thomas Schulte]

Stimmt ihr habt recht. Wenn man das genau liest dann passiert da wirklich alles im Spieicher und damit sind Profildokumente verwendbar.

[Marinero Atlántico]

Hervorhebungen von mir:

Der [einzelne] User ruft über eine Schaltfläche eine Ansicht auf z. B. KundenNachName. Über diese werden mehrere Aktionen ausgeführt und darüberhinaus wird eine zweite Ansicht geöffnet. Zum Schluss sollte aber wieder die zuerst [von dem einzelnen User] gewählte Ansicht geöffnet werden.

ist es noch nicht einmal erforderlich, das Profil-Doc explizit personenbezogen zu erstellen

Jens, das verstehe ich nicht.
Das Datum "vonUserZuerstGewaehlteAnsicht" ist eindeutig personenbezogen. Also benötigt man personenbezogene Profildokumente. 

[Semeaphoros]

Benötigt keine personenbezogenen Profildokumente, da die Angabe nur solange Sinn macht, wie die Sitzung noch existiert, und während der Sitzung wechselt der Benutzer nicht. Nach der Sitzung kannst Du die gespeicherte Info wegwerfen, spielt also keine Rolle mehr, was da noch im Profildoc drinsteht, wird eh bei einer neuen Sitzung überschrieben

[Marinero Atlántico]

und während der Sitzung wechselt der Benutzer nicht.

ok. Ich bin z.Zt. ein bischen object relational mapping infiziert, deshalb:

Nicht user-gebundene Profildokumente besitzen eine 1 zu 1 Beziehung zur Datenbank.
User besitzen (normalerweise) eine n zu 1 Beziehung zur Datenbank.

User 1 wählt seine 1. Ansicht und das Telefon klingelt.
AnsichtUser1 wird in das ProfilDokument geschrieben. 
User 2 wählt seine Ansicht
AnsichtUser2 wird in das ProfilDokument geschrieben.
User1 legt den Höhrer auf und arbeitet weiter.
Eigentlich müßte User1 nun AnsichtUser2 sehen, wenn er seine erste Ansicht aus dem Profildokument holt.

Das könnte funktionieren, wenn der cache von Profildokumenten tatsächlich user-session-gebunden wäre. Und wie lange werden die an die UserSession gebundenen Daten im Speicher gehalten? Was ist, wenn er Essen geht. Vielleicht werden die an die UserSession gebundenen Daten nach 30 Minuten gelöscht. Oder vielleicht findet manchmal doch ein Durchgriff auf das Profildokument statt. 
Weisst du sicher, dass das stabil funktioniert? Selbst dann wäre es ein hack. Die genaue Funktionalität des caches ist nicht dokumentiert (userSession-bezogen? wann und überhaupt wird der cache gelöscht?

Gruß Axel
 

[Semeaphoros]

Genau das ist es ja, was sonst das Problem macht, was man hier ausnutzen kann: Profildokumente werden nur aus dem Memory bedient, wenn sie mal geladen sind, der Cache ist auch kein write-through, wird also nicht sofort zurückgeschrieben. Man kann hier genau das nutzen, was sonst den Entwicklern so sehr Bauchweh macht (weil sie damit nicht rechnen und deshalb dieses Verhalten nicht gewohnt sind)