---

Hallo Insider!

Kann man mit VBA  Unterprogramme aus den AutoCAD- Aufsätzen (konkret LDDT- digitale Geländemodelle) aufrufen? Habe bisher nur lisp programmiert, komme da aber nicht weiter. Ich möchte mit LDT (Land development desktop) Profile erzeugen und diese in eine abgabereife Form bringen (Profile mit Stationstabellen). Habe das bisher per Hand gemacht, also Profile erzeugen, dann an signifikanten Richtungsänderungen senkrechte Linien nach unten fällen, Stationen (entspricht Längen im Straßenbau) und entsprechende Höhen über Ordinaten-Bemaßung antragen. Da ich jetzt 30-40 Profile auf die Art aufpeppen muß, wollte ich ein Programm schreiben das diese erzeugt und aufpeppt. Habe bisher Null Ahnung von VBA, würde mich aber reinknien, wenn es mir weiter helfen würde. Ist es das richtige Medium?
Ein unbeschriebenes VBA-Blatt

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

---

Ich habe leider keine Ahnung ob man auf LDT zugreifen kann. Vielleicht kann dir aber ein anderer aus diesem Forum weiter helfen.
Was VBA angeht, es ist sicher relativ leicht zu erlernen, schau dir aber einmal DIESEN Artikel an, ist sehr interessant zu lesen, vielleicht überlegst du dir dann ob du VBA noch lernen möchtest. 

------------------
Roland

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

---

Ich kann diesen Artikel nicht so gut finden - irgendwie hat er kein Thema. Er fängt mit den Perspektiven von VB an und schwenkt dann plötzlich zu C# und SharpDevelop um, und plötzlich geht es nur noch um die Installation von #Develop und die 10 Minuten, die das Bauen der Datenbank für die Completion dauert.

Jemand, der sich für oder gegen eine Programmiersprache entscheiden will oder muss, macht so eine Entscheidung doch nicht davon abhängig, dass er (ein!!)mal zehn Minuten den Rechner nicht benutzen kann. Ein Setup von Visual Studio ist jedenfalls auch nicht in 10 Minuten erledigt.

Aber mal zur Sache selbst: VBA hat wohl in der jetzigen Form sein Endstadium erreicht (6.2 in Acad 2004, 6.2 in 2005). Ich vermute, es wird auch im nächsten AutoCAD noch genauso drin sein - wieder 6.2. Aber ich habe kein Insider-Wissen, wer weiss. Vielleicht gibt es da auch eine kleine Überraschung, vielleicht gibt's doch noch 6.3 oder so.

Bei allem 'Da ist nichts mehr, wie es im alten VB war' des Autors - das stimmt zwar, aber ich kann nur sagen: Richtig so!!! Endlich wird aus dem krautigen, kauderwelschenden VisualBasic eine richtige, strukturierte Programmiersprache. Mein Lieblingsbeispiel: Die Zeiten, da man beim Öffnen 'irgendwas.open' und beim Schließen 'docmd close irgendwas' schreiben musste, sind vorbei. In VB.NET wird das, was man mit .open() aufgemacht hat, auch mit .close() zugemacht.

Richtig ist, dass VB.NET und C#.NET sehr viel Ähnlichkeit miteinander haben - die Syntax hat man in beiden Fällen recht schnell begriffen, viel aufwändiger ist es, den Gebrauch der .NET-Klassenbibliotheken zu erlernen. Das sind aber für beide Sprachen die gleichen (und natürlich für C++ auch). Auch da hat der Autor des Artikels Recht: Der Unterschied zwischen VB6 und VB7 (VB.NET) ist größer als der Unterschied zwischen VB.NET und C#.NET.

Zurück zum Ausgangspunkt: Was soll man denn jetzt lernen, wenn es darum geht, dass konkrete AutoCAD-Probleme gelöst werden müssen? Fangen wir bei Lisp an: COM wird in ein paar Jahren verschwinden, und ein Lisp für .NET wird es mit ziemlicher Sicherheit nicht geben. VisualLisp ist ja das Resultat des Einkaus von VitalLisp - aber ein DOTNET-Lisp steht derzeit nicht zum Verkauf. Lisp ist also Auslaufmodell - so schade ich das auch finde, denn mir ist es nach wie vor lieber als alles andere.

Wie es mit VBA weitergehen wird - keine Ahnung. Vielleicht gibt es ein VBA.NET mit ein paar festverdrahteten COM-Interop-DLLs, das übergangweise alte Techniken mit neuer Syntax ermöglicht (was natürlich ohne die Verdrahtung und ohne A im Namen jetzt auch schon prima funktioniert). Würde heissen: Man lernt jetzt den Umgang mit 'set', 'on error resume' usw., und nächstes Jahr wird alles anders, da gibt es kein 'set' mehr und kein 'error', dafür aber nur noch Klassen und Exceptions, und der 'Variant' ist auch endlich beerdigt. Ich kann mir auch beim besten Willen nicht vorstellen, dass MS das 'XXX for Applications'-Konzept aufgeben möchte. Da steckt doch zu viel 'Kundenbindung' drin.

Dann gibt es auch noch ObjectARX und C++. Aber: Es ist ungleich schwieriger als VB oder Lisp zu erlernen. Für einen Einsteiger eigentlich eher nicht zu bewältigen. Wer nie etwas programmiert hat, wird mit Lisp oder VBA schnell ein paar Erfolgserlebnisse haben, aber nicht mit C++/ARX.

Die wesentliche Information ist aber diese: So wie es aussieht, wird AutoCAD-Programmierung in Zukunft _IMMER_ ObjectARX-Programmierug sein. Das ist den meisten noch nicht klar! AutoCAD-Programmierung mit .NET geht immer über die ObjectARX-Klassenbibliotheken, und dabei ist es egal, ob man in C++, C# oder VB(.NET) programmiert. Wie gesagt: COM/ActiveX verschwindet demnächst.

Jetzt wäre es einfach zu sagen: 'Na, dann steige ich gleich richtig ein, lerne VB.NET und ObjectARX, das hat es Zukunft!' RICHTIG! Dummerweise hat es aber keine Gegenwart, den die in 2005 vorliegenden Klassenbibliotheken für AutoCAD sind halbgar und unfertig, auch wenn ein kleiner Teil von 2005 selbst schon damit entwickelt wurde. Aber wer möchte schon AutoCAD-Applikationen entwickeln, wenn es zwar ein getString() gibt, aber kein getInt(), kein getKword() und wie sie alle heissen? Und einen Punkt auf dem Bildschirm kann man auch nicht klicken. AutoCAD.NET ist schön für wissenschaftliche Zwecke, aber nichts für den praktischen Einsatz. Wem bringt es was, dass man jetzt in VB 'Custom Entities' erzeugen kann (ja, geht), aber erst das nächste AutoCAD (2006) die dann auch erkennen wird?

Fazit: Wer jetzt seine Probleme lösen möchte, hat viele Wege, die alle den Mangel haben, dass man viel von dem, was man gelernt hat, bald wieder vergessen kann. Fast jeder Weg hat aber auch seine Vorteile:

Lisp: Da muss man bald die Sprache selbst wieder vergessen und neu lernen, und die ganze COM-Schnittstelle auch. Vorteil: Der schnellste und einfachste Weg, kleine Probleme im Jetzt und Hier zu lösen.

VBA6: Auch da muss man bald die Sprache selbst wieder vergessen und neu lernen, und die ganze COM-Schnittstelle ebenso. Aber man lernt schon mal grundsätzliche Sachen wie Dialoge erzeugen usw., das ist auch in VB7 noch (fast) genauso.

VBA7 (VBA.NET): Über COM-Interop kann man AutoCAD etwa so programmieren wie bisher unter VB ohne A, und man lernt gleich das neue, aufgeräumte, bessere VisualBasic. COM muss man dann aber auch bald wieder vergessen. Negativ: Keine kostenlose Umgebung.

C#.NET: Es gilt alles, was ich zu VB.NET gesagt habe, mit dem Unterschied, dass es hier mit #Develop eine kostenlose, freie Entwicklungsumgebung gibt. Ausserdem hat C# in meinen Augen ein paar kleine Vorteile gegenüber VB, z.B. den Unsafe-Modus, d.h. Zeigerarithmetik, wie man sie von Ansi C kennt. Das ist in VB7 verboten - aber wenn es darum geht, zeitkritische Anwendungen für komplexe Zeichnungen zu schreiben, ist da sicherlich viel rauszuholen.

C++/ObjectARX: Schwierig, aber zukunftsbeständig. C++ geht zwar etwas zurück, ist aber Bestandteil von .NET und wird es weiterhin sein. Und die ARX-Bibos sind wohl das einzige, was sich in AutoCAD langfristig halten wird. Die eigentlichen ARX-Klassenbibliotheken werden zwar durch .NET-Klassen ersetzt, aber sie haben den gleichen Inhalt. Da ist nur mit minimalen Änderungen zu rechnen.

