GUID->Datei

[Jan Steinhardt]

Hallo,
wie kann ich aus einer GUID sicher ermitteln, welche DLL/OCX dahinter steckt? Im Augenblick schaue ich immer unter HKEY_CLASSES_ROOT\TypeLib\{GUID}\TypeLibVersion\0\ Win32 nach. Der Haken dabei ist, daß ich immer die TypeLib-Version benötige. Kennt irgendjemand evtl. einen besseren Weg? Ich will sicherstellen, daß alle Controls, die ich verwende, die richtige Versionsnummer bzw. Dateigröße haben.

MfG Jan

[Andreas Kosch]

Hallo,

ein COM-Objekt wird normalerweise durch seine <b>CLSID</b> (COM Class Identifier) gekennzeichnet. Und COM stellt in der Registry unter HKEY_CLASSES_ROOT\CLSID\{<CLSID-Wert>} im Schlüssel <b>InProcServer32</b> (DLL) oder <b>LocalServer32</b> (EXE) einen Bezug zwischen der CLSID und dem ausführbaren Modul her.

Da die Typbibliothek nur optional ist, darf COM nicht über diesen Weg suchen. Erst dann, wenn die CLSID den <b>Standard Marshaler</b> anmeldet, sucht COM nach der Typbibliothek.
&#10

[Jan Steinhardt]

Hallo,
leider ist diese Option nicht so einfach nutzbar! Ich will (mit Delphi) ein Programm schreiben, welches Visual Basic Projektdateien ausliest und mir dann sagt, welche DLLs benötigt werden. Die Einträge dort lauten z.B. so:
<br><pre>Object={831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.0#0; Mscomctl.ocx</pre><br>
Die dortige GUID gibts leider nur im TypeLib-Schlüssel. Leider ist Visual Basic nicht gerade gut, was die TypeLib-Version angeht. Die stimmt manchmal nicht und dann funktioniert mein Programm natürlich auch nicht. Ich könnte zwar alle Quellcodes nach ProgIDs durchsuchen, aber der Aufwand dafür wäre zu hoch.

MfG Ja

[Andreas Kosch]

Hallo,

das Modul wird in der o.g. Zeile an letzter Stelle aufgeführt, warum soll dann noch danach gesucht werden ;-

[Jan Steinhardt]

Hallo,<p>
und woher weiss ich, in welchem Pfad diese Datei liegt? Bei einigen Controls (z.B. Crystal Reports) liegen diese Dateien nicht im Suchpfad und daher entfällt leider diese einfache Möglichkeit:-(<p>
MfG Ja