---

Hallo,

und wieder mal ein Verständnisproblem meinerseits - glaube ich zumindest.

Ziel wäre, einen Träger mittels Graitec Advance Steel 2012 in AutoCAD zu erstellen. Das wollte ich über Befehle an die Kommandozeile von AutoCAD realisieren. Zuerst den Befehl, um den Träger zu verlegen. Dann Enter, dann die Koordinaten des Startpunkts, Enter, die Koordinaten des Endpunkts, Enter.

Ob das so funktioniert oder nicht, weiß ich bisher garnicht.

Ich habe erstmal folgendes Problem - Visual Basic 2010 Express spuckt mir 3 Warnungen aus:
1. Nicht verwendete lokale Variable: "acadapp"
2. Nicht verwendete lokale Variable: "sysapp"
3. Zugriff des freigegebenen Members, konstanten Members, Enumerationsmembers oder geschachtelten Typs über eine Instanz; der qualifizierende Ausdruck wird nicht ausgewertet. (in der Zeile mit "Dim app As AcadApplication = acadapp.AcadApplication", acadapp.AcadApplication ist unterstrichen)

Das passiert irgendwie, weil es in den Assemblys System.Windows.Forms und Autodesk.AutoCAD.ApplicationServices jeweils die Klasse "Applications" gibt. Ich habe dann versucht, das zu trennen. Das haut aber nicht so ganz hin, wie ich mir das vorgestellt habe. Wo könnte sich mein Hirn denn da verstrickt haben? Habe ich das überhaupt richtig verstanden?

Vielen Dank für etwaige Gedankenanstöße 

Und hier der Code:

Code:

---

Imports Autodesk.AutoCAD.Runtime
Imports Autodesk.AutoCAD.ApplicationServices
Imports Autodesk.AutoCAD.Interop
Imports System.Windows.Forms

Public Class FETRAG

    <Autodesk.AutoCAD.Runtime.CommandMethod("fetrag", CommandFlags.Session)> _
    Public Shared Sub fetrag()

        ' Trennung Klassenverweis von "Application" aus den unten genannten Assemblys
        Dim acadapp As Autodesk.AutoCAD.ApplicationServices.Application
        Dim sysapp As System.Windows.Forms.Application
        Dim app As AcadApplication = acadapp.AcadApplication

        ' Kommando an AutoCAD übergeben, um im aktiven Zeichnungsfenster einen Träger zu erstellen
        app.ActiveDocument.SendCommand("_astm4crbeambyclass I")
        SendKeys.Send("{enter}")       
        app.ActiveDocument.SendCommand("0,0,0")
        SendKeys.Send("{enter}")       
        app.ActiveDocument.SendCommand("1000,0,0")
       
    End Sub

End Class

---

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

vbNetFehler.gif

Hallo fewoer,

mal 'ne grundsätzliche Frage: Wenn du nur mit SendCommand arbeitest, gibt es doch auch sehr viel einfacherer Möglichkeiten, diese Makro's zu hinterlegen.
1-Menübefehl: ^C^C_astm4crbeambyclass;I;0,0,0;1000,0,0
2-Lisp (command "_astm4crbeambyclass" "I" "0,0,0" "1000,0,0")

Warum schreibst du das in VB.Net?
Das ist die komplizierteste Umgebung, um eine Command-Abfolge zu realisieren.

Grüße!
Holger

Zitat:

---

Original erstellt von fewoer:
... 3. Zugriff des freigegebenen Members, konstanten Members, Enumerationsmembers oder geschachtelten Typs über eine Instanz; der qualifizierende Ausdruck wird nicht ausgewertet. (in der Zeile mit "Dim app As AcadApplication = acadapp.AcadApplication", acadapp.AcadApplication ist unterstrichen)
[/code]

---

Welche Fareb hat die Unterstreichung?
(Bei Standard-Einstellungen): Grün - Hinweis | | Blau - Fehler

Und was steht unter der Meldung? -> Ich denke, die ist identisch mit dem anbei befindlichem ScreenShot. Da steht ja auch, was zu tun ist.

Grüße!
Holger

------------------
Holger Brischke
CAD on demand GmbH
Individuelle Lösungen von Heute auf Morgen.

