---

Guten Morgen,

ich habe jetzt mal eine ganz allgemeine Frage zur Programmierung von AutoCAD.

Ich will ein Programm erstellen, welches über ein beliebiges Bauteil, nach einer von mir erstellten Regel, Linien zeichnet (Oberflächenlinien sind wohl nur durch Querschnitte zu erzeugen). Auf diesen Linien Punkte verteilt und diese wiederrum in einer bestimmten Art und Weise verbindet und dann die Längen dieser einzelnen Linien ermittelt und in einer Excel-Tabelle ausgibt. Hinzukommt, dass ich eine Eingabemaske erstellen möchte, in der der Benutzer verschiedene Dinge festlegen soll, die dann an AutoCAD weitergegeben werden (z.B. wie viele Punkte auf den einzelnen Querschnitte verteilt werden sollen etc.)

Jetzt bin ich nur völlig verwirrt und weiß gar nicht, in welcher Programmiersprache ich das realisieren soll.
Es war zuerst gedacht, die Eingabemaske in C++ zu erstellen und die Zeichenbefehle dann in LISP, allerdings habe ich erfahren, dass die Schnittstelle zwischen den beiden Programmiersprachen nur sehr schwer zu bestimmen ist.
Wäre VBA die richtige Programmiersprache für mein Vorhaben? Oder ist sie in Verbindung mit AutoCAD noch nicht ausgereift genug?
Mit VBA müssten man doch genauso, wie mit C++ schöne Eingabemasken erstellen können oder?
Ich habe nämlich die Befürchtung, dass LISP jetzt "ausstirbt" und mein mühevoll erstelltes "Programm" (wenn es denn irgendwann fertig werden sollte) bei einer der nächst neueren AutoCAD-Versionen nicht mehr läuft.

Wozu würdet Ihr mir raten? Können, tue ich leider keine dieser Sprachen richtig. Ich habe mich in der letzten Zeit lediglich mit LISP versucht vertraut zu machen.

Viele Grüße
Andrea

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

---

Hallo Andrea,

wenn du von allem keine Ahnung ast, würde ich Dir empfehlen mit LISP weiter zu machen. Diese Sprache läßt sich meiner Meinung nach am schnellsten erlernen.
Das Argument der schöneren Dialogfenster lasse ich kaum gelten. Sicherlich sind die Dialoge in Lisp nicht so super schön, aber wichtiger ist doch der Inhalt. Das erstellen der Dialogfenster mit DCL ist etwas bescheiden, aber es funktioniert.
Das LISP ausstirbt (zumindest in Verbindung mit AutoCAD) kann ich mir nicht vorstellen. Dieses Gerücht kommt bei jedem Releasewechsel auf, weshalb ich dem mittlerweile keine Beachtung mehr schenke.
Wie Du hier schon gemerkt hast, ist die LISP-Gemeinschaft auch recht groß, so dass man zu nahezu jedem Problem auch eine Antwort bekommt.

Die eigentliche Aufgabenstellung, die du erfüllen sollst, ist meiner Meinung nach ganz wunderbar mit LISP zu lösen. Ich verfolge Deine Beiträge schon länger (habe mittlerweile auch dein Ziel verstanden), und habe auch verschiedene Teilschritte einfach mal aus Interesse programmiert. Wenn Du also Fragen hast, einfach posten.

Grüße Holger

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

---

Hallo Holger,

vielen Dank für Deine Antwort. Das beruhigt mich jetzt ein wenig, da ich schon befürchtet habe, besser von ganz vorne beginnen zu müssen. Ich tue mich aber auch mit LISP recht schwer, wie Du wohl an meinen häufigen Fragen schon gemerkt hast. Die Entwicklerhilfe im Mechanical Desktop ist leider fast ausschließlich auf VBA ausgerichtet, sodass sie so gut wie gar nicht weiterhilft. Die Bücher, die etwas über LISP und die Geometriedatenbanken enthalten sind alle schon sehr alt. Einige Befehle funktionieren da schon gar nicht mehr. Ich habe so nur die Möglichkeit, geschriebene Codes mir anzusehen und zu versuchen sie zu verstehen und dann für meine Bedürfnisse abzuwandeln. Das ich überhaupt etwas verstehe habe ich zum größten Teil Axels (mapcar)-Tutorium zu verdanken.