Na, das war doch mal wieder ein Roman;-)

Gruß, Axel

------------------

Meine AutoLisp-Seiten
Meine private Homepage
Mein Angriff auf dein Zwerchfell
Mein Lexikon der Fotografie
Mein gereimtes Gesülze
Meine Überzeugung...

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

---

Hallo Axel,
danke für deine Ausführungen, ich hatte eigentlich vor mir C++ anzueignen, es wurde mir daraufhin gesagt, es würde sicher ein Jahr dauern bis ich es annähernd verstehe. Und dann noch ObjectARX, das dauert noch mal ein paar Tage.
Angeblich wäre C# leichter zu erlernen und auch gleich ein Einstieg in C++. Was wäre deiner Meinung nach besser, gleich C++ oder vielleicht doch erst einmal C#?

------------------
Roland

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

---

@Alex

Guter Text !

@Roland

Deine VB Kentnisse sind sehr gut, so wird es für dich kein Problem sein C# zu erlernen. Aber wie der Alex schon gesagt hat, da ist im Moment recht wenig wo du es einsetzen kannst. Ich habe mir vor ca. 8 Wochen 3 Bücher über C# bei eBay gekauft ( ca. 2000 Seiten C# für 18 Euronen  ), aber beim Versuch das einzige sample aus Inventor SDK zu kompilieren, bin ich gescheitert, da der Code nicht OK war oder die Bibs fehlen, oder... Da, habe ich mal frustriert erstmal eine Pause eingelegt.

C++ ist sehr gut, aber nicht so recht mit VB zu vergleichen, daher würde ich mal sagen: Monat oder zwei C überfliegen, um das Gefühl dafür zu bekommen, und dann erst mit C++ anfangen.

------------------
Grüße daywa1k3r

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

---

Hallo daywa1k3r,
danker für deinen Ratschlag, hätte jemand auch Buchvorschläge, es gibt ja leider immer und überall gute und schlechte Bücher über ein Thema.

------------------
Roland

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

---

Also von den drei Büchern, dass ich gekauft habe, bin ich gleich beim ersten geblieben, da es recht gut geschrieben ist. Und das ist:

C#.NET
Verlag: BHV
Autor: Dr. Susanne Wigad
Taschenbuch - 768 Seiten

Ich habe glaube ich 3-4 Euro dafür gezahlt (neu - original verpackt), aber ich bin mir sicher dass es noch bessere Bücher zum kaufen gibt. Für mich hat es allerdings gereicht, so dass ich in die andere zwei kaum reingeschaut habe.

------------------
Grüße daywa1k3r

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

---

Roland,

ich gehe davon aus, dass du deine "Alltagsprobleme" erstmal weiterhin mit Lsip und/oder VBA lösen wirst und dich zusätzlich in neue Dinge einarbeiten willst.

Jetzt in C#-AutoCAD einsteigen, ohne Kenntnisse in C++/ObjectARX zu haben, ist ziemlich aussichtslos. Das ARX-SDK enthält Dutzende gute Beispiele zur ARX-Programmierung in C++ nach altem Muster, aber nur drei kleinere Beispiele in VB zu .NET/ARX (in einem davon wird auch kurz auf COM über Interop eingegangen). Beispiele in C#: Absolut null.

Zu C++/ObjectARX nach altem Modell gibt es einige Bücher, wenn auch nur englische, soweit ich weiss. Zu .NET/ARX/AutoCAD gibt es bisher auch nichts - kein Wunder, 2005 ist ja noch nicht so lange am Markt. Lass dich auch nicht davon täuschen, dass es Leute gibt, die sagen, sie haben auch schon AutoCAD 2004 mit .NET programmiert: Das ist ein Schaf im Wolfspelz, also COM-Programmierung wie in VB oder VBA oder auch Delphi, aber kein ARX.

Tja, was kann ich dir da raten? Ich selbst habe brauchbare C++-Kenntnisse und habe schon einige ARX-Projekte gemacht. Und ganz passable Java-Kenntnisse ebenso, deswegen ist der Einstieg in c# nicht allzu schwer - vieles hat da ja große Ähnlichkeit mit Java. Wenn ich mir aber vorstelle, ich hätte diese Kenntnisse nicht: Dann wär's wohl kaum lösbar.

Wenn du wirklich AutoCAD ohne COM programmieren willst, wirst du nicht umhinkommen, dich in C++/ObjectARX einzuarbeiten. Kauf dir ein gutes Buch (such mal in news.autodesk.autocad.objectarx) und zieh dir die Beispiele aus dem ARX-SDK rein. Parallel dazu würde ich trotzdem mit C# anfangen, ohne allerdings irgendwie was mit AutoCAD zu machen. Zur Sprache C# allgemein gibt es Bücher wie Sand am Meer und jede Menge Quellen und Beispiele im Netz. Im nächsten ARX-SDK wird es dann auch mehr als drei Beispiele geben, und sicherlich auch in C#.

Aber: Du würdest so einen Haufen Geld in VisualStudio investieren, denn ohne das geht nix mit C++. Und noch der Haken dabei: AutoCAD geht nur mit VS 2002, das aber gar nicht mehr zu kaufen ist. Du müsstest also 2003 kaufen und dann mit Bills Mannen über ein 'Downgrade' verhandeln. Jedenfalls geht das in die Tausende. Und das dafür, dass ich dir dennoch empfehlen würde, langfristig (d.h. wenn die AutoCAD.NET-Bibos fertig sind) doch auf C# umzusteigen? Es ist einfach so: C++ verliert an Existenzberechtigung, weil C# einfacher zu handhaben und damit wesentlich effektiver ist. Oder meinetwegen auch VB-Neu, da gilt das selbe. Wenn du demnächst einige Kenntnisse hast, wirst du merken, dass es ziemlich egal ist, ob die drei real existierenden Beispiele in VB oder C# vorliegen. Eine andere Syntax, aber inhaltlich wenige Unterschiede. Man kann sich natürlich auch für C++ entscheiden, aber es spricht wenig dafür. Beispiele, Newsgroups und andere Online-Resourcen sind auch deutlich weniger als in C# bzw. VB.NET vorhanden. Nicht ohne Grund entwickelt AutoDESK selbst plötzlich in C#. Ob der Layermanager nur mal ein Test war oder demnächst alles in C# entwickelt werden soll, weiss ich allerdings nicht. Bisher war's immer C++ (bzw. C in den ganz alten Zeiten, als noch Metaware High C und später Watcom C/C++ angesagt waren).

Wenn du also nicht mindestens 1600 Euronen hinblättern willst, hast du wahrscheinlich nur den Weg, 'erstmal so' in C# einzusteigen und allgemein zu lernen, bis ObjectARX 2006 kommt mit vollständiger .NET-Bibo und allen Beispielen in C# (hoffe ich doch, dass die das hinkriegen).

