| | | Gut zu wissen: Hilfreiche Tipps und Tricks aus der Praxis prägnant, und auf den Punkt gebracht für SOLIDWORKS | | | | 3DEXPERIENCE Conference 2024 | München, eine Veranstaltung am 16.10.2024
|
Autor
|
Thema: SolidWorks Makros in C# oder VBA? Vor-/Nachteile (988 / mal gelesen)
|
tjaard Mitglied
Beiträge: 26 Registriert: 14.06.2021
|
erstellt am: 04. Okt. 2021 19:32 <-- editieren / zitieren --> Unities abgeben:
Moin zusammen, ich lerne derzeit das Programmieren mit C#, das allerdings nur so als Hobby. Ich habe bereits Erfahrungen in der Programmierung von Makros in VBA. Für meinen derzeitigen Betrieb habe ich ein recht komplexes Tool programmiert. Nun bin ich am überlegen, ggf. dieses in C# zu übertragen und das Ganze über ein Add-In laufen zu lassen. Hat jemand von Euch eventuell Erfahrungen mit C# für SolidWorks Makros? Lohnt sich der Umstieg? Würde mich mal so generell interessieren
------------------ Mit besten Grüßen aus Ostfriesland, Tjaard Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
deckelmaho Mitglied Konstrukteur
Beiträge: 240 Registriert: 03.03.2020 SolidWorks 2023 SP5 Windows 10 64bit Office 2019
|
erstellt am: 05. Okt. 2021 07:25 <-- editieren / zitieren --> Unities abgeben: Nur für tjaard
Hallo Tjaard, ich habe den SWXHelper damals auch komplett in VBA geschrieben und bin später auch auf eine "richtige" Entwicklungsumgebung umgestiegen.(VisualStudio2019) Pro-VBA >Für das Unternehmen ist es sicherlich einfacher den VBA-Code zu pflegen, falls du die Firma mal verlässt. >Falls sich irgendwo ein Fehler einschleicht (wird sicher mal passieren), dann musst du nicht erst neu kompilieren und die .exe tauschen. Jetzt kommen leider nur noch Argumente die für mich gegen VBA sprechen. Contra-VBA >Wenn dein Tool jedoch kein Ende hat, du also immer weiter programmierst, dann wirst du irgendwann an Grenzen stoßen. Du drückst auf den Macro-Button und die bspw. 8Mb Datei wird erstmal ins VBA geladen. >Die Formen sind deutlich ansehnlicher und das mit weitaus weniger Aufwand. Die blauen Forms habe ich mit viel Gefummel im VBA erstellt. https://swxtools.de/ueber/ >Die meisten Sachen die man eigentlich bei einer Anwendung voraussetzt musst du nicht selbst programmieren... ...Animation bei Maus über Button ...Scroll-Funktion bei Listen und Dropdowns ...Ordner und Dateidialoge ...(und mehr) >Generell ist das Programmieren angenehmer... ...automatische Einrückung ...auto-vervollständigung ...alle Klassen eines Steuerelements sind über Dropdown verfügbar ...(und mehr)
Das übertragen des VBA-Codes in C# ist sicher eine gute Übung um sich erstmal zurecht zu finden. Und du weist das der Code funktioniert. LG Kevin
------------------ HOMEPAGE | SWXTools.de - SWXHelper für SOLIDWORKS KONTAKT | support@swxtools.de FACEBOOK | facebook.com/SWXHelper TWITTER | twitter.com/SWXTools Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
nahe Ehrenmitglied
Beiträge: 1764 Registriert: 18.01.2001 arbeite mit: Dell Precision 7750 i7 2,6 GHz 6 Kerne 32GB RAM 512GB SSD NVIDIA Quadro RTX 4000 ------------------------ SWX-2020 SP5.0 EPDM ---------------- Windows 10 ---------------- VB.net VB VBA ein wenig Swift am Mac
|
erstellt am: 05. Okt. 2021 09:22 <-- editieren / zitieren --> Unities abgeben: Nur für tjaard
Hallo tjaard, zusätzlich zu den Info´s von Kevin Pro-VBA - einfach zu debuggen - keine "aufwändige" Registrierung des Makros - einfache Bereitstellung für andere Arbeitsplätze (das Setup hat mich einiges an Zeit gekostet) - keine Registrierung für Dateitypen notw. (bei einem Add-In musst Du dafür Sorge tragen, dass es für bereits geöffnete Dateien aktiviert wird und/oder nur für neue Dateien und für welchen Dataeityp es gelten soll) Contra-VBA - Wenn Du Formular-Daten an eine Datenbank koppeln möchtest, dann geht das mit .net sehr einfach (in meinem Fall, Verknüpfung der Felder vom Setup-Dialog mit einer XML-Datei) - Listenhandling ist, meiner Meinung nach, um einiges einfacher (z.B.: ListOf, Dictionary, ...) - je nach Art das Makros kann die Performance bei einem Add-In besser sein ------------------ Grüße Heinz Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
riesi Mitglied CAD-Admin
Beiträge: 1087 Registriert: 06.05.2002 SWX Premium 2023-Sp5
|
erstellt am: 05. Okt. 2021 10:15 <-- editieren / zitieren --> Unities abgeben: Nur für tjaard
Mein fetter Punkt Pro c#: - Visual Studio als Editor ist deutlich angenehmer, Auto-Vervollständigung - Speziell für mich: Da ich mit SQL-Datenbanken hantieren muss, geht das deutlich einfacher als in VBA - Falls Du mit PDM zu tun hast: Nicht alle Funktionen sind in VBA möglich - Sämtliche Windows-Funktionen stehen einfacher im Zugriff. Negativer Punkt Contra c#: - steile Lernkurve, ohne Browser-Fenster mit Google geht es bei mir nicht. Ein Hoch auf diejenigen, welche bei Stackoverflow für mich sämtliche Fragestellungen gelöst haben. [Diese Nachricht wurde von riesi am 05. Okt. 2021 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
tjaard Mitglied
Beiträge: 26 Registriert: 14.06.2021
|
erstellt am: 05. Okt. 2021 19:14 <-- editieren / zitieren --> Unities abgeben:
Moin zusammen, vielen Dank für Euer Feedback! Ich glaube, ich werde mal versuchen einzelne Funktionen in C# zu übertragen. Einfach um mir eine kleine Herausforderung zu stellen und etwas mehr Erfahrung in dem Programm zu sammeln. Dann werde ich ja sehen, wie es so klappt, bzw. ob ich mir auch diesbezüglich das nötige Know-How aneignen kann. Des Weiteren sind die Gestaltungsmöglichkeiten im C# auch ein dicker, dicker Vorteil für mich. @Kevin, die Entwicklung Deines Tools habe ich auch schon auf Deiner Website bestaunt, dickes Lob einmal an dieser Stelle! Das Problem, dass mein Makro zu groß wird, löse ich derzeit so, dass ich ein Makro als Übersicht programmiert habe, aus welchem ich dann die einzelnen Unterprogramme Aufrufe (RunMacro2-Methode). So lässt sich das Ganze gut splitten. Stichwort Performance: Eines meiner Makros erstellt in einem Zug alle STEP- und DWG-Dateien direkt aus der Baugruppe inkl. einer Art „Filter-System“ und einer Ablage in einem Lieferanten-Server-Verzeichnis. Bisschen schwierig bzw. auch nicht notwendig das Ganze so kurz und knapp zu erklären. Allerdings wird bei großen Baugruppen recht viel Arbeitsspeicher vollgeladen. Da hilft nach einigen Vorgängen nur noch der Neustart. Denkt ihr, hier könnte C# für eine Verbesserung der Performance sorgen? Ich glaube zwar nicht dran, da ich das Problem hier eher auf der Seite SolidWorks sehe - bzw. ist der Vorgang nunmal extrem aufwendig, aber man kann ja mal blauäugig in die Runde fragen. Ich wünsche Euch noch einen schönen Abend!
------------------ Mit besten Grüßen aus Ostfriesland, Tjaard Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
riesi Mitglied CAD-Admin
Beiträge: 1087 Registriert: 06.05.2002 SWX Premium 2023-Sp5
|
erstellt am: 06. Okt. 2021 07:28 <-- editieren / zitieren --> Unities abgeben: Nur für tjaard
Zitat: Original erstellt von tjaard: .... Stichwort Performance: Eines meiner Makros erstellt in einem Zug alle STEP- und DWG-Dateien direkt aus der Baugruppe inkl ....
Daran wird C# nichts ändern können, hier wird nur ein anderer Ansatz helfen. Kannst Du die Baugruppen-Struktur über eure Verwaltung abfragen (evtl. PDM?)? Bei der Programmierung meines Konvertierungs-Tasks für STEP und DWG, schließe ich SolidWorks nach 15 Konvertierungen und starte es wieder neu. So machen es auch die Konvertieungs-Jobs vom PDM oder der Taskplaner. Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
nahe Ehrenmitglied
Beiträge: 1764 Registriert: 18.01.2001 arbeite mit: Dell Precision 7750 i7 2,6 GHz 6 Kerne 32GB RAM 512GB SSD NVIDIA Quadro RTX 4000 ------------------------ SWX-2020 SP5.0 EPDM ---------------- Windows 10 ---------------- VB.net VB VBA ein wenig Swift am Mac
|
erstellt am: 06. Okt. 2021 08:30 <-- editieren / zitieren --> Unities abgeben: Nur für tjaard
Hallo tjaard, ich bin auch der Meinung von riesi, dass sich dieses Verhalten nicht mit dem Einsatz eines Add-In´s ändern wird. Das Problem mit dem Speicher kenne ich. Ich musst mal rund 2.500 Datei als PDF ausgeben und bin auf das gleiche Problem gestoßen. Da es eine einmalige Sache war habe ich es ähnlich wie riesi gemacht und nach rund 250 Dateien SWX beendet und die nächsten 250 angestoßen. Ich hab das nicht getestet aber ev. würde es was bringen die Baugruppe und/oder Teile im Modus "ViewOnly" zu öffnen Aber Achtung: meines Wissens werden die Dateien in diesem Modus nicht aktualisiert und es besteht die Gefahr, dass man nicht aktuelle Daten erhält.
------------------ Grüße Heinz Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
tjaard Mitglied
Beiträge: 26 Registriert: 14.06.2021
|
erstellt am: 06. Okt. 2021 21:23 <-- editieren / zitieren --> Unities abgeben:
Hallo Riesi und Heinz, vielen Dank für Eure Antworten. Ich befürchte leider auch, dass es keine andere Möglichkeit gibt als einen Restart. Ich habe heute eine Sicherung eingebaut, dass das Makro nach 10 Ausführungen auch wirklich neugestartet werden soll. Falls es jemanden interessiert, das mache ich so: Ich habe eine externe .txt-Datei angelegt, in welche bei jeder Ausführung des Makros eine Zeile ergänzt wird. Im nächsten Schritt werden vor dem Starten des Makros die Zeilen ausgelesen, sobald die 10 Zeilen erreicht sind, gibt es eine Warnmeldungen, welche auf einen Neustart verweist. Sobald diese Warnmeldungen, dass SWX neugestartet wurde, mit vbYes bestätigt wird, wird der Inhalt der Textdatei gelöscht. Dann geht das Ganze wieder von vorne los. Ist sicher nicht der beste Weg, aber war so die erste Möglichkeit, die mir eingefallen ist. @Heinz, ich gehe auch davon aus, dass view_only den Arbeitsspeicher entlasten würde, jedoch müssen bei meinem Makro die Dateieigenschaften ausgelesen werden, das funktioniert in diesem Modus anscheinend nicht. Hat jemand von Euch eventuell noch ein paar generelle Ideen, wie man den Arbeitsspeicher entlasten kann? Ich weiß, das ist extrem schwierig, wenn man keinen Code dazu hat, den darf ich allerdings nicht posten. Ich weiß, dass es in Excel-Makros ein paar Standard-Anweisungen gibt, mit welchem man das Ganze beschleunigen kann. Zum Beispiel Application.ScreenUpdating, Application.EnableEvents = False usw. usw. Ansonsten muss ich wohl mit der Restart-Methode leben.
------------------ Mit besten Grüßen aus Ostfriesland, Tjaard Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
| Anzeige.:
Anzeige: (Infos zum Werbeplatz >>)
|