Ist es denn überhaupt machbar, einen Zugriff auf Excel-Tabellen mit LISP zu realisieren? Ich glaube ja oder?
Und wo finde ich Informationen, wie man *.dcl erstellt (Wie da der Code-Aufbau auszusehen hat etc)?

Viele Grüße
Andrea

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

---

Hallo Andrea,

du bist schon bei Axel (mapcar) gelandet - das ist gut! Dieses Tutorial ist sehr gut, da man erkennen kann, in welcher Kombination die Befehle was bewirken. Ich nutze hauptsächlich die in VLisp enthaltene Hilfe und denke, dass diese auch beim  MDT enthalten ist. DCL sollte dort auch erläutert sein.

DCL ist auch nicht so schwer, das einzige was etwas unhandlich ist, ist die Anordnung der einzelnen Elemente. Wenn man aber den Aufbau von Reihen (row) und Spalten (column) erst einmal verstanden hat, dann ist es nur noch halb so schwer. Die Übergabe nach Lisp gestaltet sich u.U. in der Anfangszeit etwas umständlich, da die Dialogboxelemente Strings- zurück geben. Wenn man also eine Zahl möchte, muss der String erst in eine Zahl umgewandelt werden. Falls der User Text in ein Zahlenfeld schreibt, ist zuvor eine Prüfroutine einzubauen, die dann natürlich meckert wenn keine Zahl entdeckt wird.
Die Abfrage der eingegebenen Werte erfolgt mit get_tile, setzen kann man mit set_tile und direkt auf Eingaben reagieren mit action_tile.
Einfach probieren und wenn's nicht klappt: fragen.

Excel Tabellen kann man erstellen. Ich mache es immer so, dass mit LISP eine TAB-getrennte *.txt- Datei erzeugt wird. Diese kann dann problemlos in Excel geöffnet werden.

Bei Fragen ...

Grüße Holger

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

---

Hallo,
ich finde die Programmierung in VBA einfacher als in LISP.

Ich habe jahrelang LISP programmiert, es ist eine tolle Sache, was man damit in AutoCAD machen kann. Ich finde nur, dass das ganze in VBA einfacher geht, dadurch dass man einfach auf Eigenschaften und Methoden der Objekte zugreift. Es gibt Dinge, die man in VBA nicht realisieren kann. Dafür schreibe ich mir eine kleine LISP Routine, die ich dan von VBA aus aufrufe.
Wenn man mit Dialogboxen arbeitet, ist es in VBA sowieso leichter. Einfach die Box zusammenschieben und fertig, nicht mühsam die Syntax für DCL lernen. Die Doku dazu findest du im Visual LISP Developers Guide. Ich habe sie mir jetzt nicht angeschaut, aber in den Vorgängerversionen war sie bescheiden. Es ist ja schon ein Fortschritt, dass man sich DCL-Code in der VisualLISP IDE anschauen kann.

Unter LISP kann man mit z.B. vlax-get-object auf Excel zugreifen. Wie es ganau funktioniert, weiss ich nicht. Prinzipiell geht es aber.

Gruss Uwe

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

---

Nachdem mein Weg von Lisp nach VBA und endgültig ARX ging kann ich nur folgendes sagen:

VBA ist einfacher da Dialogfeldererstellung einfacher

LISP bietet (vor allem mit Visual LISP) mehr Möglichkeiten als
VBA

ARX ist der Ferrari unter den Schnittstellen, schneller und Möglichkeiten bis zum Abwinken (z.B. in einem Dialogfeld eine
Zeichnung in einem Fenster öffnen, Bemaßungsvoransicht arbeitet so)
aber auch die komplexeste, mit Layer.setColor wie in VBA ist es da
nicht getan, Layerdatenbank öffnen, Layer öffnen, Farbe ändern, schließen etc.

------------------
Ing. Bernd Cuder
Cad&Co makes CAD easy

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

---

Meiner Meinung nach sprechen füer VisualLISP und VBA die in ACAD integrierte Entwicklungsumgebungen, die auch noch kostenlos mitgeliefert werden. Für ARX braucht man soviel ich weiss irgendeinen MS C++ Compiler.
Da die meisten hier wahrscheinlich Gelegenheitsprogrammierer für kleinere Tools sind, wird sich die Anschaffung eines Compilers nicht lohnen. Bei professionellen Anwendungen sieht es natürlich ganz anders aus.