Theoretisch sollte es mit C++/ObjectARX allerdings auch kostenlos funktionieren: Die .NET-Compiler und Bibliotheken sind ja allesamt Freeware - Geld kostet nur die Oberfläche VisualStudio. Dann musst du du aber die Dialoge usw. allesamt von Hand im Notepad schreiben - sicherlich eine ***sehr*** sportliche Angelegenheit;-) Allein die Einarbeitung in die Makefiles dauert dann schon ein Vierteljahr:-(

Wenn du keinen Chef mit dickem Portemonnaie hast, würde ich das Geld nicht ausgeben. In ein paar Monaten werden dann auch Beispiel zu AutoCAD.NET im Netz herumschwirren. Also: Zieh dir SharpDevelop runter und fang einfach mit allgemeinen Sachen an. XML z.B. ist ein wunderbares Thema, da kann man eine Menge lernen, und in zwei, drei Jahren wird das auch in AutoCAD eines der Top-Themen sein. Und was AutoCAD-Jetzt betrifft: Weitermachen mit dem, was du hast und kannst.

Gruß, Axel

------------------

Meine AutoLisp-Seiten
Meine private Homepage
Mein Angriff auf dein Zwerchfell
Mein Lexikon der Fotografie
Mein gereimtes Gesülze
Meine Überzeugung...

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

---

Hey kann hier mal einer die U's Buttons um einen mit 100 bereichern?

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

---

Danke Axel,
#Develop hab ich schon installiert, die Oberfläche schaut ja erstmal nicht schlecht aus. Leider hab ich überhaupt keine Ahnung wie ich jetzt wirklich anfangen soll, darum die Frage nach einem Buch.

Wenn ich dich also richtig verstehe, dann fang ich mal mit C# an, C++ zahlt sich also nicht mehr so richtig aus (wenn man in die Zukunft schaut). Verstehe ich es richtig das man aber mit C# auch ObjectARX verwendet? Entschuldige diese Frage, aber ich bin wirklich Neueinsteiger in diesem Bereich.

------------------
Roland

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

---

Richtig, Roland. Die .NET-Bibos von AutoCAD sind nur Wrapper-Klassen für ObjectARX, d.h. nichts weiter als eine neue Verpackung der bisherigen ARX-Inhalte. Daran wird sich, so wie ich die Dinge sehe, auch in naher Zukunft nichts ändern, aber im nächsten AutoCAD kann man auch Custom Entities und Object Enabler in VB oder C# schreiben.

Du kannst aber mit C# über Interop auch an die COM-Schnittstelle gehen, das heisst, alles was mit VB(A) oder VLAX geht, funktioniert ebenso in C#. Aber nicht mehr ewig;-) Wie immer der Nach-Nachfolger von XP auch heissen wird, ich vermute, da wird COM irgendwo als 'Legacy' drinstecken. Aber ich bin kein Windows-Experte:-(

COM-Interop ist zwar schön zum Üben von C#, aber es bringt dich nicht viel weiter, weil da nichts ausser der Sprache C# ist, was du nicht schon aus VB oder VLAX kennst - es steckt ja die selbe TLB dahinter. Und die essenziellen Techniken, nämlich den Gebrauch der .NET-Klassenbibliotheken vermeidest du da nur.

Gruß, Axel

------------------

Meine AutoLisp-Seiten
Meine private Homepage
Mein Angriff auf dein Zwerchfell
Mein Lexikon der Fotografie
Mein gereimtes Gesülze
Meine Überzeugung...

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

---

Schön langsam kenn ich mich nicht mehr wirklich aus. Ist es richtig wenn ich mich jetzt mit C# beschäftige aber noch nicht versuche etwas mit Acad zu machen? Was ändert sich dann mit den .NET-Klassenbibliotheken?
Wenn ich jetzt versuche mich in C# einzuarbeiten habe ich es später dann aber leichter, oder muß ich dann wieder ganz umdenken?

------------------
Roland

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

---

Noch ein Nachtrag: Mit C++ ist das ja alles auch noch komplizierter, als es auf den ersten Blick aussieht. Es gibt da nämlich zum einen das alte C++ (mit dem auf die bisherigen und noch aktuellen ObjectARX-Funktionsbibliotheken zugegriffen wird), und dann das sog. 'Managed C++', das mit der .NET-Klassenbibliothek (und auch den Wrapperklassen von Acad) arbeitet. Unmanaged C++ ist das alte C++, das es auch schon in VS 6 gab, während Managed C++, VB7 und C# die drei Sprachen sind, die in die Intermediate Language übersetzt werden. Der Trick ist ja: Egal, welche dieser 3 Sprachen man wählt, der IML-Code ist der selbe. Unmanaged C++ erzeugt nur eine klassische EXE oder DLL, die unter Windows läuft. Die .NET-Sprachen hingegen erzeugen Dateien, die zwar ebenso EXE bzw. DLL heissen, die aber unter Windows gar nicht lauffähig sind - sie laufen nur in der CLR (Common Language Runtime) des .NET Framework.

Also, an alle Tester: #Develop alleine reicht natürlich nicht - man braucht auch das .NET-Framework (CLR zum Ausführen) sowie das .NET-Framework-SDK (da sind die Compiler drin). Ach ja, und jetzt fällt's mir ein: Das mit dem C++ kostenlos wird wohl doch nicht gehen, denn ich denke, der Compiler für Unmanaged C++ ist im SDK nicht mit drin, nur der für Managed C++. Aber das vermute ich jetzt nur:-(

Gruß vom Romaneschreiber

------------------

Meine AutoLisp-Seiten
Meine private Homepage
Mein Angriff auf dein Zwerchfell
Mein Lexikon der Fotografie
Mein gereimtes Gesülze
Meine Überzeugung...

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

---

jo, kompliment, das triffts wohl axel! ich für meinen teil stell mir dann aber erst mal die frage was ich eigentlich machen will.

ich bin konstrukteur und irgendwann werd ich nicht mehr bereit sein mir ständig tools in der freizeit zu schreiben nur damit ich mir einen vorteil verschaffen kann. zur zeit macht mir das spass, eher aus sportlichkeit aber der nutzen beschränkt sich auf eine kleine gruppe. das steht letztendlich in keinem verhältnis zum aufwand. die entwicklungsumgebungen sind ebend nicht für den amateur programmierer gedacht sondern für die leute die damit tagtäglich ihr brot verdienen.

ich persönlich folge dem axel vorschlag und in 2-3 jahren schaun wir dann mal.

in diesem sinne,
harry

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

---

Ich weiss, das ist kompliziert;-) Ganz ehrlich: Ich schreib ja solche Romane auch deswegen, weil es eine gute Methode für mich selber ist, die Dinge in *meinem* Kopf zu ordnen (Erklär' einem was, und du lernst selber am meisten dabei).

Also: Fang mit C# an, mach ein paar schöne Dialoge und versuch dabei, von den Bookstore-Bespielen usw. wegzukommen und was eigenes zu machen. AutoCAD kannst du vorerst aber nur über COM/ActiveX ansprechen wie bisher. Und, wie gesagt, befass dich mit Themen wie XML. Ich halte es für mehr als wahrscheinlich, dass man demnächst in AutoCAD z.B. die Inhalte von Dictionaries als XML kriegt. XML wird das DXF-Format ablösen, und dann gibt es keine Existenzberechtigung für die Gruppencodes mehr.

Wenn dann irgendwann Beispiele (von Anwendern) zu ObjectARX über die .NET-Bibos auftauchen, kannst du dich auch daran versuchen. Dann wirst du die schmerzliche Erfahrung machen, das ein einziges xxx.WasOpenForRead, das du vergessen hast, AutoCAD auf den Mond schießt;-) Aber das wirst du lernen... Beim nächsten AutoCAD wird's dann, wie gesagt, auch eine Doku und Beispiele zu C#-AutoCAD geben.

