title image


Smiley Dann wirst du vermutlich die Kompatibilitätsregeln nicht beachtet haben...
Ich hab' da früher schon mal was getippt, das ich noch in einem verwaisen Winkel meiner Platte gespeichert hatte.



Ich hab's mal rausgekramt:





Na dann werde ich mal wieder einen meiner "berühmt/berüchtigten"

langen Beiträge tippen...





die CLSID

Jede öffentliche Klasse in einer ActiveX-Komponente bekommt eine eigene CLSID.

Das sind diese ellenlangen Zahlen-Ziffernkombinationen in geschweiften Klammern in der

Registry. Diese werden durch einen Algorithmus bestimmt, der neben der aktuellen Uhrzeit

auch noch irgendwelche eindeutigen Hardewaresachen reinwurstelt. Dadurch ist gewährleistet,

daß genau diese eben erstellte CLSID weltweit eindeutig ist.

Diese CLSID (oft auch ClassID genannt) bestimmt die eindeutige Zuordnung der Klasse zu der

dll/exe/oxc, in der sie gespeichert ist.

Wenn du zB in der Registry (HKEY_CLASSES_ROOT\CLSID) unter so einer CLSID nachkuckst, dann

ist da immer ein Schlüssel der Art InprocServer32 (oder OutprocServer) vorhanden.

Und im Standardwert dieses Schlüssels ist der Pfad zu der entsprechenden dll etc hinterlegt.

Genau das (und noch ein paar mehr) sind die Einträge, die bei der Registrierung gemacht werden.

Über diese Einträge ermittelt die exe dann welche Klasse in welcher Dll ist und wo die zu finden

ist.





die Public Schnittstelle

Unter Public-Schnittstelle (= Interface) versteht man die Klassen, Functions, Subs, Properties

und Events, die die dll für alles außerhalb bereitstellt.

Also alle Functions, Subs... die mit Public in einer Public-Klasse definiert sind.

Variablen, die mit Public definiert sind gehören auch zur Public-Schnittstelle, weil das eigentlich

Public-Properties sind, VB erstellt für diese Variablen beim kompilieren das zugehörige Get-Let-Paar.

Gemeint sind dabei nicht nur die Namen der Klassen und Funktions etc, ebenso die Anzahl, Reihenfolge

und Datentypen der Parameter und Rückgabewerte.

Public-Klassen sind alle Klassen, deren Instancing-Einstellung nicht auf Private steht.

Auch UserControls in ocx'n sind idR Public.





die COM Spezifikation

Damit gewährleistet ist, daß ein bestehendes Programm mit einer neuereren Version einer Dll oä

funktioniert, darf man nur kompatible Änderungen an der Public-Schnittstelle machen und man

muß die bestehenden CLSID's verwenden.

Wenn man inkompatible Änderungen an der Public-Schnittstelle macht, sollte man eine neue CLSID

und einen neuen Klassennamen vergeben.





die C++ Umsetzung

Programmierer, die mit C++ arbeiten (Delphi und Java weiß ich jetzt nicht), sind selbst dafür

verantwortlich, daß diese Spezifikation eingehalten wird. Dazu gibt es eine Win-API, die so eine

CLSID generiert.





die Umsetzung in VB

Einem VB-Programmierer wird die Arbeit abgenommen, VB kümmert sich um die Vergabe der CLSID.

Das hat einerseits den Vorteil, daß man sich eben nicht sonderlich darum kümmern muß, andererseits

hat das den Nachteil, daß man die Vergabe (oder Nichtvergabe) einer neuen CLSID nur bedingt steuern

kann.





Möglichkeiten des VB-Programmierers

Im folgenden verwende ich den Begriff dll stellvertretend für alle Arten von ActiveX-

Komponenten.

Im Dialog Projekteigenschaften gibt es auf dem Reiter Komponente die Möglichkeit,

festzulegen, wann eine neue CLSID generiert werden soll.

Es gibt drei verschiedene Einstellungsmöglichkeiten.

- Keine Kompatibilität: Wie der Begriff schon sagt, sind ältere Programme zu dieser Dll

   dann nicht kompatibel, es wird immer, bei jedem kompilieren eine neue CLSID verwendet.

