Hi Christian,
mal zu den 'kleinen' Fragen:
>> dass das für zukünftige Versionen nicht mehr verfügbar ist
Es gibt durchaus Anzeichen, dass VBA in näherer Zukunft sein Ende hat. Z.B. in AutoCAD 2010 gibt es VBA nicht mehr im Package drin, sondern getrennt downloadbar und installierbar. VBA ist auch nicht mehr wirklich 64bit-tauglich, soll heissen mit AutoCAD 2010 64bit bekommst Du eine Performance, die unvergleichlich langsamer ist als die der 32bit-Version. Da kann auch Autodesk nichts dafür, das ist Micrsosoft-bedingt.
>> Projekte wie das mit den Blöcken, macht es da überhaupt Sinn auf VBA etwas zu machen
Normalerweise lese ich erst ganze Pflichtenhefte, um zu beurteilen, ob etwas besser mit SCRIPTING, LISP, mit VBA, mit dotNET oder mit ARX umzusetzen ist. Obige Frage 'Projekte wie das mit den Blöcken' ist ein wenig kurz für eine tatsächliche Beurteilung. Diese eine detaillierte Frage läßt sich mit VBA (fast) genauso umsetzen wie Dir Udo mit LISP gezeigt hat.
>> Wie geläufig ist AutoLisp (zukünftig)
Das wird Dir nur Autodesk beantworten können. Ich kann nicht für Autodesk sprechen, aber vielleicht meine Gedanken dazu äussern:
Autodesk ist sich sehr bewußt, dass der Erfolg von AutoCAD an der Flexibilität/der Programmiermöglichkeit hängt. Ab der Einführung von LISP als (relativ leicht zu erlernende Sprache) begann sich AutoCAD von den anderen entstehenden CAD-Systemen immer deutlicher abzuheben. Es gibt extrem viel bestehenden Code in LISP (bei Anwendern und auch bei Applikationsentwicklern) und zu riskieren, dass diese alle plötzlich 'bodenlos' dastehen, würde auch Autodesk ohne langsame Überleitung zu einer ähnlichen Alternative kaum durchführen können.
>> Kann mir jemand kurz erklären was ich mir unter dem .NET vorzustellen habe
'Kurz erklären' ist nicht, da musst Du Dich schon einlesen und der Editor hier (wo ich gerade tippe) und die Zeit lassen es auch nicht zu, da jetzt im Detail einen Vortrag zu halten. Ich versuch's oberflächlich und hoffe, dass das für Dich ausreichend ist.
Die Basis von dotNET-Programmierung ist zum einen dotNET-Framework und damit verbunden CLR und JIT.
Der Ablauf in der Programmierung ist dann:
- Du schreibst Deinen Code
- Du kompilierst Deinen Code, dieses Kompilieren erzeugt aber nicht direkten MachineCode (also bereits auf Prozessorarchitektur ausgerichteten Code) sondern ein CLR-Abbild.
- Startest Du jetzt das CLR-EXE (oder DLL), dann wird eigentlich zuerst in Deinem Rechner aus dem Framework ein Compiler gestartet (JIT), der es für Deinen aktuellen Prozessor nochmals kompiliert.
Der Vorteil ist dann, dass je nach Prozessor diese Form der Kompilierung auf Deinen Prozessor abgestimmt optimierten MachineCode generiert. Hauptsächlich macht sich das bemerkbar, dass (im Normalfall) Du als Programmierer gar nicht mehr darauf achten musst, ob der Anwender auf einem 64bit oder auf einem 32bit-Betriebssystem arbeitet, ob der Anwender 1 oder mehr Prozessoren/Prozessorkerne enthält (wenn Du MultiThreading-Applikationen schreibst). Du schreibst beispielsweise Deinen Code auf 32bit-Basis/DualCore und der Anwender eines 64bit-Systems/QuadCore startet Dein CLR-EXE und hat eine 64bit-Applikation und fertig.
Betonung aber dabei: schön wär, wenn das immer so auch funktionieren würde.
>> Wo ist der Unterschied zu ObjectARX
Unterschied wozu? Zu LISP? Zu VBA? .... 
Ich nehm mal an (meine Glaskugel deutet es mir), Du meinst Den Unterschied zu C#. 
- in der Zeit, die Du zum Programmieren und zum Testen brauchst ==> 95% (soll heissen, mit dotNET bist Du brauchst Du nur 5%-10 der Zeit für Entwicklung/Test und Debugging verglichen mit C++)
- in der Technik: für jede Betriebssystemart eigenes Kompilieren/Testen/Debuggen (32bit/64bit)
- in der resultierenden Performance: ein wenig schneller als dotNET, aber nicht um Faktoren (abhängig von 'was wird gemacht')
- deutlich mühsamer in der Gestaltung der Benutzerführung, mit dotNET hast Du Formulareditor-Funktionen, die im C++ (ObjectARX) erstmal mühsam programmiert werden müssen.
So, das war's jetzt mal oberflächlich, ich hoffe es hilft! Detailfragen jederzeit und gerne, aber bitte nicht so globale 'Was ist ObjectARX', denn da gibt es doch genug Literatur im Internet.
- alfred -
------------------
www.hollaus.at
Foren auf CAD.de (alle Foren)
| 
