Hallo, schweren Herzens bin ich jetzt von VBA auf Visual Studio(Basic) umgestiegen. Ich möchte ein Projekt mit MCP2221 realisieren. Vom Hersteller habe ich eine DLL und die Beispiele funktionieren auch. Ich möchte aber ein grafisches Programm. Da stellt sich mir folgende Frage: Wie und wo werden "extene" DLL deklariert? Unter Projekt/Verweis hinzufügen? Gruss Bodo Und nebenbei(ich weiss, der Ton mit Fragen Unwissender, ist etwas, nennen wir es, rauher): meine Bücher erklären Alles, nur das nicht und google ist auch nicht kaputt. Evtl. die falschen Suchbegriffe.
Wenn man Dir helfen soll, dann müsstest Du den Leser schon mal mit einem Minimum an Informationen versorgen. Das Du jetzt nicht mehr VBA machst, ist nicht hilfreich. Was verwendest Du jetzt (welche Sprache, welcher Compiler/IDE, welche Version, welches Betriebssystem ist das Ziel...)?
Auch die Art der DLL ist nicht ganz unwichtig (nativ, COM, .NET, ...). Hinzufügen im einfachen Fall vermutlich über den Solution Explorer -> Dependencies-Kontextmenü (oder siehe Gunnars Beitrag). Beachte aber, dass die entspr. DLL auch auf dem Zielsystem vorhanden sein (und dort von deinem Programm gefunden werden) muss.
:
Bearbeitet durch User
Bodo M. schrieb: > Vom Hersteller habe ich > eine DLL und die Beispiele funktionieren auch. Ich möchte aber ein > grafisches Programm. Da stellt sich mir folgende Frage: Wie und wo > werden "extene" DLL deklariert? Unter Projekt/Verweis hinzufügen? Genauso wie in den funktionierenden Beispielen.
Torsten R. schrieb: > Was verwendest Du jetzt (welche Sprache, welcher Compiler/IDE, welche > Version, welches Betriebssystem ist das Ziel...)? Hallo, danke für die Antwort. Sprache: Visual Basic, (siehe 1.Post, verwand mit VBA) Compiler/IDE: Visual Studio, (siehe 1.Post) Version: Visual Studio 2022 (aktuell zum Downloaden) Betriebssystem: Windows10 (VS gibt es glaube nur für Windows) Gruß Bodo
Michael K. schrieb: > Hinzufügen im einfachen Fall vermutlich über den Solution Explorer -> > Dependencies-Kontextmenü (oder siehe Gunnars Beitrag). Beachte aber, > dass die entspr. DLL auch auf dem Zielsystem vorhanden sein (und dort > von deinem Programm gefunden werden) muss. Das hat mich mit der NI-VISA API einen ganzen Tag gekostet!
Natürlich ist es meistens nicht sinnvoll, das Fahrrad immer wieder neu erfinden zu wollen, sondern die Arbeit anderer, hier die DLL oder Frameworks und Libraries zu nutzen. Manchmal kann es aber auch effektiver sein, das Ganze selber in die Hand zu nehmen. Ist der Chip so kompliziert?
Bodo M. schrieb: > Torsten R. schrieb: >> Was verwendest Du jetzt (welche Sprache, welcher Compiler/IDE, welche >> Version, welches Betriebssystem ist das Ziel...)? > Hallo, > danke für die Antwort. > > Sprache: Visual Basic, (siehe 1.Post, verwand mit VBA) > Compiler/IDE: Visual Studio, (siehe 1.Post) > Version: Visual Studio 2022 (aktuell zum Downloaden) > Betriebssystem: Windows10 (VS gibt es glaube nur für Windows) > > Gruß Bodo Zuerst mal: VB.net ist NICHT verwandt mit VBA. Auch wenn manches ein bissel ähnlich aussieht. However, du musst für VB.net die DotNet-Wrapper-DLL als Verweis einbinden. Das ist ein DotNet-Assembly, muss also auch als solches eingebunden werden. Diese Wrapper-DLL landet dann beim Kompilieren automatisch mit im Zielverzeichnis des Programms. Das allein genügt aber nicht, denn es handelt sich eben nur um einen Wrapper. Die eigentliche Funktionalität steckt in den beiden anderen DLLs im selben Verzeichnis des Zip-Archivs von MC. Die musst du also zusätzlich zum Projekt hinzufügen (nicht als Verweise, sondern im Projektexplorer als Dateien). Und du musst zusätzlich dafür sorgen, dass diese beiden DLLs automatisch mit in's Zielverzeichnis kopiert werden. Auch das stellt man im Projektexplorer ein. Falls du übrigens den 2221 nur als reine UART verwenden willst, dann brauchst du den ganzen Kram garnicht. Einfach den von MC bereitgestellten COM-Port-Treiber dafür installieren und das Ding taucht im System auf. Dessen Funktionalität kannst du (wie jeden anderen COM-Port) direkt nutzen. Alles dafür nötige Zeug findest du im Namespace System.IO.Ports, insbesondere natürlich die zentrale Klasse Serialport.
Danke für Eure Antworten. Frank E. schrieb: > Natürlich ist es meistens nicht sinnvoll, das Fahrrad immer wieder neu > erfinden zu wollen, sondern die Arbeit anderer, hier die DLL oder > Frameworks und Libraries zu nutzen. Meine Worte und fehlende Ahnung, deshalb DLL einbinden. Frank E. schrieb: > Ist der Chip so kompliziert? S. schrieb: > Falls du übrigens den 2221 nur als reine UART verwenden willst, dann > brauchst du den ganzen Kram garnicht. Der Schaltkreis ist nicht kompliziert. Ich möchte I²C-Read und Write-Befehle an einen anderen Schaltkreis schicken. Das was der Chip alles kann, nutze ich garnicht. > Manchmal kann es aber auch effektiver sein, das Ganze selber in die Hand > zu nehmen. Wenn "selber in die Hand nehmen" selbst programmieren heißt, dann ist das nicht mein Ding. Gunnar F. schrieb: > unter Project/Add References Danke. Harald K. schrieb: > Genauso wie in den funktionierenden Beispielen. Das bin ich gerade am forschen. Zu langsam geschrieben. Den letzten Post hatte ich nicht gesehen und nur überflogen. "Wrapper" das schreckt mich erstmal ab. Also danke an Alle. Gruß Bodo
Bodo M. schrieb: > Zu langsam geschrieben. Den letzten Post hatte ich nicht gesehen und nur > überflogen. "Wrapper" das schreckt mich erstmal ab. Das ist sehr ungünstig, wenn du DotNet als Basis verwenden willst. DotNet ist managed code. Jegliche Benutzung "nativer" DLLs erfordert deshalb zwingend einen Wrapper. Der vorliegende Fall ist die absolute Luxus-Variante, der Hersteller der nativen DLLs liefert den passenden DotNet-Wrapper gleich mit, man braucht ihn bloß einbinden und kann schon den ganzen Kram benutzen. Nix ist einfacher. Richtig spannend wird es erst, wenn du native DLLs benutzen willst, für die es eben keinen fertigen DotNet-Wrapper gibt. Dann musst du den nämlich selber schreiben. Und das kann von "recht einfach" bis hin zu "öde, komplizierte Riesen-Scheißarbeit" sein, was dafür an Aufwand nötig ist. Für die eher einfachen Fälle (z.B. Zugriff auf viele Win32-APIs) gibt es bereits viele "fertige" Wrapperfunktionsdeklarationen (Google-Futter: "pinvoke"). Die sind allerdings nicht selten durchaus fehlerhaft und funktionieren nur unter bestimmten Randbedingungen oder auch garnicht...
Ob S. schrieb: > Das ist sehr ungünstig, wenn du DotNet als Basis verwenden willst. > DotNet ist managed code. Jegliche Benutzung "nativer" DLLs erfordert > deshalb zwingend einen Wrapper. Das wundert mich jetzt. Ich habe kürzlich eine C# Applikation geschrieben, die den Peak-CAN-Adapter über die peak-can.dll (o.ä.) anspricht. Das ging m.E. ohne Wrapper. Ich hatte mich über eine Fehlermeldung gewundert, irgendwas mit Marshalling, das lief darauf hinaus, dass ich der DLL nicht die richtigen Parameter übergab. Nachdem ich das korrigierte, lief die Sache zur Zufriedenheit.
Gunnar F. schrieb: > Das wundert mich jetzt. Ich habe kürzlich eine C# Applikation > geschrieben, die den Peak-CAN-Adapter über die peak-can.dll (o.ä.) > anspricht. Das ging m.E. ohne Wrapper. Nein, bestimmt nicht. Was dich wohl irritiert: Ein Wrapper muss nicht zwingend in eine DLL ausgelagert werden (außer für bestimmte Sonderfälle wie etwa Hookfunktionen), er kann auch direkt im Code der Exe enthalten sein. Das sind dann im einfachsten Fall einfach nur passende Deklarationen der DLL-Funktionen. Eben sowas, wie du im von mir als Google-Futter angegebenen Pinvoke reichlich finden kannst. Das sind die Wrapper für die DLL-Funktionen. Und irgendwo steht sowas auch in deinem Code. Wenn du ihn selber geschrieben hättest, wüßtest du das. Ist aber wohl einfach nur C&P-"programmiert"...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.