---

Hallo !

Seit jeher hat DXF bei uns in der Vermessung eine Rolle gespielt, als wir seinerzeit noch unter DOS viele Fremd-Zeichnungen einzuarbeiten hatten, die wir in den unterschiedlichsten ACAD-Versionen, teilw. sogar ohne DXF-Header bekamen. Da wir daraus aber nur bestimmte Objekte und nur in unserer Block- und Layer-Struktur brauchen können, war es außer den Problemen der verschiedenen Datei-Varianten auch unangenehm, uns jedesmal unsere Zeichnungen mit Fremd-Struktur zu versauen, deren Bereinigung nachher oft mühsam war.
Ich hatte daher damals eine Lisp-Funktion gestrickt, die im beliebigen DXF (SECTION ENTITIES) alle typischen Objekte im gewünschten Koordinaten-Fenster liest, sie jedoch nicht in ihrer Fremd-Struktur, sondern gleich in unserem Format in unsere Zeichnungen einfügt.
Andererseits wurde/wird von unseren Kunden auch verlangt, eine Zeichnung als DXF zu liefern.
In unserer Branche geht es beim Kataster ja u.a. um Eigentümer, deren Namen eben auch Sonderzeichen enthalten können/müssen. Im wesentlichen handelt es sich um "¹, ², ³, Ä, Ö, Ü, ä, ö, ü, ß", wobei der Daten-Erhalt wichtiger als die Darstellung per Stil und Font ist.

Nach Windows XP stelle ich nun mit Win7-64 fest, dass sowohl AutoCAD (2011) alsauch BricsCAD (V12) beim Erzeugen einer DXF-Datei (DXFOUT, Export od. Speichern als) dies in einem Format tut, das zwar problemlos wieder von der CAD-Software aufgerufen wird und die Zeichen auch richtig dargestellt werden. Notepad++ zeigt dann an, dass es sich um "UTF-8 ohne BOM" handelt und wenn Lisp per (read-line) oder FSO + "OpenAsTextStream" in einer solchen Datei liest, werden die Sonderzeichen falsch interpretiert. Wurde jedoch per (write-line) in ein Text-File geschrieben, liefert (read-line) die Original-Zeichen korrekt zurück.

Ich suche nun nach einer Lösung, um mit diesem Verhalten künftig umgehen zu können, ohne eine DXF-Datei manuell z.B. mit Notepad++ zuerst nach ANSI konvertieren zu müssen.
1.)
Gibt es eine Möglichkeit, aus Lisp heraus festzustellen, um welches Format es sich bei einer Text-Datei handelt?
2.)
Gibt es einen simplen Befehlszeilen-Konverter, der aus der Lisp-Funktion per (startapp) aufrufbar ist?
3.)
Ist in einer jüngeren BricsCAD-Version (auf die wir planen umzusteigen) eventuell dieses Problem bereits behoben, in dem dort Lisp das Format erkennt und richtig interpretiert?

Vielen Dank, Arcuso

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

---

Zitat:

---

Original erstellt von Arcuso:
... 3.)
Ist in einer jüngeren BricsCAD-Version (auf die wir planen umzusteigen) eventuell ...

---

Falls Ihr umsteigt, dann könntest du die PRO-Version nehmen. Mit der ist die .Net-Schnittstelle nutzbar. Dort wiederum kann man beim Lesen von Textdateien die Codierung angeben.

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 !

Ob ich mir das mit .Net noch antun soll? Nachdem ich unsere Lisp-Tools alle angepasst und fit für eine BricsCAD V?? gemacht habe, wollte ich eigentlich in Pension gehen.

Meine V12 ist sogar eine Pro, es wird ja m.W. mit .Net eine DLL erstellt. Muss die dann nicht wie ARX binär-kompatibel mit der CAD-Software sein?
Wer kompiliert die dann nach mir um, wenn im Büro eine neue Version installiert wird. Ich möchte unsere Tools so universell wie möglich anlegen, dass sie sogar unter AutoCAD wie bisher (2005) laufen würden.

Ein schweres Argument für .Net wären allerdings zeitgemäße Dialogboxen. Ich habe mich bisher wenig für die Sache interessiert und müsste da bei Null beginnen. Der Aufwand ist ja sicher erheblich größer als bei Lisp, bei dem ich seit R2.5 die Funktionen besser gekannt habe als die AutoCAD-Befehle. So ein Learning By Doing wird mit .Net wohl nicht möglich sein. Was wären eigentlich die Voraussetzungen dafür, wo kriegt man's her und was kostet's?

Grüße Arcuso

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

---

Zitat:

---

Original erstellt von Arcuso:
... Ob ich mir das mit .Net noch antun soll? Nachdem ich unsere Lisp-Tools alle angepasst und fit für eine BricsCAD V?? gemacht habe, wollte ich eigentlich in Pension gehen. ...

---

Ich weiß zwar nicht, wann der Zeitpunkt der Pensionierung ist, aber ich wünsche es dir.

Zitat:

---

Original erstellt von Arcuso:
... mit .Net eine DLL erstellt. Muss die dann nicht wie ARX binär-kompatibel mit der CAD-Software sein?
...

---

Mit .Net werden nur vorkompilierte DLL's geschrieben. Schau mal auf Wikipedia, da ist das Zusammenspiel sehr gut beschrieben und illustriert.

Zitat:

---

Original erstellt von Arcuso:
... Wer kompiliert die dann nach mir um, wenn im Büro eine neue Version installiert wird. Ich möchte unsere Tools so universell wie möglich anlegen, dass sie sogar unter AutoCAD wie bisher (2005) laufen würden. ...

---

Keine Ahnung, wer das dann kompiliert. ;-) Zum Laufen unter BricsCAD und AutoCAD kann ich nur sagen, dass wir in unserem Haus eine eigene Projektvorlage erstellt haben, mit der wir die DLL's sowohl für AutoCAD (2008..2015) als auch für BricsCAD (V14) aus demselben Code generieren. Stichwort hierfür ist die bedingte Kompilierung. Soll heißen: Solange die API die Objekte gleich benannt zur Verfügung stellt, kann man beim Kompilieren festlegen, ob die API-DLL's von BricsCAD oder von AutoCAD verwendet werden sollen. (In Ausnahmefällen regeln wir die Programmunterschiede über die Reflection) Geht also ohne  nennenswerten Aufwand(zumindest, wenn man es erst einmal sauber eingestellt hat).
Unser ProjektTemplate beinhaltet zum Beispiel auch schon die Funktionen, die notwendig wären, wenn ein Tool in der Massenverarbeitung eingesetzt werden sollte. Ich sehe wahrlich mehr Vorteile und keinesfalls einen Verlust an Performance, was die Programmerstellung angeht.
Im übrigen kann man streiten, ob denn 2005 wahrlich noch zeitgemäß ist. Wie lange wird das noch im Einsatz sein? (Läuft das überhaupt noch auf den aktuellen Betriebssystemen?)

Zitat:

---

Original erstellt von Arcuso:
... Ein schweres Argument für .Net wären allerdings zeitgemäße Dialogboxen....

---

Die Dialogboxen sind nur ein ganz winziger Aspekt (ich vermeide Dialogboxen wo es nur geht, da die meisten meiner Kunden ohnehin keine wollen, da diese eine 'flüssige' Programmbedienung in der Befehlszeile verhindern.) Viel wichtiger sind die Möglichkeiten, die dir sonst noch offen stehen. Das wäre die Benutzerführung durch die Verwendung von JIG und die wahnsinnige Geschwindigkeit.
Wenn Anbindung von Datenbanken /Excel/ ... ein Thema wären ... dann gibt's eigentlich keinen Grund mehr, bei Lisp zu bleiben.

Zitat:

---

Original erstellt von Arcuso:
...Ich habe mich bisher wenig für die Sache interessiert und müsste da bei Null beginnen. Der Aufwand ist ja sicher erheblich größer als bei Lisp, bei dem ich seit R2.5 die Funktionen besser gekannt habe als die AutoCAD-Befehle. ...

---