- Projekt-Kompatibilität: Diese Einstellung ist die Standardeinstellung von VB und besagt, daß

   die CLSID innerhalb eines Projekts (eigentlich einer Projektgruppe) erhalten bleibt. Diese

   Einstellung ist dann sinnvoll, wenn man in einer Projektgruppe die Dll entwickelt und testet.

   Wenn die Dll kompiliert wird (dll-erstellen), wird immer eine neue CLSID vergeben.

- Binärkompatibilität: Das ist die sinnvollste Einstellung. Hier muß man eine bereits fertige dll

   angeben, zu der die neue Version kompatibel sein soll. Beim Erstellen eines neuen Projekts ist

   das ja noch nicht möglich, deshalb kann das nicht als Voreinstellung verwendet werden.

   Wenn die neue Version der dll kompatibel zur alten ist (die alte Public-Schnittstelle ist unverändert)

   bekommt die neue Version beim kompilieren die gleiche CLSID, ansonsten bekommt man eine Meldung,

   ob man trotzdem weitermachen will (= neue CLSID) oder nicht.





Auswirkungen

Wenn man eine exe mit einer dll ausgeliefert hat und an der dll Verbesserungen vornimmt, sollte

man darauf achten, daß die CLSID erhalten bleibt (Binärkompatibilität).



Wenn die Binärkompatibilität nicht gegeben ist, also wenn eine neue CLSID vergeben wurde,

dann muß man die dll neu registrieren und die exe neu komplieren, weil ja beim Aufnehmen

einer Referenz über Projekt->Verweise oder Projekt->Komponenten die CLSID's der entsprechenden

Klassen ins Projekt aufgenommen werden. Beim Kompilieren der exe werden diese CLSID's in die exe

reingewurstelt, damit die exe im Zielsystem eben über die Registry die Dll findet.



Wenn die Binärkompatibilität gegeben ist (keine neue CLSID), dann braucht man nur die dll austauschen,

Wenn die Public-Schnittstelle unverändert ist, ist keinerlei Registrierung oä erforderlich (vorausgesetzt

die dll kommt ins gleiche Verzeichnis wie die alte war), da sich ja an den Registrierdaten nichts geändert hat.





Eine bereits bestehende Anwendung benutzt ab sofort die neue dll, sie nutzt zwar evtl vorhandene neue

Funktionen nicht, aber die alten Funktionen sind ja nach wie vor vorhanden.





erlaubte und unerlaubte Änderungen

Die Binärkompatibilität bleibt bei folgenden Änderungen erhalten (gleiche CLSID).

- Alle Änderungen in einer Klasse, deren Instancing-Eigenschaft auf Private steht sowie Änderungen in Modulen,

   Forms etc (eine Form ist eine Private Klasse)

- Hinzufügen neuer Functions, Subs, Properties, Events zu Klassen, die nicht Private sind (*

- Änderung von Code innerhalb beliebiger Functions, Subs, Properties (auch Public)

- alle Änderungen an Functions, Subs, Properties, Events, die als Private oder Friend definiert sind

- Ändern der Instancing-Einstellung einer Klasse, die Private war (*

- Hinzufügen einer Klasse (* wenn nicht Private

Wenn mit (* gekennzeichnete Änderungen gemacht wurden, muß die dll neu registriert werden, weil dadurch die

Public-Schnittstelle erweitert wird.





Die Binärkompatibilität geht bei folgenden Änderungen verloren (neue CLSID).

- Änderungen am Funktionskopf irgendeiner als Public definierten Function, Sub, Property, Event

   in einer Klasse, deren Instancing-Eigenschaft auf nicht Private steht,

   also

   + Änderung des Funktionsnamen

   + Änderung eines Parameters

   + Änderung des Datentyps eines Parameters

   + Änderung des Datentyps eines Rückgabewerts

   + Hinzufügen oder Entfernen eines Parameters

   + Entfernen einer Funktion

- Änderung der Instancing-Eigenschaft einer Klasse, die nicht Private ist

- Entfernen einer Klasse, deren Instancing-Eigenschaft nicht Private ist



Fazit

Nachdem die dll ausgeliefert oder gründlich genug getestet ist, sofort auf Binärkompatibilität

umstellen und eben diese dll als Referenzdatei angeben.




Gruß
Gaga

___________________________________________________________________

Profilösungen für VB6
wenn nicht anders angegeben, sind alle Codebeispiele nicht getestet, nur getippt


geschrieben von

Login

E-Mail:
  

Passwort:
  

Beitrag anfügen

Symbol:
 
 
 
 
 
 
 
 
 
 
 
 
 

Überschrift: