gemeinsamer Programmcode für (nicht erbbare) COM-Klassen-Objekte

Question

Hallo alle miteinander,

der Titel verrät ganz sicher nicht, was ich suche...

Ich erstelle mit VB.NET unter Visual Studio 2013 eine DLL, die in COM-Programmen, bspw. in Word-Macros, verwendet werden soll.

Da in COM-Schnittstellen leider keine Vererbung übernommen wird (werden kann), habe ich verschiedene Klassen erstellt, die intern Objekte mit Vererbungsstrukturen instanziieren (können). Solche internen Objekte haben oftmals identische Eigenschaften, bspw. ErrorMessage, ErrorCategory u.ä., die ich nach dem Instanziieren in Eigenschaften der COM-Schnittstellen übernehmen möchte und zwar, da ich den Programmcode dafür ja nicht in einer vererbbaren Klasse unterbringen kann (s.o.), als statischer Programmcode einer weiteren COM-Klasse, auf die alle solcher COM-Schnittstellen Zugriff haben.

Leider fällt mir beim besten Willen keine Möglichkeit ein, diesem Programmcode der weiteren COM-Klasse begreiflich zu machen, an welches Objekt welcher Klasse diese Eigenschaften zu übergeben sind.

Lange Rede kurzer Sinn:

Ich habe zwei Klassen mit solchen internen Objekten, bspw.

Public Class COMA
...
Public Sub Open(index as Integer)
  Me.Bericht = New A(index)
  Me.ErrorCategory = Me.Bericht.ErrorCategory
  Me.ErrorMessage = Me.Bericht.ErrorMessage
End Sub
...
End Class

Public Class COMB
...
Public Sub Open(index as Integer)
  Me.Bericht = New B(index)
  Me.ErrorCategory = Me.Bericht.ErrorCategory
  Me.ErrorMessage = Me.Bericht.ErrorMessage
End Sub
...
End Class

Wenn ich jetzt die Zeilen

Me.ErrorCategory = Me.Bericht.ErrorCategory
Me.ErrorMessage = Me.Bericht.ErrorMessage

in eine statische Programmklasse übernehmen würde, könnte ich sie sowohl von COMA als auch von COMB aufrufen. Schöner wäre natürlich, diesen Code in einer übergeordneten Klasse vererbbar anzuordnen. Aber das geht ja eben leider nicht.

Leider weiß die statische Programmklasse nicht, an welches Objekt welcher Klasse die Eigenschaften zu übergeben sind.

Meine Idee war folgende Routine in der statischen Programmklasse:

Public Sub GetObjectDates(COMObject As Object)
  Dim referenceObject As Object
  If TypeOf COMObject Is COMA Then referenceObject = DirectCast(COMObject, COMA)
  With referenceObject 
      .ErrorMessage = .Bericht.ErrorMessage
      .ErrorCategory = .Bericht.ErrorCategory
  End With
End Sub

Aber Option Strict On lässt spätes Binden nicht zu. Zwar ginge

With DirectCast(COMObject, COMA)
  ...

Dann müsste ich aber den Code auch nochmals schreiben für

With DirectCast(COMObject, COMB)
  ...

Dann kann ich den Code auch gleich mehrfach belassen in den COM-Klassen. Ohne Vererbung tue ich mich sehr schwer.

Aber ich habe das Gefühl, dass es irgendwie gehen müsste. Kann mir jemand das Gefühl mit einem konkreten Tipp untersetzen

.... oder nehmen....

Gruß, Werner

---

WM

Answer 1

Hallo Werner,

Hast Du die dll selbst entwickelt oder sie geliefert bekommen? Kommt für Dich im ersteren Falle eine Klasse anstatt einer der Schnittstellen in Betracht, um sie zu vererben? Schau mal, ob Dir CType anstatt DirectCast bei der Typumwandlung behilflich sein kann.

Gruß,
Dimitar

---

Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.

Answer 2

Hallo Dimitar,

danke für Deinen Hinweis. Ja, ich entwickele die DLL selbst. Und ich denke, dass ich CType auch schon versucht bzw. darüber nachgedacht hatte. Ebenfalls ohne Erfolg. Allerdings weiß ich nicht mehr wieso und ob überhaupt.

Ich werde aber noch einmal darüber nachdenken und gebe Dir morgen Bescheid.

Gruß, Werner

---

WM

Answer 3

Hallo Werner,
Schau mal ob Du eine Nested Klasse / Inner Klasse  hinbekommst.
Und wenn ja ob das etwas nutzt.

Grüße Alexander

Answer 4

Guten Morgen Dimitar,

nochmals danke für Deinen Hinweis.

Ich hatte noch einmal darüber nachgedacht und es auch im Code umgesetzt. Aber natürlich ist CType auch spätes Binden, so dass dies auch nicht funktioniert.

Eine Klasse statt einer Schnittstelle käme für mich natürlich in Frage. Allerdings sehe ich nicht, worauf Du damit hinaus willst bzw. was damit für eine Realisierung möglich wäre.

Gruß, Werner

---

WM

Answer 5

Guten Morgen Alexander,

und danke für Deine Anregung.

Ich habe darüber nachgedacht, aber keine Lösungsmöglichkeit erkannt und das aus folgenden Gründen:

Es gäbe ja in einem solchen Fall aus meiner Sicht nur die Möglichkeiten,

1. GetObjectDates als Funktion einer Klasse zu definieren, die auch die Klassen COMA und COMB als Nested Class enthält bzw.

2. GetObjectDates in jeweils einer Nested Class der Klassen COMA und COMB zu definieren.

1. entfällt aber deshalb, weil ich dann ja alle Eigenschaften aus den Klassen COMA und COMB (und COMC und ...)  in die Klasse übertragen müsste, die diese Klassen und GetObjectDates enthält, da ich in VBA nicht direkt auf Eigenschaften einer Nested Class zugreifen kann und außerdem den Nutzern dieser Schnittstelle Zugriff auf oberster Ebene gestatten möchte. Damit enthielt eine Klasse Eigenschaften verschiedenster (nested) Klassen, die miteinander überhaupt nichts zu tun hätten und das Klassenkonzept parodieren würden.

2. entfällt deshalb, weil es prinzipiell nichts anderes als gegenwärtig ohnehin realisiert ist, nämlich, dass jede Klasse den Code enthält, den ich eigentlich auslagern möchte.

Dein Hinweis bringt mich also leider nicht voran.

Gruß, Werner

---

WM

Answer 6

Noch einmal guten Morgen Alexander,

da "ich in VBA nicht direkt auf Eigenschaften einer Nested Class zugreifen kann" falsch interpretiert werden könnte:

Natürlich kann ich auf Eigenschaften einer Nested Class in VBA zugreifen, allerdings ebenfalls nur lesend, schreibend aber nicht auf alle Typen.

Womit ich aber eigentlich schon bei meinem nächsten Problem wäre, was darin besteht, dass ich ein Byte-Array, in VB.NET definiert als

Public Property Blb As Byte()

zwar in VBA lesen kann in ein Array, definiert als

Dim Blb() As Byte

aber leider nicht zurückschreiben, obwohl die Typen, mit TypeName() in VBA, ermittelt, identisch sind und der Setter in VB.NET auch Public definiert wurde.

Aber dieses Problem werde ich gleich in einem extra Thread zur Diskussion stellen.

Gruß, Werner

---

WM