Das sehe ich inzwischen anders. Mit Lisp verschleudert man einen Haufen Zeit damit, die irgendwann einmal programmierten Funktionsbausteine wieder zu finden. Man muss extrem ordentlich sein, was die Code-Organisation angeht. Das Überladen von Funktionen ist nicht möglich. Für die gleiche Aufgabe mit unterschiedlichen Parametern muss man eine eigene Subroutine benennen. Da die Übersicht zu behalten ist wahnsinnig schwer.
Wir haben unsere .Net-Funktionsbibliothek so organisiert, dass diese nur in die aktuellen Projekte verlinkt ist. Wir können also aus einem laufenden Projekt jederzeit Subroutinen (von denen wir meinen, dass diese allgemein gültig sind) in die Bibliothek verschieben. Gleichermaßen steht diese ab diesem Zeitpunkt in allen (alt wie neuen) Projekten zur Verfügung. Die Sensitive-Hilfe, zeigt zudem die Kommentare an, die aus der Code-Dokumentation gebildet werden. Also auch bei Funktionen, die ich vor 2 Jahren geschrieben habe, wird mir (wenn ich diese Verwenden wollte) direkt der Hilfetext angezeigt. Die Möglichkeit des Überladens von Funktionen führt zudem dazu, dass man nur mit wenigen Funktionsnamen hantieren muss. Wiederum mithilfe der Sensitive-Hilfe werden die Hilfetexte zu den einzelnen Funktionsparametern angezeigt .. ich muss nicht mehr alles wissen, sondern nur sauber dokumentieren. Da letzteres sowohl in Lisp als auch .Net eigentlich gemacht werden sollte, sehe ich alleine in diesem Punkt einen wahnsinnigen Vorteil, von Lisp zu wechseln.

Zitat:

---

Original erstellt von Arcuso:
...So ein Learning By Doing wird mit .Net wohl nicht möglich sein. Was wären eigentlich die Voraussetzungen dafür, wo kriegt man's her und was kostet's?

---

Ich empfehle dir eine Schulung, die dich in's Thema bringt. (gerne auch bei mir) Du kannst programmieren, also ist für dich lediglich die neue Syntax zu erlernen. Das Objektmodell sollte dir bekannt sein, und das ist auch in der .Net-API so abgebildet wie in Lisp - nur noch leichter zugänglich, weil man sich für die neuerlichen Funktionsverbesserungen nicht mehr durch die Dictionaries hangeln muss.
Voraussetzungen sind ein VisualStudio. Die Express-Edition kostet nichts, würde ich aber nicht empfehlen. Um aber einzusteigen und zu schauen, kann man damit warm werden, langt die auf jeden Fall. Alles Andere bringt entweder das Betriebssystem oder das Programm mit, für welches du programmieren möchtest.

Bei 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

---

Hallo Holger !

Vielen Dank für den ausführlichen Kommentar.
Die Sachlage ist die:
Als ich vor ca. 15 Jahren im Vermessungsbüro begonnen habe, war ich mit allerlei selbstgestrickten Lisp-Tools meines Vorgängers konfrontiert, die ich zuerst je nach Bedarf angepasst, verbessert oder erweitert habe. Da aber im Büro kein konzentriertes Arbeiten möglich war und mir meine eigene Maschine mit bereits vorhandenen Tools, Editoren in gewohnter Umgebung weit sympathischer ist, mache ich das bis jetzt daheim autodidaktisch. Als Idealist spielt Zeit wenig Rolle.
Im Büro musste man durch die Euthanasie von Windows XP auf den neuen Rechnern das alte AutoCAD 2005 mit den alten Lisp-Tools in einem XP-Fenster am Leben erhalten, um weiter produktiv sein zu können.
Bis vor 2Jahren war ja noch nicht klar, ob bei einer Aktualisierung der Software (10 Arbeitsplätze) nicht gleich auf BricsCAD umgestiegen werden soll. Außerdem gibt es für die Vermessungs-Branche wenig CAD-Aufsätze, die zudem noch die österr. Vermessungs-Verordnungen erfüllen können.
Meine Aufgabe war es bisher BricsCAD entsprechend zu testen (V11, jetzt V12), jedoch auch eine jüngere AutoCAD-Version (2011) nicht ganz zu ignorieren. Gleichzeitig bin ich dabei ca. 2500 (!) Lisp-Funktionen und Befehle auszumisten, zu aktualisieren oder zu verbessern. Diese Masse ist im Laufe der Jahre entstanden, weil durch individuellen Bedarf neue Funktionen dazukamen, es im Büro niemanden gab, der die Rechner auf einen einheitlichen Stand der Tools gebracht hätte bzw. die Kollegen befragt hätte, ob dieses oder jenes überhaupt noch gebraucht und verwendet wird. Um nicht bestehende Funktionen zu vermurksen, kamen halt immer neue hinzu, auch wenn sie zigfach fast das selbe machen.
Das Problem besteht nach wie vor, dass im Büro, obwohl stark abhängig davon, CAD viel zu wenig Beachtung beigemessen und Zeit für dessen Pflege zugestanden wird.
Selbst wenn ich denen ein picobello Tool-Paket mit eigener Benutzeroberfläche zaubern würde, wären sie nach mir bald verloren, weil's niemandenden gibt, der das weiterpflegen würde.
Man nimmt sich ja nicht einmal die Zeit, den jüngst angebotenen Aufsatz "GeoSI" zu testen.
Daher hält sich bei mir auch die Lust in Grenzen, mir nun auch noch eine andere Programmiersprache reinzuziehen. Wenn ich jede Stunde, die ich in diese Dinge bereits investiert habe, in die Waagschale würfe, wäre ich ja längst schon in Pension.

