B
Hmm, eine VB Definition eines C Structs. Da bekomme ich leicht Bauchschmerzen.
Probiere doch mal bitte folgendes. Generiere ein kleines C Projekt, was eine Funktion
BOOL MyGetOpenFileName(const char* Title, char* FileName, size_t FileNameCount)
mittles OPENFILENAME und GetOpenFileName() definiert und aufruft. Hierbei kannst du mal den cbSize Parameter in dem C und VB Projekt miteinander vergleichen. Sollte alles gut funktionieren, kannst du ein DLL Projekt anlegen, welche genau diese Funktion exportiert, s.d. du die Funktion aus Excel heraus aufrufen kannst.
Declare Function MyGetOpenFileName Lib "Test.dll" (ByRef Title As String, ByRef FileName As String, FileNameCount as Long) As Long
Hintergrund:
Bei Aufrufen von DLL aus Excel hast du das Problem, wie die einzelnen Datentypen, Structs von der DLL aus nach VB gemappt werden. Hinter Datentypen wie std::string, String stecken oft eine etwas komplexere Struktur als einen Zeiger auf Zeichen. Wenn du nun beispielsweise annimmst dass VB String = std::string = char* auf elementarer Ebene ist, so kann die interne Struktur überschrieben werden und es knallt.
Siehe auch:
http://vb.mvps.org/tips/vb5dll.asp
Der cbSize Parameter des OPENFILENAME Structs ist aber auch nicht ohne. Unter C wird dieser Parameter immer mit der sizeof(OPENFILENAME), der Größe des Structs, initialisiert. Solche Structs sind aber nicht starr. Oftmals erweitern neuere Windows Version diese, s.d. diese größer wird. Offenbar wird cbSize dazu benutzt Versionen zu unterscheiden. Und nun definiert man sich in VB ein Struct wie OPENFILENAME. Doch anstatt dass diese 32 Byte (nur mal um eine Zahl zu sagen) belegt, belegt diese 38 Byte s.d. Windows von einer anderen Version ausgeht und deswegen die letzten Bytes des Structs missinterpretiert.
Deswegen die C Dll. So verhindert man die Nutzung von komplexeren C++ Datentypen, und man kapselt die OPENFILENAME Struktur und einigermaßen die Übergabeparameter.