defun-tools Das Download-Portal für AutoCAD-Zusatzprogramme!

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Holger!

danke dir vielmals, der Screenshot hat sehr geholfen. Damit haben sich dann die u.g. Einträge erledigt - das wäre ja dann doppelt gemoppelt, wie ich das verstanden habe. Bei mir in Visual Basic waren die Fehlermeldungen übrigens grün unterstrichen, also wohl nur Hinweise, wie du sagst.

Code:

---

'Dim acadapp As Autodesk.AutoCAD.ApplicationServices.Application
'Dim sysapp As System.Windows.Forms.Application

---

Warum ich das ganze in VB.Net schreibe, hab ich mir wegen folgendem überlegt. Der Code wäre in LISP oder über Makros doch ziemlich leicht einzusehen - ein Texteditor und man sieht wie programmiert wurde. VB.Net Code wird dagegen kompiliert, bevor er in AutoCAD geladen wird. Da ist es zumindest schon mal nicht mehr ganz so einfach, Reverse Engineering zu betreiben.

Ein weiterer Grund wäre, dass ich doch mehr Möglichkeiten in VB.Net habe, oder? Ich kann im AutoCAD damit Code über mehrere Fenster hinaus ausführen, was doch in LISP irgendwie schon mal nicht geht, der beschränkt sich doch nur auf das aktive Fenster? Und ich könnte mit VB.Net einfacher "richtige" Excel-Dateien erstellen oder einlesen, also nicht diese CSV-Excel-Dateien.

Oder ist das ein Trugschluss, dass VB.Net einem die meisten Möglichkeiten bietet? Außerdem ist es sicher auch nicht schlecht, sich da ein bißchen reinzuarbeiten - man muss ja schließlich mit etwas einfachem anfangen.

Liebe Grüße!
Patrick

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von fewoer:
... Warum ich das ganze in VB.Net schreibe, hab ich mir wegen folgendem überlegt. Der Code wäre in LISP oder über Makros doch ziemlich leicht einzusehen - ein Texteditor und man sieht wie programmiert wurde. VB.Net Code wird dagegen kompiliert, bevor er in AutoCAD geladen wird. Da ist es zumindest schon mal nicht mehr ganz so einfach, Reverse Engineering zu betreiben.

Ein weiterer Grund wäre, dass ich doch mehr Möglichkeiten in VB.Net habe, oder? Ich kann im AutoCAD damit Code über mehrere Fenster hinaus ausführen, was doch in LISP irgendwie schon mal nicht geht, der beschränkt sich doch nur auf das aktive Fenster? Und ich könnte mit VB.Net einfacher "richtige" Excel-Dateien erstellen oder einlesen, also nicht diese CSV-Excel-Dateien.

Oder ist das ein Trugschluss, dass VB.Net einem die meisten Möglichkeiten bietet? Außerdem ist es sicher auch nicht schlecht, sich da ein bißchen reinzuarbeiten - man muss ja schließlich mit etwas einfachem anfangen.

---

Hallo Patrick,