Kondolenzen sind trotzdem nicht notwendig.

Grüße Arcuso

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

---

Hallo Arcuso,

die von dir beschriebene Situation ist leider in sehr vielen Büros so oder so ähnlich.
Inzwischen habe ich es sogar geschafft, Rahmenverträge mit Büro's zu schließen, bei denen die Mitarbeiter auf Zuruf von mir programmieren lassen können. Dort haben die Chef's sich die Zeit genommen und sich an ein paar Beispielen zeigen lassen, was es an Zeiteinsparung bringt, und was die Programmierung im Gegensatz gekostet hat. Und egal wie so mancher Chef drauf ist, rechnen können sie alle - die Schwierigkeit ist nur, das offene Ohr dafür zu finden.

Ich gehe davon aus, dass du ausreichend Fantasie hast, was deine Programme an Mehrwert haben. Manche Chefs lassen sich auch damit überzeugen, dass Sie in den Angeboten einen Mehrwert formulieren können, der höher bewertet sein kann, als es an Aufwand mit einem Tool bedeutet. Auftraggeber sehen das auch sehr gern, wenn Ihnen ein sinnvolles Mehr geboten wird, was nicht so sehr in's Budget rein haut. Mitunter sind das kleine Punkte, die den Ausschlag dafür geben, ob man den Auftrag erhält oder auch nicht.

Ich würde versuchen in diese Richtung zu gehen, und deinen Chef versuchen zu überzeugen, dass die CAD-Admin-Stelle nicht nur notwendig ist, sondern sich auch rechnet. Du kannst ja nur mal zum Spaß, die existierenden Tools von den Rechnern nehmen - schon hast du 10 Befürworter. ;-)

In diesem Sinne!

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 !

Mehrwert ist gut! Mir persönlich wäre es ja viel lieber, wenn man einen Geodäsie-Aufsatz für BricsCAD investiert und ich mich nur mehr mehr auf die Sonderwünsche konzentrieren brauche, die von der Software nicht abgedeckt werden (spezielle Strukturen für Bahn, Autobahn, Hochbau etc.), was ja meine ursprüngliche Aufgabe war.
Wenn man sowas brauchte, war ja der Auftrag schon da und deshalb Feuer am Dach. Meistens habe ich die Funktionen dann so zwischen Freitag Mittag und nächsten Montag geliefert. Sowas wird aber geringgeschätzt und kann nicht viel Arbeit gewesen sein, weil viele sich gar nicht vorstellen können, dass jemand nach Feierabend noch bereit ist, produktive Handgriffe zu leisten. Insofern gebe ich mir fast selbst die Schuld, diese Einstellung ja noch zu fördern und es wäre vielleicht besser gewesen, für jede Zeile Lisp-Code sofort die Hand aufzuhalten.
Tatsächlich es ist mir auch nur möglich gewesen, da ich 230km Entfernung vom Büro wirke und nicht dem täglichen Unwillen mancher Mitarbeiter ausgesetzt bin, die sich als Anwender bezeichnen und gar nicht erst konstruktive Gedanken aufkommen lassen.
Im Moment findet der Austausch in Sachen CAD mit einem Kollegen statt, der seit der Hardware-Umstellung im Büro dazu verurteilt ist, sich mit EDV-Problemen aller Art zu beschäftigen, aber bitte so zwischendurch, neben seiner eigentlichen Geodäten-Arbeit. Den kann ich ja schlecht auch noch mit CAD zusätzlich belasten. Beim Erstellen einer eigenen Block- und Layer-Struktur, die die heutigen und künftigen Bedürfnisse abdecken soll, wären aber mit dem Plotter und für amtsgerechte PDFs intensive Tests notwendig.
Ich beschränke mich zZt. also damit, möglichst universell einsetzbare Lisp-Funktionen zu erstellen, sie ausführlich zu dokumentieren und samt ihren Quer-Verknüpfungen zu katalogisieren. Das dient meiner eigenen Übersicht und kann auch einem Nachfolger nützlich sein, sollte sich doch einer finden.

So, Ende der Elegie
Grüße Arcuso

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