grus uwe

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

---

Hi Leute,

ein paar Sachen kann ich einfach nicht unwidersprochen stehen lassen. C++ - der Ferrari unter den Schnittstellen? Ich dachte immer, Ferraris zeichnen sich durch die Höchstgeschwindigkeit aus, aber nicht so sehr durch ihr Potenzial als Möbel- oder Müllauto, Taxi usw. Aber genau das leistet doch die C++-Schnittstelle: Universalität - damit kann man nämlich alles machen, was in AutoCAD machbar ist. Nur eines leistet die C++-Schnittstelle eindeutig nicht: Kurze Entwicklungszeiten, also Ferrari-Geschwindigkeit.

Das leistet allerdings Lisp - in kaum einer anderen Sprache kann man mit so wenig schnell dahingeschriebenem Code so viel erreichen. Da verweise ich auf den Beitrag von Stefan in einem anderen Thread von AB (diese PEDIT-Geschichte). Drei Zeilen, und das Problem ist gelöst. Ein weiterer Vorteil von Lisp ist auch die äusserst einfache Syntax, die man in einer halben Stunde begriffen hat und die keine Ausnahmen kennt. Lisp kann aber auch anspruchsvoll sein - es ist ja nach weit über einem Jahrzehnt AutoLisp so, dass die meisten immer noch nichts mit mapcar und lambda anfangen können.

Wenn man nur (setq a ..., (setq b ... usw. untereinander schreibt, dann unterscheidet sich auch ein Lisp-Programm wenig von einem Basic-Programm. Da hat dann VB den Vorteil bei den Dialogen auf seiner Seite, ganz eindeutig. An der DCL-Schnittstelle hat AutoDesk seit der Einführung vor einem knappen Jahrzehnt nicht einen Finger mehr gerührt - da muss man schon aufpassen, dass die Dateien keinen Schimmel ansetzen. Kein Wunder, dass ObjectDCL so boomt - wenn's AutoDesk irgendwann mal in den Sinn kommt, wird das eben auch gekauft und die Pflege eingestellt.

Lisp ist aber ganz klar vorn, wenn es um komplexere Inhalte geht - das setzt aber auch voraus, dass man die komplexen Inhalte a) begriffen hat und b) gewillt ist, sie umzusetzen.

Und noch ein paar Worte zur C/C++-Schnittstelle: Eigentlich sind das ja zwei Schnittstellen - zum Einen ADS (Ansi C), und zum Anderen ObjectARX in C++. Man sollte diese beiden auch getrennt diskutieren, da sie völlig unterschiedlichen Zwecken dienen.

Ich versuche hier mal, die Vor- und Nachteile der Sprachen aufzulisten und dabei eine Schätzung für den Programmieraufwand abzugeben - Widerspruch wird gerne entgegengenommen. Als Messlatte dient mir natürlich Lisp:

1. Lisp
Entwicklungszeit-Faktor: 1
Unschlagbar für Rapid Prototyping. Kurzer, mächtiger Code, mit dem auch äusserst komplexe Probleme in endlicher Zeit gelöst werden können. Klare Syntax, kurze Lernphase. Dialoge: Steinzeit-Niveau, da muss man sich schon in die Hände eines Drittanbieters begeben. Entwicklungsumgebung: Notfalls brauchbar, besser als Notepad jedenfalls. Und: Zugriff auf eine schier unendliche Menge fertiger Lösungen.

2. VisualBasic
Entwicklungszeit-Faktor: 2 - 5
Wenn die Probleme nicht so komplex sind, ist VB eine gute Wahl. Wenn's komplexer werden sollte, sollte man vielleicht lieber Perl lernen und die Basic-Programme dann durch Perl-Skripte erzeugen lassen (das mache ich z.B. bei der Programmierung von Corel Photo-Paint, wenn's mir zu blöd wird). Die Syntax von VB ist stellenweise etwas undurchsichtig, und vieles erreicht man nur durch Kopieren von Code-Passagen. Fertige Lösungen findet man nicht so viele wie bei Lisp, auch die Informationen in NGs usw. sind deutlich weniger. In der Dialogprogrammierung deutlich besser als Lisp. IDE: Kann man mit leben.