Vergessen musst du so jedenfalls gar nix, ausser das, was du über COM-Interop machst - das hat keine große Zukunft mehr. So einzusteigen, ist eine sichere und kostenlose Schiene.

Alles klar?

Axel

------------------

Meine AutoLisp-Seiten
Meine private Homepage
Mein Angriff auf dein Zwerchfell
Mein Lexikon der Fotografie
Mein gereimtes Gesülze
Meine Überzeugung...

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

---

@Axel: Alles klar, jetzt fang ich einmal an ein wenig zu lesen und dann werd ich mal weiterschaun.

@Harry: Auch ich programmiere eigentlich nur zum Spaß, es interessiert mich einfach sehr. Es ist immer schön, wenn man sich für manche Dinge ein kleines Programm so auf die Schnelle schreiben kann. Leider stößt man mit VBA irgendwann an Grenzen. Seien es Reaktoren oder z.B. das Curve-Objekt, das es in VBA leider nicht gibt, bei VB.Net und dem Autodesk SDK aber sehr wohl (hab ich zumindest gehört). Und das sind die Dinge die mich nun reizen würden.
Wir, ein Kollege und ich, haben (fast) unser ganzes Büro auf unsere arbeitsweise und unsere Tools umgestellt, es wäre schön, wenn ich nun, wieder aus Spaß, neue nützliche Tools schreiben könnte. Und da hab ich immer ein paar Ideen  .
So wäre C# einen neue Herausforderung, es ist zwar nicht so das ich mich in VB so gut auskennen würde, aber ich wollte immer schon ein wenig mehr als nur VBA können. Darum meine Fragen.

------------------
Roland

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

---

hi roland,
neee, deine fragen sind schon völlig berechtigt, ich wär ja sonst nicht auch hier. aber axels 'romane' lassen mich dann doch erstmal darüber nachdenken ob es für mich sinn macht einen 2. beruf zu lernen um einen anderen schneller ausführen zu können!?! ehrlich, ich raff nix von dem was er da schreibt, will ich auch nicht müssen. aber vielleicht hört es sich auch nur komplizierter an als es werden wird. solange ich noch mit alt+F11 was gestartet bekomme wo ich code reinkloppen kann auf nen button gelegt bekomme ist's ok für mich.

aber unabhängig von der programmiersprache werden auch die cad programme besser oder es kommen neue auf den markt. wenn ich das so betrachte verwenden wir autocad nicht weil es so toll ist (eher nicht...) sondern eher weil hinz und kunz (glaubt) damit umgehen zu können, und es seltsamerweise auf jeden 2.rechner dieser welt installiert ist... und dabei gibt es ohne frage bessere.

weiterhin viel erfolg!
harry

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

---

Es gibt bessere, welche denn, ich hab mich da noch nicht so sehr erkundigt. Im 3D Bereich finde ich ja Rhino nicht so schlecht.

------------------
Roland

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

---

ist rhino nicht sowas wie 3ds max? kenn ich jetzt nicht aber wenn ich mir die möglichkeiten der 'blöcke' in max ansehe werd ich wahnsinnig weshalb es das nicht in ac gibt. überhaupt ist die technik des modifikatorstapels ne feine sache.

hab mal nen bisschen mit inventor rumgespielt, sagenhaft - nur leider doof in der gebäudetechnik/anlagenbau, wegen kompatiblität. kein architekt will mir ein gebäude im inventor format liefern. ein kollege von mir arbeitet mit solid edge und macht stahlbau darauf, sagenhaft schnell - glaub nicht das er nen layermanager benötigt..., überhaupt hat der weniger icons aufm bildschirm.

ich denke in diese richtung gehts, diese programme sind jetzt noch der mechanik vorbehalten, aber irgendwann wird es sich auch für andere branchen durchsetzten.

gruss, harry

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

---

So meinst du das, deine Beispiele sind aber auch von Autodesk bzw. Discreet und auch Branchenspezifische Lösungen, oder nicht?

------------------
Roland

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

---

ok, autodesk stimmt, leider bekomme ich auch nur hin und wieder mal ne anlage in die finger an der ich was ausprobieren kann -> autodesk, verbreitung...

aber solid edge ist jetzt keine stahlbau applikation, eher mechanik generell. (zur verteidigung: ich denke beim 2d elektro schema wird s.e. versagen) branchenspezifisch hin oder her, die cad-technik ist halt eine ganz andere und mit wenigen eingaben kann ich abhängigkeiten durch formeln bestimmen für die ich lange code stricken müsste. ob ich jetzt stahlträger, lüftungskanäle, rohrleitungen oder möbel erstellen möchte. der software ist's egal.

so denne, bevor wir aufgefordert werden das forum zu wechseln ;-)
harry

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

---

Auf die Idee käme ich nie. Ich habe mich aber wieder einmal über die Anregungen in diesem Beitrag gefreut. Ich wünsche euch noch einen schönen Tag. Ich werde mich nun nach Hause begeben.

Bis morgen

------------------
Roland

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

---

Zitat:

---

Original erstellt von RoSiNiNo:
Ich habe leider keine Ahnung ob man auf LDT zugreifen kann. Vielleicht kann dir aber ein anderer aus diesem Forum weiter helfen.
Was VBA angeht, es ist sicher relativ leicht zu erlernen, schau dir aber einmal DIESEN Artikel an, ist sehr interessant zu lesen, vielleicht überlegst du dir dann ob du VBA noch lernen möchtest.  

---

DANKE! Habe mir den Artikel runtergeladen und werd ihn mir jetzt reinziehen. Sonja

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

---

Danke für den tiefen Einblick, Axel. Ich bin zwar jetzt etwas irritiert, unentschlossen schwankend. Aber immerhin weiß ich jetzt in den ersten Zügen um die Möglichkeiten. Auch wenn es vielleicht (gewiss!) nicht für die Ewigkeit ist, so schadet es nicht, eine Programmiersprache mehr zu kennen. Danke für den Einstieg.
Sonja

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

---

Tag zusammen.

Das ist mein erster Beitrag im VBA-Forum und das mit gutem Grund. Ich habe kaum nennenswerte Kenntnisse in VB(A) und was sollte ich dann hier. Nun bin ich allerdings auf diese Thema aufmerksam gemacht worden und möchte ein paar ergänzende Zeilen zum Besten geben:

(1) Axel:

Deinen Ausführungen ist kaum etwas hinzu zu fügen. Ausgezeichnete Übersicht über die Möglichkeiten und Änderungen die uns erwarten! Wenn überhaupt, dann kann ich nur anmerken, dass der in 2005 eingeführte Layermanger zwar im .NET-Framwork erstellt wurde, aber ob unbedingt in C# weiß ich nicht zu sagen. Allerdings hast du ja auch deutlich gemacht, dass dieser Umstand keine Rolle spielt, weil alle .Net-Sprachen den gleichen Code in der Intermediate-Language erzeugen und damit nach eigenem Gusto gewählt werden können.

Hierzu gehört übrigens auch Delphi.NET, die meines Wissens bisher einzige Sprache für's .NET-Framework, die nicht von Microsoft entwickelt wurde. Sie wird aber sicher nicht die einzige bleiben, aber das wird erst die Zukunft zeigen ..

(2) Integrierte Entwicklungs-Umgebungen (IDE):

