Da VB .NET nicht den Umgang mit Pointern im "herkömmlichen" Sinne unterstützt, dachte ich mir, ich veröffentliche hier mal mein kleines Workaround.
Wahrscheinlich werden die Meisten hier diesen Weg schon ewig anwenden, aber aus eigener Erfahrung weiss ich, dass man als Neulin an diesem Problem verzweifeln kann.

Code :

1 2 3

Public Function getPointerTo(ByRef obj As Object) As Object         Return obj     End Function

Da in VB .NET Call-by-Reference über das Schlüsselwort ByRef vor dem Parameter realisiert wird, kann man sich auf diese Weise den Pointer zu einem Objekt holen.

Gearbeitet werden kann damit dann ganz normal über

Code :

1	getPointerTo(myBeautifulObject).beautifulMemberFunction()

ACHTUNG: In VS funktioniert an dieser Stelle das Intellisense nicht, also vorsicht vor Tippfehlern. Sonst fliegt euch zur Laufzeit euer Programm um die Ohren.

Ich hoffe, ich konnte einigen Neulingen den Einstieg in VB .NET erleichtern.

mfg LuigiEd

Mal eine ganz dumme Frage: Aber wo liegt jetzt genau der Unterschied zwischen

Code vb:

1	getPointerTo(myBeautifulObject).beautifulMemberFunction()

und

Code vb:

1	beautifulMemberFunction.beautifulMemberFunction()

Soweit ich mich in VB auskenne müsste doch beautifulMemberFunction auch schon eine Referenz sein?

Das ist...Schmarrn. Die Funktion castet lediglich das Objekt (vom Typ X) in den Typ 'Object'. Das geht auch direkt mittels CType

Code vbnet:

1	CType(myBeautifulObject, Object)

Aber ich sehe spontan keinen Grund, warum man diesen Typecast häufig brauchen könnte. Mit Pointern hat das übrigens nichts zu tun.

Dass IntelliSense nicht funktioniert ist logisch, da IntelliSense nur ein 'Object' sieht und entsprechend nur die 'Object'-Methoden anzeigen kann.

Ok, das gewählte Beispiel ist vlt. nicht sonderlich sinnvoll, aber es gibt Fälle, wo man einfach eine Referenz benötigt. Gerade bei Oberflächenprogrammierung habe ich das jetzt öfters benötigt.

Ich habe eine Treeview die ich vorher dynamisch gefüllt hatte und deren Tag-Element ich ein Objekt zugewiesen habe. Beim Doppelklick auf ein é Node wird das Objekt in einer Variable zwischen gespeichert und beim anschließenden Doppelklick auf eine andere Node, wird dem ersten Objekt die ID des 2. und umgekehrt an eine Memberfunktion übergeben.

Ohne Referenz würde ich jetzt nur zwar dem zweiten Objekt die ID des 1. übergeben, nicht aber umgekehrt, da lediglich die Funktion des zwischengespeicherten Objektes (also der Kopie) aufgerufen wird und nicht die Funktion des Originalobjektes.

Das fällt dann beim Speichern der Daten auf.

Ich habe auch keine Lust jedes Mal die Treeview rekursiv durchzuwursten, bis ich das Originalobjekt gefunden habe und das mit der geänderten Kopie überschreiben kann.

Ich finde spontan, dass meine Lösung fixer ist.

mfg

PS: Sorry, wegen dem dämlichen Beispiel, aber ich war tippfaul.

Ich arbeite zwar hautsächlich mit c#, aber ich bin mir ziemlich sicher das auch in VB.net (mit Ausnahme von Primitiven Datentypen) alle Objekte immer Referencen sind. Somit müsstest du von einem TreeNode auch immer eine Reference bekommen und keine Kopie.

Einfaches Beispiel:

Code vb:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Sub Main()           Dim a As TreeNode         Dim b As TreeNode           a = New TreeNode         a.Tag = 5         MsgBox(a.Tag)         b = a         a.Tag = 9           MsgBox(a.Tag)         MsgBox(b.Tag)       End Sub

Die Ausgaben hier sind 5, dann 9 und nochmals 9. Hier sieht man sehr schön das b nur eine Referenze auf a ist und der Wert von b.x somit mitgeändert wird.

Öhm, wenn du dir da sicher bist, glaube ich dir das und sag mal "mein Fehler". Mich wundert allerdings, dass es nach deiner Variante bei mir nicht funktioniert hat. Und nach meiner wurde der Wert geändert. Ich bin mir auch sicher, dass ich nix anderes geändert hatte. Komisch

Steiner_B hat Recht! .NET ist komplett objektorientiert und alle Reference-Types werden, wie der Name schon sagt, auch als Referenz übergeben.
Einzig Value-Types werden als Wert übergeben. Dazu zählen Structs, Build-in-Typen, alle Benutzertypen, die von System.ValueType erben und string (Mischling, liegt zwar auf dem Heap, wird aber ByVal übergeben)