DokumentObjekt als Funktionsrückgabewert?!

[samWare]

Hallo Leute,

ich hab gerade eben was Probiert, sieht ungefähr so aus:

Code

Funktion get_doc() as NotesDocument
...BLABLA...
Dim vw As NotesView
...View holen usw, usw...

'DokumentObjekt zurückgeben
Set get_doc = vw.GetFirstDocument

End Function

Nutzen wollte ich das ganze dann wiefolgt:

Code

....BLABLABLA....
Dim doc As NotesDocument
...BLABLABLA....

Set doc = get_doc()

Funktioniert leider nicht. Ihr werdet mir bestimmt auch sofort sagen können warum Ich würde die Sache sehr toll finden, da ich bisher immer nur Integers, Strings und weis der Geier was zurückgegeben habe, und docObjects immer nur per ÜbergabeWert verändert // gesetzt habe.

Ich wär echt glücklich wenn das so auf die Art und Weise irgendwie Funktionieren könnte..

mfg Samuel

Edit: Der Debugger zeigt mir in der get_doc() Funktion am Ende an dass er get_doc auf das Dokument gesetzt hat. Das scheint also zu Funktionieren. Ich kriege dann nur das "doc"Objekt im unteren Code nicht gesetzt...

[dirk_2909]

..weil Du dasd BackendDoc über die View holst.
Das View Handle ist aber nur in der externen Funktion verfügbar. In der aufrufenden Methode ist das View-Object nicht verfügbar und somit auch nicht seine Unterobjekte.

Wenn, dann musst Du die View (und auch die db) global deklarieren.

[samWare]

Würde das auch auf eine andere Art und Weiße funktionieren? Kann mir grad nicht vorstellen wie das klappen soll, da beide Funktionen später in verschiedenen LS_Libs liegen würden. Kann man das überhaupt auf die Art ordentlich lösen oder muss ich das per ÜbergabeObjekt lösen?

[BigWim]

Dann muss Du Deiner Funktion die View mitgeben.

Also in etwa so:

function Get_doc (tmpView as view) as NotesDocument

Set Get_doc=tmpView.GetFirstDocument
End Function

Stichwort "objektorientiertes Denken"
Aber, wie gesagt, man kann sich da sehr leicht "verschachteln" (war sehr lehrreich)

Markus

[samWare]

Also doch mit ÜbergabeObjekt.. neiiin! Schrecklich! Ich wollte das nutzen um ein KonfigurationsDokument aus einer externen DB zu laden. Da spar ich mir ja nicht viel wenn ich das über diese Methode löse...

Dann wär aber das noch das schlauste:

Code

Dim tmpdoc As NotesDocument

Call get_doc(tmpdoc)

Code

Function get_doc(tmpdoc As NotesDocument)
....
Dim vw As NotesView
....
Set doc = vw.GetFirstDocument

Nur blöd dass "tmpdoc" immer "tmpdoc" heißen muss...

[MadMetzger]

Hm... Was ist, wenn du das Dokument danach noch mal neu über die vorher beschaffte UNID erzeugst?

[samWare]

Klasse Idee! An UNID denk ich natürlich wieder nicht.. danke dir Markus!

[ascabg]

Also dieser kleine Code tut bei mir genau das gewuenschte.

Code

Sub Initialize
	Dim ses As New NotesSession
	Dim db As NotesDatabase
	Dim doc As NotesDocument
	
	Set db = ses.CurrentDatabase
	If db.IsOpen Then
		Call GetDoc(doc)
		If doc Is Nothing Then Msgbox "Nothing" Else Msgbox "immer noch da"
	End If
End Sub

Sub GetDoc(doc As NotesDocument)
	Dim s As New NotesSession
	Dim db1 As NotesDatabase
	Dim vw As NotesView
	
	Set db1 = s.CurrentDatabase
	If db1.isopen Then
		Set vw = db1.GetView("alldoc")
		If Not (vw Is Nothing) Then
			Set doc = vw.GetFirstDocument
		End If
	End If
End Sub

Andreas

[samWare]

Hallo Andreas,

die Methode habe ich ja bereits gepostet. Leider mit nur mäßigem Erfolg.

In der Call Funktion, befinde ich mich in DB-1. Das Configdoc liegt allerdings in DB-2.

mit "Call get_doc(doc)" übergebe ich ein leeres Dokument (nur Deklariert noch nicht initialisiert). Dieses setze ich dann in der "get_doc()" Funktion.

"get_doc" Intern funktioniert das, das "doc" bleibt in der Call Funktion aber trozdem un-initialisiert. Ich kapier das nicht.

hierzu mal ein wenig Code:

Code

Function environment_get_config_doc(sdo As NotesDocument)
	'Funktion holt das Stammdaten-Dokument und giebt es zurück
	
	'Dimentions festlegen
	Dim s As New NotesSession
	Dim db As NotesDatabase
	Dim vw As NotesView
	
	'DB//VW initialisieren
	Set db = s.GetDatabase(environment_constants(1), environment_constants(2), False)
	Set vw = db.GetView(environment_constants(3))
	
	'Dokument-Objekt zuweisen
	Set sdo = vw.GetFirstDocument
	
End Function

Aufgerufen wird das ganze in dieser Funktion:

Code

Function environment_get_config_doc_value(itn As String, ca As Integer) As String
%REM	
	Funktion giebt den geforderten Feldwert aus den Stammdaten zurück
	itn	=> ItemName
	ca 	=> Case (im itn)