Neben den beiden bereits erwähnten IDEs (#Develop und Visual Studio) gibt es noch den C#-Builder von Borland. Der ist insofern des Bemerkens wert, weil es von ihm eine kostenlose Personal-Variante (für den nicht-kommerziellen Einsatz) gibt, die (bisher) deutlich ausgereifter daher kommt als #Develop, aber im Gegensatz zu ihr kein VB.NET unterstützt - das tut #Develop nämlich.

Bei #Develop ist auch zu beachten, dass hier der Umfang des .NET-Frameworks um eine ZIP-Bibliothek erweitert wurde, die unter der GPL (genauer unter einer GPL-Abart - sollte genau angesehen werden, wenn diese Teile in Kommerziellen Programmen Anwendung finden sollen) steht.

Beobachten könnten wir auch noch die Entwicklung unter eclipse. Sicher wird es auch hier in absehbarer Zeit - wie bereits für eine Fülle Programmierspacher zuvor - vollwertige Plugins für die eine oder andere .NET-Sprache geben. Diese IDE hat den bestechenden Vorteil, für alle unterstützten Sprachen grundsätzlich den gleichen Rahmen zur Verfügung zu stellen und durch das Plugin-Konzept beinahe beliebig ereweiterbar zu sein. Auf alle Fälle einmal ansehen! Schließlich ist's ebenfalls OpenSource und für diverse Sprachen der IDE-Standard bei (und von) IBM.

(3) Zukunfts-Sicherheit:

Oh-je - ich bin Anwendungs-Entwickler und kein Prophet, aber eines kann ich nicht deutlich genug unterstreichen: In unseerem Metier ist nichts beständiger als der Wandel!

C++ ist Anfang der 90er-Jahre die Standard-Spreche für Windows-Entwicklung und hat seine Verbreitung wohl in erster Linie auch diesem Umstand zu verdanken. Diese Sprache und die damit verbundenen Konzepte haben also über 10 Jahre gehalten. Was wollen wir eigendlich mehr? Jetzt deutet sich eben ein neues Konzept an und - da kann ich Axels Einschätzungen nur wiederholen - .NET wird das kommende Framework für die Software-Entwicklung unter Windows bilden. Da können wir uns eigendlich glücklich schätzen von Anfang an dabei zu sein und hoffen, dass dieses Konzept ebenfalls 10 Jahre halten wird.

Was ich bereits das eine odere andere Mal erwähnte, hier aber dennoch wiederholen möchte ist: Genaue Kenntnis einer Programmiersprache besitzt einen sicherlich nicht zu unterschätzenden Stellenwert, ist aber zu vergleichen mit der genauen Kenntnis eines Werkeugs im Handwerk. Irgendwann gibt's eben andere Werkzeuge und die alten verschwinden. Kenne ich nur das Werkzeug, dann bin ich raus aus dem Geschäft. Anders sieht es aus, wenn ich die Prozesse und Strukturen verstehe, die sind nämlich unabhängig - naja zumindest zu großen Teilen - vom Werkzeug, das ich benutze. Die einzige Art von Wissen, die m.M. nach eine Chance hat etwas länger zu halten ..

(4) Bücher und Resourcen:

- Sehr gut gefallen hat mir Programmieren mit C# - Jesse Liberety, O'Reilly. Das Buch betet nicht noch einmal die .NET-Klassen-Stuktur herunter, um seine gut 650 Seiten zu füllen, sondern gibt einen ordendlichen und gut verständlichen Überblick über die Möglickeiten und Konzepte von C#. Darüber hinaus ist es auch für nicht allzu fortgeschrittene Programmierer noch verdaulich.

- Nicht leicht verdaulich, dafür aber grundlegend ist das Standardwerk der 'ProgrammierKunst': The Art Of Computer Programming (Bände 1-3) - Donald E. Knuth, Addison Wesley. Wurde allerrdings nicht ins Deutsche übersetzt und kostet ein Heiden-Geld (ist bei Büchern, gerade auch im Verhältnis zu den IDEs aber zu vereschmerzen - denke ich).

- Die .NET-Dokumentation von Microsoft ist zwar als Online-Doku konzipiert, aber - von den üblichen Abstichen mal abgesehen - duchaus gelungen. Also auch, wenn's kein Buch ist sehr hilfreich und wird mit dem .NET-Framwork installiert und steht in den IDE's die ich ausprobiert habe dann auch zur Verfügung.

- Vielleicht weiß der eine oder die andere hier noch was News-Groups sind ;-) - für all diese Leut' sollte sich ein Blick oder Post in der unten lohnen. Die gibt's sicher auch für VB.NET und Manged C++.

microsoft.public.de.german.entwickler.dotnet.csharp

Achim Dabrunz

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