In der Firma, die ich arbeite, entwickeln wir die gesamte GUI in C #, aber der Anwendungskernel wurde hauptsächlich in Delphi 5 (aus historischen Gründen) entwickelt, mit vielen Komponenten, die in COM + erstellt wurden. In Bezug auf diese sehr spezifische Art von Anwendung a ich zwei Fragen:
Erfahrene Leute in Delphi und / oder COM, haben Sie irgendwelche Arbeitsumgebungen, um mit der fehlerhaften TLB-Schnittstelle zu arbeiten? Einige der Fehler sind: IDE-Absturz während der Edition eines großen TLB, Verlust von Methoden-IDs, TLB-Korruption usw. Hier haben wir keine gute Lösung gefunden. Eigentlich haben wir versucht, die neue Version 2007 zu aktualisieren. Aber die neue IDE-TLB-Schnittstelle hat die gleichen Fehler, die wir zuvor gefunden haben.
Wie kontrollieren Sie TLB-Versionen? Die TLB-Datei ist in einem binären Format und Konfliktlösungen sind sehr schwer zu tun. Wir haben versucht, die Interface-Beschreibungen nach IDL zu exportieren und in CVS zu schreiben, aber wir haben keine gute Möglichkeit gefunden, TLBs aus IDL mit Delphi zu generieren. Außerdem hat das von Microsoft bereitgestellte MIDL-Tool die IDL-Dateien, die wir aus Delphi exportiert haben, nicht korrekt analysiert.
Ich denke, Sie sollten sich Delphi 2009 genau ansehen.
Delphi 2009 hat Änderungen an der COM-Unterstützung, einschließlich einer textbasierten Ersetzung für die binären TLB-Dateien.
Sie können mehr auf Chris Bensens Blog lesen.
In der fernen Vergangenheit (bevor ich für CodeGear anfing) gab ich die ungerade IDL-Sprache auf, die die IDE präsentierte, schrieb meine eigene IDL und kompilierte sie mit MS midl. Das hat weitgehend funktioniert; der einzige Catch, IIRC, stellte sicher, dass Dispids (ID-Attribut) auf Automationsschnittstellen (Dispatch Interfaces) für Property Getter & Amp; Setter - es gab eine Invariante, die Tlibimp erwartet hatte, aber Midl hat das nicht garantiert.
Da Delphi 2009 jedoch eine sichere Teilmenge der Midl-Syntax verwendet und einen Compiler für dieses Midl in der Box enthält und in die IDE integriert ist, sollten diese Probleme der Vergangenheit angehören.
Wir haben auch Delphi 2009 bereits installiert und es scheint die Unterstützung für Typbibliotheken verbessert zu haben. Ich habe jedoch schon eine ganze Weile mit COM und Typbibliotheken gearbeitet und hier sind meine allgemeinen Fehler, die ich über die Jahre gefunden habe. Ich stimme dem hübschen Buggy zu und ist bis Delphi 2006 (unsere Version vor der Verwendung von 2009) hoch.
Aber ich denke, Ihre beste Lösung ist wahrscheinlich ein Upgrade. Sie erhalten auch Unicode-Unterstützung.
Die Verwendung von Delphi 2009 hat großen Teil der großen TLB-Dateien stark beansprucht und die Konvertierung unserer vorhandenen Objekte war problemlos, aber unsere com-Objekte verwenden keine Bibliotheken von Drittanbietern.
Wir werden unsere GUI-Anwendungen migrieren, sobald die Bibliothekshersteller unterstützte Versionen veröffentlichen.
Die gleiche Erfahrung mit der TLB-Schnittstelle hier: wir haben es einfach nicht mehr benutzt.
Wir arbeiten mit verschiedenen IDL-Dateien (hand-build) für verschiedene Teile unseres Frameworks, verwenden das # include-Konstrukt, um sie in die IDL der eigentlichen Anwendung aufzunehmen, und generieren dann das einzelne tlb mit MIDL und tlibimp es . Wenn die Anwendung über keine eigene IDL verfügt, sind vorkompilierte Versionen der verschiedenen Framework-TLB-Dateien verfügbar.
Immer wenn das Framework in eine neue Version eintritt, wird ein Skript ausgeführt, um die GUIDS auf allen notwendigen Schnittstellen in den IDL-Dateien neu zu generieren.
Dies hat uns viele Jahre lang gut getan, und für uns wird das neue IDL / TLB-Toolset von Delphi 2009 nicht nur in die IDE integriert werden müssen, sondern auch für automatisierte Builds und vieles mehr. Ich kann es kaum erwarten, meine Hände mit einigen Experimenten schmutzig zu machen!
Tags und Links delphi com type-library com-hell