Hi tu oll!

Das obige Problem ist ja hinreichend bekannt. Ein TFont-Objekt in einer library unterscheidet sich von einem TFont-Objekt in einem program.
Gut, nehmen wir an, ich finde micht damit ab. Kennt einer (es dürfen auch mehrere sein ) ein Workaround außer der Kompilierung mit Packages?

Jeder noch so windige Tip ist willkommen.

Schau Dir mal an, in welcher unit der entspr. TFont deklariert wurde.
Dann gehst Du z.B. hin, schreibst die entspr. unit des programmes mit in die uses deiner library. Wenn Du dann eine Variable von diesem Typ deklarieren willst, gib einfach die passende unit mit an "var test = wasweissich.TFont;"
In Delphi gibt es leider einige inkompatible doppeldeklarationen, deshalb gehe ich mal davon aus, dass es hier das gleiche ist.

Zitat von chaosben:

Das obige Problem ist ja hinreichend bekannt. Ein TFont-Objekt in einer library unterscheidet sich von einem TFont-Objekt in einem program.
Gut, nehmen wir an, ich finde micht damit ab. Kennt einer (es dürfen auch mehrere sein ) ein Workaround außer der Kompilierung mit Packages?

Du kannst als Hack wenn du sicher bist das die Compiler-Version + Compiler-Einstellungen in der Exe und DLL gleich ist mittels harten Cast (TFont(meinFontZeiger)) arbeiten, aber das wird dir nicht überall gelingen.

Einzigst richtige Lösung ist der Vergleich über ClassName:

  if Library.Font.ClassNameIs(TFont.ClassName) then mit der Hoffnung das beide Klassen, also der in der Library und des eigenen Modules, die identische Klassennamen besitzen auch die gleichen Klassenimplementierungen darstellen. Dies trifft nur dann zu wenn beides, Library und Modul mit der exakt gleichen Kopie der Sourcen kompiliert wurden.

Nimm Packages, das macht es absolut sicher.

Gruß Hagen

Oder Du benutzt das IFontDisp Interface zur Kommunikation, es wird auch von TFont unterstützt

mfG
mirage228

Danke für eure Antworten.

@negaH:

Zitat von chaosben:

Kennt einer (es dürfen auch mehrere sein Smile ) ein Workaround außer der Kompilierung mit Packages?

Es geht einfach nicht mit Packages. Unmöglich. Ausgeschlossen.

Zitat von negaH:

Einzigst richtige Lösung ist der Vergleich über ClassName:
  if Library.Font.ClassNameIs(TFont.ClassName) then

Ich komm nicht hinter den Sinn dieses Codes. Beide Objekte haben "TFont" als Classname. Was bringt mir dann ein Vergleich?

Hast Du denn auch schonmal nachgeschaut, WO die jeweiligen TFont deklariert wurden (welche unit)? DA dürfte der Hund begraben liegen, denn TFont kann <> TFont sein...

Ja, meines erachtens kommen beide aus der Unit "Graphics". In einem der vielen Threads in Google.Groups stand aber, das der Hase angeblich bei "TPersistent" im Pfeffer liegt. Aber ich werde das in der nächsten Stunde genauer untersuchen. Wenn ich also bis 14.00 Uhr keine weiteren Lebenszeichen von mir gebe, hab ich mich wahrscheinlicht mit einem Pointer erdrosselt.

Zitat:

Ich komm nicht hinter den Sinn dieses Codes. Beide Objekte haben "TFont" als Classname. Was bringt mir dann ein Vergleich?

Der Vergleich der Klassennamen ist die EINZIGST mögliche Überprüfung zweier Klassen die in unterschiedlichen Modulen deklariert wurden, aber im Grunde identisch sind, auf Gleichheit zu verifizieren.
Eine andere Möglichkeit gibt es einfach nicht.

Da du OHNE Packages arbeitest sieht die Situation einfach so aus:

Modul A benutzt seine komplett eigenen Sourcen für TFont und linkt dementsprechend alle RTTI und Klassen in sein eigenes Codesegement.

Modul B benutzt seine komplett eigenen Sourcen für TFont und linkt dementsprechend alle RTTI und Klassen in sein eigenes Codesegement.

Ergo: beide Module arbeiten mit ihren eigenen Klassen, basierend auf dem identischen Source.

Ein Vergleich beider Klassen miteinander ist im Grunde unsinnig, wie auch ein Typcast über Modulgrenzen unsinnig ist. In jedem Falle stellen die beiden separaten TFont Klassen zwei absolut indifferente Klassen dar.

Klar, praktisch gesehen hat man für Modul A und B jeweils den identischen Source für TFont benutzt, sie sind also logisch gesehen identisch, aber NICHT wirklich aus Sicht des Codes zum Vergleich von Klassen.
Alle Operationen wie "is" und "as" werden damit Probleme bekommen. Die EINDEUTIGKEIT einer Klasse ist aber für das Funktionieren der kompletten VCL von entscheidender Bedeutung. Ein TForm aus Modul A ist eben nicht das gleiche TForm aus Modul B und auch nicht identisch zum TForm im eigenen Prozess.

Der obige Ansatz über IUnknown und COM Interfaces zu gehen ist dagegen richtig in diesem Falle.

Gruß Hagen

Nach der Lektüre von Beschreibungen der VMT dämmert es jetzt ein wenig. Danke für eure Hilfe.