ja, das ist ein Trugschluss:
- Entwicklungsumgebung ist im AutoCAD integriert: Befehl: VLIDE
- in der Entwicklungsumgebung kann man Lisp-Dateien kompilieren (VLX) Im Unterschied zu den .Net-DLLs können diese VLX-Dateien nicht dekompiliert werden. (da ist VLX deutlich sicherer als DLL
- Excel-Dateien kannst du mit VisualLisp genauso schreiben wie in .Net - Weil es in beiden Umgebungen ohnehin nur via ActiveX (COM) geht
- Der zeichnungsübergrifende Zugriff ist von Lisp aus ebenso möglich. Du kannst weder hier noch da Commands in einer beim Programmstart inaktiven Zeichnung absetzen.

Fazit: Für das was du vor hast .. geht beides, Lisp erscheint mir allerdings weniger kompliziert

Noch Fragen ..

Grüße!
Holger

------------------
Holger Brischke
CAD on demand GmbH
Individuelle Lösungen von Heute auf Morgen.

defun-tools Das Download-Portal für AutoCAD-Zusatzprogramme!

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Ah okay, danke für die Infos. Wusste ich garnicht, dass man LISPs auch kompilieren kann 

Aber dann braucht man VB.Net ja überhaupt nicht, oder? Die einzige Daseinsberechtigung, die mir dafür gerade einfällt wäre ja dann Leuten, die schon VB.Net Erfahrung haben und noch kein LISP können, den Zugang zur AutoCAD Automation zu erleichtern.

Weil wenn mir LISP ja schon alle Möglichkeiten bietet, dann brauche ich mir ja jetzt eigentlich nicht die Mühe machen und mich in VB.Net hineinzuvertiefen 

Liebe Grüße,
Patrick

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

... Naja, so ganz will ich das nicht unterschreiben.
Mit .Net kommt man schon einige Ebenen tiefer in das System rein. Man hat Zugriff auf das Framework, was eben schon ganz andere Bibliotheken enthält. (Datenbankzugriffe, XML, Bildbearbeitung, Dateizugriffe um nur die gebräuchlichsten zu nennen).
Es gibt in Bezug auf AutoCAD aber eben auch Geschichten wie das Overruling, Werkzeugpaletten, Dialoggestaltung (zusätzliche Registerkarten in die Optionen integrieren), die mit Lisp nicht zu realisieren sind. Die Frage ist aber, ob man das denn tatsachlich brauch?
Ich persönlich bevorzuge inzwischen .Net, weil hier das Codehandling (Aufbau von Bibliotheken, Zugriff darauf) einfacher ist. Zudem ist der Programmdurchlauf sehr viel schneller, besonders wenn man die komplette Zeichnungsdatenbank bearbeiten muss.
Ich will aber nicht verheimlichen, dass manche Dinge mit Lisp einfacher, mit viel weniger Codezeilen, umzusetzen sind. Außerdem sind die .Net Programme mitunter Platform und Versionsabhängig - was sehr viele Schwierigkeiten bereiten kann.
Da die Windows-Sicherheitseinstelungen, das Laden von .Net-DLLs aus dem Netzwerk verhindern, ist auch die Softwareverteilung ein Punkt, der neu organisiert werden muss. Lisp-Dateien können ja bekanntlich von überall geladen werden.

Man kann also nicht absolut sagen, dass .Net unnötig ist oder Lisp zu bevorzugen. Es hat beides seine Daseinsberechtigung - jedes hat Vorteile in bestimmten Zielstellungen.

Grüße!
Holger

------------------
Holger Brischke
CAD on demand GmbH
Individuelle Lösungen von Heute auf Morgen.

defun-tools Das Download-Portal für AutoCAD-Zusatzprogramme!

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Okay, ich habe mich jetzt ein bißchen mit VB.Net auseinandergesetzt und stelle fest - wenn man sich mal ein bißchen reingearbeitet hat, ist es für mich leichter Programmabläufe nachzuvollziehen als in LISP. Ist vielleicht auch nur der IDE geschuldet, ich benutze MS VB 2010 Express. Da ist alles noch einen Ticken bunter als in VLisp, hilft mir bei der Übersicht und der Organisation der Programmstrukturen. Wobei mich manches auch noch verwirrt - beispielsweise verstehe ich nicht, wieso VB.Net erst zoomen will, wenn das ganze restliche Programm schon durchgelaufen ist. Obwohl der Zoom bei Programmbeginn steht, macht er es immer zuletzt. Selbst wenn ich ein Wait einbaue nach dem Zoombefehl... dann wartet er, führt das restliche Programm aus und dann zoomt er 

Aber was du in deinem letzten Post sagst, kann ich so bestätigen. Hatte auch den Eindruck, dass VB.Net fixer ist als LISP. Auch das Framework bietet schon einige ganz angenehme Bibliotheken, die mir vieles erst ermöglicht haben, was ich bei LISP einfach nicht hinbekommen habe. Auch wenn ich jetzt noch nicht so tief eingestiegen und von Overruling etc. keine Ahnung habe.

Immerhin hat man ja noch die Möglichkeit, einfache Strukturen in LISP zu realisieren und die dann aus dem VB.Net Programmteil aufzurufen. Damit hat man ja dann die Vorteile beider Welten.

Gruß!

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP