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

  • Frage

  • 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

    Mittwoch, 8. November 2017 09:21

Alle Antworten

  • 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.

    Donnerstag, 9. November 2017 09:59
    Moderator
  • 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

    Donnerstag, 9. November 2017 15:08
  • Hallo Werner,
    Schau mal ob Du eine Nested Klasse / Inner Klasse  hinbekommst.
    Und wenn ja ob das etwas nutzt.

    Grüße Alexander

    Donnerstag, 9. November 2017 16:36
  • 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

    Montag, 13. November 2017 05:52
  • 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

    Montag, 13. November 2017 06:06
  • 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

    Montag, 13. November 2017 06:27