N
Also erzähl nix von wegen es wurde nicht funktionieren
Doch, mach' ich - kann ich mir leider nicht verkneifen.
Schön wär's ja, wenn das so funktionieren würde, aber das tut nicht. Hab' ich alles schon zur Genüge durchgespielt. Z.B. in Anlehnung an
Public Declare Function GetWindowsDirectory Lib "kernel32" Alias "GetWindowsDirectoryA" (ByVal lpBuffer As String, ByVal nSize As Long) As Long
eine Funktion, die einen String/Buffer und dessen Länge als Parameter bekommt, diesen String überschreibt und die tatsächlich hineingeschriebene Länge als Returnwert zurückgibt. Bei GetWindowsDirectory() funktioniert das auch - aber nicht mit meiner VC-DLL-Funktion.
Ich weiss nicht, ob ich blöd bin, oder der VC-Linker oder der #$*§+@%&-Visual Basic Compiler. Ich weiss auch nicht, wie GetWindowsDirectory das macht, aber wenn ich in VB ByVal lpBuffer As String reinstecke, kommt der zwar als LPSTR oder auch LPTSTR mit aktuellem Inhalt in der VC-DLL an - wenn ich aber in der DLL-Funktion in diese String-Adresse per strcpy() was reinschreibe, steht das auch nur innerhalb der DLL-Funktion tatsächlich drin - im VB-Programm ändert das an dem reingesteckten String rein garnichts, der hat nach dem Aufruf der DLL-Funktion denselben Inhalt wie vorher, lediglich die Länge des strcpyrten Strings wird ordnungsgemäß zurückgegeben. Ganz offensichtlich ist die String-Adresse, die in der DLL ankommt, nicht die vom VB-Programm hineingesteckte. Da wird der String-Inhalt zwischendurch umkopiert, aber eben nur in eine Richtung. Kann es sein, dass der feine Unterschied zwischen WINAPI und __declspec(dllexport) da eine Rolle spielt und für Selbstüberlistung sorgt?
Wenn ich in VB bei der Funktionsdeklaration den Parameter als ByRef lpBuffer As String oder einfach lpBuffer As String angebe und dann einen ganz normal mit Dim myString as String und myString = String(ausreichendviel,egalwasfuernchar) angelegten String reinstecken will, schlägt mir der #$*§+@%&-Visual Basic Compiler einen "Type mismatch" um die Ohren.
Wenn ich dagegen StrPtr(myString) als ByRef lpBuffer As String reinstecke, gibt's zwar im #$§+@%&-Visual Basic keinen Type Mismatch mehr, aber dafür kommt in der VC-DLL auch kein String mehr an - da kann ich dereferenzen und casten soviel ich will, in (char)lpBuffer oder ((char*)lpBuffer) oder (char*)((void*)lpBuffer)steht irgendwas an Speichermüll, was nichtmal wie eine gültige Adresse aussieht - der String-Inhalt ist jedenfalls nicht wiederzufinden.
Bei VC-DLL an VC-Programm wäre das alles kein Thema. Hatte ich schon erwähnt, dass ich dieses #$*§+@%&-Visual-Basic hasse...?
