LZF 430 oder wieso ist die DLL nicht kompatibel

11/02/2010 - 23:08 von Reiner Wolff | Report spam
Moin moin,

der Laufzeitfehler 430 'Klasse unterstützt keine Automatisierung oder die
erwartete Schnittstelle nicht' macht mich noch wahnsinnig. ;-)

Ich habe eine DLL, mit der ich ein Steuerelement (FlexGrid von
ComponentOne) um Funktionalitàten erweitere. Seit einiger Zeit tritt der
LZF 430 vermehrt auf. Schön daran ist, ich kann den Fehler reproduzieren:
- DLL neu erstellen (Version wird hochgesetzt)
- Programm-Exe mit Verweis auf DLL erstellen
- Setup packen, ausliefern und installieren
-> keine Probleme alles funktioniert wie es soll

- DLL neu erstellen (Version wird erneut hochgesetzt)
- Setup packen, ausliefern und installieren
-> LZF 430 beim Aufruf der Erweiterungskomponente.

Das klingt für mich erstmal danach, dass die DLL zu ihrem Vorgànger nicht
kompatibel bleibt und deswegen von der EXE "abgewiesen" wird.
Stelle ich die DLL auf 'keine Kompatibilitàt', erstelle eine DLL, stelle
danach um auf 'Binàrkompatibilitàt', gebe die gerade erstellte DLL zum
Vergleich an und erstelle direkt wieder eine neue DLL, bekomme ich die
Meldung, dass die Schnittstelle nicht gleich sei:













Ursprüngler Code lautete:
Public wwGrid As Object

neuer Code lautet:
Public wwGrid As VSFlex8.C1Grid
<<<<
(die genaue Klassenbezeichnung habe ich gerade nicht im Kopf.)

Nun, am Code habe ich wàhrend der beiden Kompilierungsvorgànge nichts
geàndert. Die Deklaration lautet eigentlich so:
Public WithEvents wwGrid As VSFlex8.C1Grid

Ich vestehe den Verlust der Kompatibilitàt nicht und schaffe es derzeit
auch nicht, die wieder herzustellen.
Da ich diese DLL in diversen Projekten benutze, bin ich im Prinzip auf die
Kompatibilitàt angewiesen.
Mir kommt es fast so vor, als ob mir irgendein Patch für VB6 fehlt.
Vielleicht ist auch einfach nur irgendeine Einstellung falsch.

Hat hier jemand eine Idee, wodran das Verhalten liegen könnte und wie ich
es beheben kann?

Schonmal vielen Dank für's Lesen.

Gruß aus Kiel
Reiner
Ein Programm sollte nicht nur Hand und Fuss,
sondern auch Herz und Hirn haben.
(Michael Anton)
 

Lesen sie die antworten

#1 Dieter Strassner
12/02/2010 - 10:43 | Warnen spam
Hallo Reiner,

der Laufzeitfehler 430 'Klasse unterstützt keine Automatisierung oder
die erwartete Schnittstelle nicht' macht mich noch wahnsinnig. ;-)

Ich habe eine DLL, mit der ich ein Steuerelement (FlexGrid von
ComponentOne) um Funktionalitàten erweitere. Seit einiger Zeit tritt
der LZF 430 vermehrt auf. Schön daran ist, ich kann den Fehler
reproduzieren:
- DLL neu erstellen (Version wird hochgesetzt)
- Programm-Exe mit Verweis auf DLL erstellen
- Setup packen, ausliefern und installieren
-> keine Probleme alles funktioniert wie es soll

- DLL neu erstellen (Version wird erneut hochgesetzt)
- Setup packen, ausliefern und installieren
-> LZF 430 beim Aufruf der Erweiterungskomponente.

Das klingt für mich erstmal danach, dass die DLL zu ihrem Vorgànger
nicht kompatibel bleibt und deswegen von der EXE "abgewiesen" wird.
Stelle ich die DLL auf 'keine Kompatibilitàt', erstelle eine DLL,
stelle danach um auf 'Binàrkompatibilitàt', gebe die gerade erstellte
DLL zum Vergleich an und erstelle direkt wieder eine neue DLL,
bekomme ich die Meldung, dass die Schnittstelle nicht gleich sei:









Ursprüngler Code lautete:
Public wwGrid As Object

neuer Code lautet:
Public wwGrid As VSFlex8.C1Grid
<<<<
(die genaue Klassenbezeichnung habe ich gerade nicht im Kopf.)

Nun, am Code habe ich wàhrend der beiden Kompilierungsvorgànge nichts
geàndert. Die Deklaration lautet eigentlich so:
Public WithEvents wwGrid As VSFlex8.C1Grid

Ich vestehe den Verlust der Kompatibilitàt nicht und schaffe es
derzeit auch nicht, die wieder herzustellen.
Da ich diese DLL in diversen Projekten benutze, bin ich im Prinzip
auf die Kompatibilitàt angewiesen.
Mir kommt es fast so vor, als ob mir irgendein Patch für VB6 fehlt.
Vielleicht ist auch einfach nur irgendeine Einstellung falsch.

Hat hier jemand eine Idee, wodran das Verhalten liegen könnte und wie
ich es beheben kann?



exakt mit dem gleichen Problem schalge ich mich schon seit einigen
VB6-Jahren herum.
Meine einfachste Lösung dazu: Von innen nach außen übersetzen (von der DLL
bis zur EXE)

Meine praxiserprobte Lösung ist allerdings komplizierter:
Arbeite mit (fast) leeren EXE-Hüllen, die über mitteks Olafs Classfaktory
(ComDirect.dll und dh_CtlLoader ) die unregisterierten DLL/OCX. dadurch kann
ein einfaches Update ohne SETUP, ohne besondere Benutzerrechte ausgeführt
werden.


Viele Grüße

Dieter


Rückfragen bitte nur in die Newsgroup!

EDV-Kommunikation Strassner e.K.
68623 Lampertheim
Internet: www.strassner.biz

Ähnliche fragen