%END REM
	
	'Dimentions festlegen
	Dim sdo As NotesDocument
	Dim s As New NotesSession
	Dim db As NotesDatabase
	Dim vw As NotesView
	
	'Konfigurationsdokument holen // initialisieren
	Call environment_get_config_doc(sdo)
	
	'Wert ausgeben
	environment_get_config_doc_value = sdo.GetItemValue(itn)(ca)
End Function

Mein Call bewirkt NULL. Da wird nichts initialisiert...  

Wo ist der Fehler?!

[ascabg]

Hallo,

Dann wuerde ich sagen sieht es schlecht aus, da ja eigentlich alle benoetigten Objekte beim verlassen Deiner Funktion zum Holen des Dokumentes wieder "terminiert" werden.
(Session, db, View)

Somit wirst Du wahrscheinlich nicht umhinkommen die entsprechenden Variablen entweder global zu definieren oder als Parameter mit zu uebergeben.


Andreas

P.S.
Sollte es noch einen aderen Weg geben, ich moechte ja auch noch lernen.

[TRO]

Hm... Was ist, wenn du das Dokument danach noch mal neu über die vorher beschaffte UNID erzeugst?

Mit der NoteID (statt der UNID) wäre das noch performanter, da die NoteID quasi die "natürliche" Ordnung der Notes-Dokumente in einer DaBa darstellt. Da muss dann bei GetDocumentBy(UN)ID nicht der Weg über die interne Tabelle UNID --> NoteID gegangen werden.

Thomas

[koehlerbv]

Samuel, das geht ganz einfach auch ohne Verrenkungen und zig Objekten, die auch "aussen" vorhanden sein müssen.

Ein Beispiel:

Code

Set docTRConfigSetup = GetSetupDocumentFromOtherDB (True, dbTRConfig, "ConfigDBReplicaID", "Global Setup", "TRConfig", szErrorMessage)

docTRConfigSetup sei als Objekt vorgesehen für das Setup-Dokument der "fremden" Datenbank "TRConfig".

Die Parameter der Routine GetSetupDocumentFromOtherDB sind bis auf einen - siehe unten - der internen Verwaltung geschuldet:

Code

	' Purpose:		Retrieves a named Setup document from another database
	'------------------------------------------------------------------------------------------------------------------------------------------------------------
	' Arguments:
	'					bIsInteractive - True if called from the frontend, False otherwise
	'					dbOther - NotesDatabase object to be returned by reference because the Setup document is a "child" of dbOther
	'					szItemReplicaID - The item name in the own Setup document which contains the ReplicaID of the other database
	'					szSetupName - The type name of the Setup document to retrieve in the other database
	'					szDBTitle - The title of the other database (for possible frontend error messages)
	'					szErrorMessage - Used to return possible error messages by reference

"Kriegsentscheidend" ist also nur das Objekt "dbOther", welches vorgesehen ist für den "Vater" des Kindes "Setup-Dokument in dbOther" (wie Markus schon schrieb: Objektorientiert denken!)

Was dbOther übergeben wird, ist wurscht - Hauptsache, es ist wirklich ein NotesDatabase object.

Vor dem Aufruf der Function steht daher:
Dim dbIrgendeinName As New NotesDatabase ("", "").

Das "New Database" könnte aber auch innerhalb der Function gesetzt werden.

Ich hoffe, ich habe damit das Verfahren zum Umgang mit Vererbung und deren Übertragung halbwegs verständlich herüberbringen können.

Bernhard

[MadMetzger]

Hm... Bernhard... Ich habe gerade ein Deja-vu... Irgendwie hatten wir genau bei dem Thema die Diskussion, dass es sich bei diesen Beziehungen nicht um Vererbung handelt... In der OO würde man diese Beziehung eher Assoziation nennen. In diesen speziellen Fall könnte man sogar von Aggregation sprechen, da mit Verlust des verweisenden Objektes das abhängige Objekt mit verloren geht.

Zumindest bin ich zu Noteszeiten auch das eine oder andere Mal drauf reingefallen, dass solche Objekte "verschwinden", wenn das verweisende Objekt aus dem Fokus ist.

Um das vielleicht noch etwas aufzuhellen: Vererbung ist eine Beziehung, die man nutzt, wenn man zwei Typen gemeinsames Verhalten (Methoden) und gemeinsame Struktur (Attribute) haben. Genau das liegt hier aber nicht vor, denn ein Dokument und eine View haben eigentlich keine Gemeinsamkeiten (aus OO-Sicht).

[TRO]

und hier

http://www.bobzblog.com/tuxedoguy.nsf/dx/geek-o-terica-3-taking-out-the-garbage-lotusscript

beschreibt Bob Balaban (der Chef-Entwickler der LS-Engine) die Hintergründe für diese "verschwindenden" Objekte.


Thomas

[koehlerbv]

Jo, diese Begriffe sind natürlich korrekter: Eine "Assoziation" fällt beim Verlassen des encapsulated modules der "garbage collection" zum Opfer.

Hauptsache, man kennt diese Zusammenhänge und sorgt dafür, dass die Müllabfuhr nicht das "falsche" abräumt: NotesDatabase ist in diesem Fall für das "Überleben" des NotesDocuments essentiell. Und es für auch nur einmal im Speicher vorgehalten dank der Reference.

Bernhard

[samWare]

Ich hoffe, ich habe damit das Verfahren zum Umgang mit Vererbung und deren Übertragung halbwegs verständlich herüberbringen können.

Ja hast du. In meinem Fall hole ich das ConfigDoc einfach ohne Funktion, das sind nur 2 kleine Zeilchen mehr. Ein Mehraufwand der sich eindeutig verkraften lässt

Danke aufjeden Fall nochmal für die Anschauliche beschreibung des Vererbungsprinzips. Hilft ungemein

mfg Samuel