3. C-Schnittstelle:
Entwicklungszeit-Faktor: 10 - 50
Gut geeignet, um neue Lisp-Befehle zu basteln (gutes Beispiel: DosLib). Wer dem Break-Befehl ein Knackgeräusch verpassen will, wer eine gute Sort-Funktion in Lisp braucht, der ist hier richtig. Ich benutze diese Schnittstelle vor allem, wenn's um sehr zeitkritische Angelegenheiten oder um Windows geht, und auch dann, wenn ich Lisp-Funktionen brauche, die 'arbitrary arguments' bekommen sollen. Fertige Lösungen im Netz: So gut wie keine. IDE: siehe 4

4. ObjectARX:
Entwicklungszeit-Faktor: 20 - 500 ??
Die Schnittstelle, wenn's darum geht, eigene Entities zu erzeugen. D.h. man ergänzt AutoCAD, aber dann auch mit allen Konsequenzen wie z.B. DXF-Verhalten usw., man braucht eine Testphase (und Tester!), muss sich darum kümmern, wie andere die Zeichnung noch lesen können usw. Ein abgeschlossenes Studium der Mathematik ist empfehlenswert. Syntax: Verknorzt, viele Ausnahmen. Schwieriger Zugriff auf Informationen. Fertige Lösungen im Netz: Absolut keine. IDE: Durchaus brauchbar.

Die Kosten für den C/C++-Compiler sind lächerlich. Einen Arbeitgeber kostet der Compiler ungefähr so viel wie eine zwei- oder dreistündige Internet-Recherche eines Programmierers. Der Aufwand für die Einarbeitung dürfte allerding deutlich(!) höher liegen.

Meine Empfehlung: Lisp, was sonst. Mein Username ist ja nicht DoCmd;-) Das Argument, dass Lisp verschwinden könnte, zieht nicht: das kann sich AutoDesk auch bei aller Arroganz im Moment nicht leisten. Falls doch: Ich habe noch einen Interpreter hier liegen! Soll heissen: es würde andere geben, die das fortsetzen. VB kann ich nur empfehlen, wenn man a) keine Glanzlichter setzen will oder b) sowieso dauernd MS-Office-Sachen macht. C ist eine schöne Ergänzung für Lisp, und ObjectARX kann ich wirklich nur Entwicklungs-Teams empfehlen, die die notwendige finanzielle Rückendeckung haben.

Wenn ich diesen Beitrag während der Arbeitszeit geschrieben hätte, wäre er meinen Arbeitgeber teurer gekommen als der C-Compiler;-)))

Schluss jetzt, Axel 

------------------
http://www.tutorial.autolisp.info

http://www.advanced.autolisp.info

http://www.activex.autolisp.info

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

---

Das ist dann wohl Ansichtssache was Geschwindigkeit ist

Tatsache ist:

ARX ist die mit Abstand schnellste Schnittstelle in AutoCAD
(O Wunder wenn AutoCAD selbst in C geschrieben ist)
Das die Entwicklung eines ARX Programmes möglicherweise
aufwendiger ist habe ich ebenfalls erwähnt (siehe vorher)

Und wenn wir schon bei Ferrari sind, die Entwicklungszeit eines
neuen Ferraris hat noch niemanden interessiert, das Endergebnis
zählt, ein schnelles Auto bzw. Programm.

Ich habe meine Programme von Lisp in Vba und letzendlich in Arx
hinüber getragen und wenn du einmal versucht hast den Autocad
Bemaßungsblock über VBA zu ändern und dasselbe in Arx gemacht hast,
dann weißt du was Geschwindigkeit ist.

Die Behauptung das man ARX und ADS getrennt betrachten sollte
ist auch Blödsinn, sie dienen heute beide nur einen Zweck,
AutoCAD auf C zu programmieren da die ADS Schnittstelle vollkommen
in ADSARX aufgegangen ist.

------------------
Ing. Bernd Cuder
Cad&Co makes CAD easy

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

---

Und noch etwas,

die Entwicklungszeit und auch die Gründe die du unter ARX angeführt hast sind schlicht und einfach lächerlich, ich programmiere seit
einem Jahr auf ARX, und ich habe auch benutzerdefinierte Objekte
programmiert, aber ich bin heute auf ARX genauso schnell wie
vor einem Jahr auf VBA oder Lisp.

Vielleicht solltest du in ARX mehr programmieren als darüber zu schreiben, dann würdest vielleicht von 20-500? auf 5, oder wenn du
gut bist auf 2 runter kommen.

------------------
Ing. Bernd Cuder
Cad&Co makes CAD easy

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

---

Hi Bernd,

ich weiss nicht, warum das bei dir alles gleich so unfreundlich klingen muss: Es ist keineswegs lächerlich, sich über Entwicklungszeiten Gedanken zu machen - die bestimmen nun mal weitgehend den Preis von Software. Und bei einem Ferrari tun sie das ebenso. Ich nehme jetzt einfach an, du fährst einen, denn was er kostet, ist dir doch wohl egal - Hauptsache schnell!

Mir ist das nicht egal - deswegen fahre ich keinen, er ist mir zu teuer. Und auch bei der Entwicklung muss ich Abstriche machen. Wenn jemand z.B. ein automatisches Mittenkreuz in einer Bohrung haben möchte, dann kann ich ihm zwei Wege vorschlagen: In Lisp in zwei Minuten erledigt, oder ich baue ihm ein neues Entity 'Bohrung'. Da sitze ich einen ganzen Tag dran - ich muss ja erstmal einen Plan machen, welche Ofänge das Ding haben soll usw., die DXF-Schnittstelle festlegen, muss mir Gedanken über das Ding als Proxy machen, muss klären, wie die ARX mit den Zeichnungen mitgegeben werden kann usw. Und evtl. auch noch eine Setup-Routine machen.

Mag ja sein, dass die ARX-Bohrung zehn Mal so schnell ist wie die Lisp-Variante, aber wen interessiert das denn? Ein Konstrukteur, der 25 Bohrungen am Tag zeichnet, kann also eine halbe Mikrosekunde früher Feierabend machen? Aber den für die Finanzen Verantwortlichen wird es schon interessieren, ob für so etwas zwei Minuten oder ein ganzer Arbeitstag draufgehen.

Und die ADS-Schnittstelle ist in irgendwas aufgegangen? Eine neues Headerfile gibt es, in dem den ads_-Funktionen schöne neue Namen verpasst wurden, sonst hat sich nichts geändert. Alter Wein in neuen Schläuchen! Wie überall in AutoCAD stehen auch da unterschiedliche Ansätze aus unterschiedlichen Zeiten mehr oder weniger zusammenhangslos nebeneinander. Ich denke nicht, dass eine in ADS, also in Ansi-C(!) geschriebene neue Lisp-Funktion und eine in C++ programmierte objektorientierte Applikation, die die ObjectARX-Klassenbibliotheken verwendet, viel miteinander gemeinsam haben. Das sind nach wie vor zwei Welten, und ein Umbenennen der Funktionen ändert daran absolut nichts.

Ich denke, du solltest einfach nicht gleich mit Worten wie 'Blödsinn' und 'lächerlich' um dich werfen, wenn du anderer Meinung bist. Das disqualifiziert dich selbst, aber nicht meinen Text.

Gruss, Axel

------------------
http://www.tutorial.autolisp.info

http://www.advanced.autolisp.info

http://www.activex.autolisp.info

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

---

Falls ich unfreundlich geklungen habe tut mir das leid, wars sicher
nicht meine Absicht, also Entschuldigung.

Was in deinen Ausführungen immer wieder vorkommt ist, das ARX für
benutzerdefinierte Objekte da ist (siehe Bohrung).

Aber eben nicht nur, die Bohrung kann ich ebenso in ARX programmieren,
ohne gleich ein neues Objekt zu erzeugen, und das ebenfalls in
der selben Zeit wie in Lisp, vorausgesetzt ich habe Compiler, etc zur Hand.

Ich meine damit, wenn ich in Lisp ein Bohrungskreuz aus zwei Linien erzeuge, so kann ich das auch in ARX, und es sind auch nur zwei Linien. Und in ARX muß ich mich, im Gegensatz zu VBA, nicht mit so
Dingen wie transparente Menübefehle bei Eingabeabfragen herumschlagen.

Deine Beitäge erwecken denn Eindruck das man in ARX nur benutzerdefinierte Objekte erstellen kann, und diesen Irrtum wollte
ich hiermit aufklären.

------------------
Ing. Bernd Cuder
Cad&Co makes CAD easy

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