---

Habe eine Sript dass unter AC2005 einwandfrei läuft, aber unter AC2006 nicht!

Hier die entscheidenden Zeilen:

PLinie
100,100
'KAL
ILL([@0,0],[@120<-9],[200,50],[200,120])

Bei AC2006 wird der Befehl beendet und gibt dann das richtige Ergebnis als 'neuen' Befehl heraus, was natürlich zu 'unbekannter Befehl' führt.

Tritt dieser Fehler auch bei Euch auf? Oder hat sich was geändert in AC2006?

------------------
strukturiertes Zeichnen mit www.Werner-Maahs.de

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

---

Schon wieder ich... 

Guggst du Hilfe:

Zitat:

---

ill(p1,p2,p3,p4)

Determines the intersection point between two lines (p1,p2) and (p3,p4). All points are considered three-dimensional.

---

Schau mal welchen Linientyp du aufrufst... PLs sind nur 2D, verwende mal eine 3DPOLY oder eine LINE

------------------
Grüsse

Thomas

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

---

Danke!

Dann muss ich wohl erst die Linien und Bögen zeichnen, um dann zu einer geschlossenen Polylinie zu editieren.

Hat dies einen tieferen Grund, dass dies bei AC2006 mit 3D-Punkten gemacht wurde?

------------------
strukturiertes Zeichnen mit www.Werner-Maahs.de

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

---

das war auch vorher so (X,Y,z)

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

---

wie schon erwähnt, unter AC2005 lief das Skript einwandfrei durch.

In 2006 eigentlich auch, will sagen es gibt keine Fehlermeldung.

Sinngemäß steht in der Hilfe
zu 2005 jeder Punkt wird dreidimensional betrachtet,
zu 2006 jeder Punkt ist dreidimasional.
Wo immer der Unterschied auch ist.

Das Ergebnis wird ja auch richtig zurückgegeben, nur eben eine Zeile zu spät.

------------------
strukturiertes Zeichnen mit www.Werner-Maahs.de

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

---

Ich kann mir kaum vorstellen, dass das unter 2005 lief. Es lässt sich auch schnell belegen, dass das nicht geht:

Code:

---

Command: _pline
Specify start point: 0,0,0
Current line-width is 0.0000
Specify next point or [Arc/Halfwidth/Length/Undo/Width]: 100,0,0
2D point or option keyword required.
Specify next point or [Arc/Halfwidth/Length/Undo/Width]: 100,0
Specify next point or [Arc/Close/Halfwidth/Length/Undo/Width]:
Command:

---

_PLINE akzeptiert als ersten Punkt einen 3D-Punkt, ab dem zweiten nicht mehr. Das war in 2005 so, und es ist auch in 2006 so geblieben.

Das ist eine Sache im Zusammenspiel mit CAL, über die ich mich auch schon geärgert habe. Die Rückgabe von CAL-Vektoren/Punkten ist immer 3D. Auch die Anwendung von xyof(<ausdruck> ) bringt nichts, denn dadurch wird zwar der Z-Wert genullt, aber er ist immer noch da, z.B. xyof([1,2,3]) => [1, 2, 0].

Im CAL kann man auch nie mehr als einen Ausdruck auf einmal evaluieren, daher ist es nicht machbar, ein Zwischenergebnis in einer Lisp-Varablen abzulegen und dann X und Y daraus auszulesen - das wären zwei sequenzielle Ausdrücke, und das geht nicht. Also bleibt nichts anderes möglich, als die Operation zweimal durchzuführen, auch wenn's echt Schwachsinn ist:

Code:

---

[rxof(...), ryof(...)]; fügt X und Y zusammen

[rxof(<meinAusdruck> ), ryof(<meinAusdruck>] => 2D-Vektor

[rxof(ILL([@0,0],[@120<-9],[200,50],[200,120])),ryof(ILL([@0,0],[@120<-9],[200,50],[200,120]))] => sollte funktionieren

---

Ich hab's nicht ausprobiert, aber das Muster sollte klar sein. Wie gesagt: Idiotisch, aber die einzige Möglichkeit. Wenns erstmal unterm Makrobutton liegt, sieht's ja keiner mehr;-)

Gruß, Axel Strube-Zettler

------------------
Meine AutoLisp-Seiten Mein Angriff auf dein Zwerchfell Mein Lexikon der Fotografie Mein gereimtes Gesülze

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

---

Zitat:

---

Original erstellt von mapcar:
Ich kann mir kaum vorstellen, dass das unter 2005 lief.

---

Hi mapcar,

Du liegt da ja völlig richtig. Aber dass war ja nicht das Problem. Wenn Du meinen Skript anschaust, siehst Du keine einzige 3D-Eingabe, nicht einmal der Startpunkt.
Auch eine Schaltfläche nützt da recht wenig, da es sich bei meinen Skripts um Demo-Skripts handelt. Und diese sollten den Umgang mit der geometrischen Rechnerhilfe aufzeigen.

Trotzdem Danke für Deine ausführliche Darlegung.

------------------
strukturiertes Zeichnen mit www.Werner-Maahs.de

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

---

Zitat:

---

Original erstellt von Werner-Maahs.de:
Du liegt da ja völlig richtig. Aber dass war ja nicht das Problem.

---

Öööh, habe ich jetzt was falsch verstanden? Du hast weiter oben gesagt, dass das Script in 2005 problemlos lief

Zitat:

---

Original erstellt von Werner-Maahs.de:
Wenn Du meinen Skript anschaust, siehst Du keine einzige 3D-Eingabe, nicht einmal der Startpunkt.

---

Doch, jedenfalls im Sinne von 3D-Eingabe für AutoCAD. Die Rückgabe aller CAL-Funktionen, die keinen Double zurückgeben (wie z.B. cos() oder rxof()) ist *immer* ein 3D-Punkt! Der CAL kennt nur diese beiden Datentypen "Double" und "3DVektor", sonst nix - nicht mal Ganzzahlen.

Zitat:

---

Original erstellt von Werner-Maahs.de:
Auch eine Schaltfläche nützt da recht wenig, da es sich bei meinen Skripts um Demo-Skripts handelt. Und diese sollten den Umgang mit der geometrischen Rechnerhilfe aufzeigen.

---

Tja, dann war dein Beispiel nun gerade ein Griff ins Klo;-) Wie gesagt, ich habe mich auch schon über das Eingabeverhalten von _PLINE geärgert. Andere Befehle machen das eleganter, z.B. _MVIEW. Ein MAnsichtsfenster ist ja auch nicht 3D-fähig, aber _MVIEW lässt sich mit 3D-Angaben füttern - die Z-Werte werden einfach ignoriert. Warum macht das _PLINE nicht genauso? Wäre wahrscheinlich ein zu konsistentes Verhalten für AutoCAD;-)

Der CAL ist ja ein nettes Tool, aber er hat ein paar echte Grenzen. Das wichtigste fehlende Feature ist eben der von mir bereits angesprochene fehlende Sequenz-Operator, vergleichbar mit PROGN in Lisp. Steinalt ist CAL auch, könnte altersmäßig ein Geschwister von Proteus/DCL sein. Und dass man bei der deutschen Übersetzung am ä im Ofang "Näc" gescheitert ist und daher die Ofänge auch im deutschen KAL auf englisch eingegeben werden müssen, ist schon *voll* peinlich.

Der CAL war übrigens mal quelloffen (R12, R13), allerdings wurde auch mit der deutschen Version die engl. Quelldateien mit ausgeliefert. Ich hab's mal ausprobiert: Komplette Übersetzung ins Deutsche einschl. der Ofangnamen betrug AFAIR ca. 3 Stunden Arbeit - eine davon war die Panne mit dem ä. Diese eine Arbeitsstunde kann sich Adesk Deutschland seit 10 Jahren nicht leisten. Davon, dass der Ofang im CAL auch aussehen sollte wie der normale Ofang (Pickbox, Symbole usw.), will ich ja gar nicht reden. Seit vielen Releases wird der Quellcode auch nicht mehr mit ausgeliefert, schade.

Gruß, Axel Strube-Zettler

------------------
Meine AutoLisp-Seiten Mein Angriff auf dein Zwerchfell Mein Lexikon der Fotografie Mein gereimtes Gesülze

[Diese Nachricht wurde von mapcar am 24. Aug. 2005 editiert.]

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

---

Eben hat mich eine PM erreicht, die das Thema betrifft. Ich meine aber, das sollte nicht per PM geklärt werden, sonderhier, damit alle was davon haben, insbesondere der OPoster Werner Maahs. Hier also die Fragen aus der PM:

Zitat:

---

1. in 2004/2005 wurde das Ergebnis von Kal als (Lisp-)LISTE ausgegeben. Der Befehl PLINIE konnte mit dieser Liste umgehen und hat dann einfach nur den X & Y-Wert genutzt - es hat also funtkioniert.

- Man kann als Koordinate für einen PL-Stützpunkt auch angeben:
- (list 20 20 5) und es wird funktionieren.

In 2006 ist die Rückgabe keine Liste mehr sondern eine Texteingabe (oder wie man das in diesem Falle nennt)

2. Du hast irgendwetwas geschrieben aŽla "kann man Zwischenergebnis nicht in Lispvariable speichern / nutzen... Hä ? Das geht doch dachte ich..

---

Zu 1.
Der Hinweis auf das Lisp-Listen-Format war entscheidend: Das ist tatsächlich so! Ich habe es explizit noch mal in 2005 und 2006 verglichen:

AutoCAD 2005:

Code:

---

Command: cal
>> Expression: ill([0,0],[1,1],[4,0],[3,1])
(2.0 2.0 0.0)

---

AutoCAD 2006:

Code:

---

Command: cal
>> Expression: ill([0,0],[1,1],[4,0],[3,1])
2,2,0

---

OK, es hat sich also tatsächlich was geändert, die Aussage aus der PM ist *richtig*, und ich habe mich da einfach geirrt mit der Aussage, dass das Skript von Werner in 2005 nicht laufen konnte. Ich hab's zwar nicht ausprobiert, aber es wird wohl doch funktioniert haben;-)

Es bleibt allerdings die Frage offen, warum _PLINE 3D-Punkte akzeptiert, wenn sie als Lisp-Liste reinkommen (dann wird Z ignoriert), aber nicht, wenn sie "as is" über die Kommandozeile übergeben werden. Da hat sich zwischen 2005 und 2006 nichts geändert, mein gestern angeführter Kommandozeilenmitschnitt ohne CAL ist noch immer für beide Versionen gültig.

Tja, und nachdem ich heute etwas mehr Zeit habe (gestern stand schon das Essen auf dem Tisch und wurde kalt, deswegen sagte ich ja "sollte funktionieren") habe ich mal mein ach so schönes Workaround getestet - geht aber auch nicht, gibt auch ein implizites Z=0 zurück.

2. Ich habe nicht gesagt, dass man ein Zwischenergebnis nicht in einer Lisp-Variablen speichern kann - ich habe nur gesagt, dass man nicht innerhalb eines Ausdrucks speichern und gleich wieder auslesen kann. Ein simples Beispiel: Der User soll einen Punkt mit CUR wählen, der Ausdruck soll X^2+Y^2 berechnen. In zwei Schritten geht das:

>> Expression: myPoint=CUR
...
>> Expression: rxof(myPoint)^2+ryof(myPoint)^2

Aber es nütz ja nix, wenn man das in einem Ausdruck braucht, und nicht erst im nächsten CAL-Aufruf. Wenn es einen Sequenz-Operator gäbe (ich schreibe dafür mal ein Semikolon), dann sähe der Ausdruck so aus:

myPoint = CUR;rxof(myPoint)^2+ryof(myPoint)^2 => Fehler!

Es geht auch nicht mit einem Komma dazwischen, es geht überhaupt nicht. Es bringt aber auch nix, den User den Punkt dreimal wählen zu lassen;-)

Überhaupt hat der CAL massive Probleme mit seinen Operatoren, z.B. dem Gruppierungsoperator, den Klammern. P=CUR funktioniert, aber warum gibt (P=CUR) den Fehler "AutoLISP variable P has no value" zurück, wenn P == nil, aber den Fehler "Right parenthesis ')' missing", wenn P != nil, als wenn P doch einen Wert hat? Der CAL-Interpreter tickt da einfach nicht richtig!

Eigentlich sollte sich das Beispiel X^2+y^2, wenn man schon keinen Sequenzoperator hat, wenigstens so lösen können:

rxof(myPoint=CUR)^2+ryof(myPoint)^2

Dieser Ausdruck ist nach den Regeln des CAL völlig korrekt. Geht man von der üblichen Reihenfolge der Verarbeitung (links-rechts, innen-außen) und der internen Umwandlung in Postfix-Notation aus, dann sollte der Ausdruck so evaluiert werden (der User hat den Punkt 3,4,0 gewählt, das Ergebnis sollte also 25 lauten:

Code:

---

1. myPoint=CUR  => Vektor [3,4,0]  ;; Picken und Ablegen in myPoint
2. rxof(Vektor) => Skalar 3        ;; X des gewählten Punktes
3. ^2          => Skalar 9        ;; Quadrieren
4. ryof(Vektor) => Skalar 4        ;; Y des gewählten Punktes
5. ^2          => Skalar 16        ;; Quadrieren
6. +            => Skalar 25        ;; zurückgeben

---

Die Datentypen sind für jeden Schritt korrekt, die Syntax ist korrekt usw. Trotzdem erzeugt dieser Ausdruck die völlig schwachsinnige Fehlermeldung "Unexpected argument list for function RXOF". Wo ist da eine Argumentenliste? Der Ausdruck enthält doch nicht ein einziges Komma! rxof() erwartet einen Vektor, und MyPoint=CUR sollte eigentlich einen Vektor zurückgeben: Offensichtlich wurde aber vergessen, dem Vorgang Variable=Wert irgendwie eine definierte Rückgabe zu verpassen.

Deswegen läuft das alles nur, wenn die Zuweisung an eine Lisp-Variable als letzte Operation innerhalb eines Ausdrucks stattfindet. Das heisst auf Deutsch:

a) Der Variablenname muss immer am Anfang des Ausdrucks stehen

b) Dem Variablennamen muss natürlich der Operator = folgen

c) Im weiteren Ausdruck kann nicht auf die Variable zugegriffen werden

4) Erst beim nächsten Aufruf von CAL kann man die Variable verwenden

Und nochmal die Kernaussage: Daraus lässt sich schließen: Zwischenspeichern in einem Ausdruck geht nicht, daher muss man oft mehrmals die gleichen Schritte wiederholen und Berechnungen  durchführen, deren Ergebnis man schon längst hat.

Tja, und nun zur Frage, warum Autodesk das Rückgabeverhalten des CAL mit 2006 geändert hat - andere Änderungen hat's ja seit 10 Jahren nicht gegeben. Möglich, dass das nur ein Bug war, der mit dem kommenden SP wieder bereinigt wird. Aber: Ein Neukompilieren war doch gar nicht nötig! ARXe von 2004, 2005 und 2006 sind kompatibel, da sie alle mit Visual C++ 7.0 kompiliert wurden/werden. Wenn also geändert und neu kompiliert wurde, dann nicht versehentlich. Die
Absicht kann aber nur sein, wenn man die Umstellung von Lisp-Liste auf ein Sendcommand umstellt, dass der CAL für ein AutoCAD ohne Lisp fit gemacht werden soll. Anders kann ich das nicht interpretieren.

So weit, so gut. Aber: man könnte ja schlau sein und einfach die Geomcal.arx von 2005 ins 2006er Verzeichnis kopieren. Da die versionskompatibel sind, sollte damit der alte Zustand wieder hergestellt sein. Habe ich gemacht - ändert aber nicht die Bohne! Der CAL läuft unbeeindruckt weiter, aber die Rückgabe ist nach wie vor keine Lisp-Liste, sondern blanke Zahlen auf der Kommandozeile. Eigentlich erhärtet das meinen Verdacht nur noch, dass
demnächst die Eingabe einer öffnenden runden Klammer oder eines
Ausrufungszeichens als erstes Zeichen nur noch die Fehlermeldung "Unbekannter Befehl" erzeugen wird.

Und nun kommt der eigentliche Hit: ich kann die Geomcal.arx auch einfach löschen, und der CAL läuft auch nach dem nächsten Start weiter, ohne dass sich was ändert! Der CAL läuft gar nicht mehr als ARX, sondern ist jetzt integraler Bestandteil von AutoCAD. Das wird bestätigt durch einen Blick in die Appload-Liste: Da steht er gar nicht mehr drin (in 2005 ist er noch da). OK, der letzte Versuch: Ich lade in 2006 einfach mit APPL0AD die geomcal.arx von 2005 - trotzdem keine Änderung, geladen wurde aber "successfully". Wahrscheinlich ruft die Eingabe von CAL immer die interne Version auf. Also auch nichts zu machen. Und wozu wird dann die ARX noch in 2006 mitgeliefert? Und warum ist sie plötzlich nur noch 12kB groß (bisher 56kB)? Fragen über Fragen, aber keine Antworten...

Sorry für meine Irrtümer noch mal, aber auch "Götter" pfuschen manchmal;-) Nicht, dass ich mich für einen halten würde, aber wenn man des öfteren so angeredet wird, gerade von dem, der mir die PM geschickt hat...

Gruß, Axel Strube-Zettler

------------------
Meine AutoLisp-Seiten Mein Angriff auf dein Zwerchfell Mein Lexikon der Fotografie Mein gereimtes Gesülze

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

---

Und nochmal ich;-)

Eben kam mir noch die Idee, dass die geomcal.arx deshalb nur noch 12 KB groß ist, weil sie nur noch den Stub für die Lisp-Funktion (cal ...) enthält. Aber dem st nicht so: (cal ...) funktionert in Lisp ebenfalls weiter, auch wenn gar keine geomcal.arx mehr da ist. ic vermute also, dass diese 12 KB eine leere arx/dll sind, in der außer den Lade- und Entladefunktionen gar nichts drin steht, ein Dummy also, der nur verhindern soll, dass vorhandene Lisp-Programme mit Kopfzeilen wie (if(null cal)(arxload"geomcal.arx")) geladen werden können, ohne dass ein Fehler entsteht.

Im Lisp-Handbuch steht aber nix, dass (cal ...) jetzt eine echte Lisp-Funktion ist.

Gruß, Axel Strube-Zettler

------------------
Meine AutoLisp-Seiten Mein Angriff auf dein Zwerchfell Mein Lexikon der Fotografie Mein gereimtes Gesülze

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

---

Ich kann jetzt auch voll daneben liegen, aber resultiert das ganze nicht  aus der Einführung des Quickcalc ?

AutoCAD unterscheidet ja jetzt zwischen CAL und QC - und meines Wissens nach (also was meine ersten Verusche so zeigten) arbeitet der QC jetzt mit Listen und nicht mit "Punkten" - was ja aber schön zum Verhalten passen würde.

Oder lieg ich da jetzt daneben ?

------------------
Grüsse

Thomas

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

---

Beispiel1.scr.txt Beispiel2.scr.txt

Mein Gott,
da habe ich ja was angestoßen! Danke für Eure Mühe, aber ich bin noch nicht am Ende.

Jetzt kommt wieder was Neues.
Ein weiterer Skript arbeitet ebenfalls mit der ILL-Funktion und läuft auch in AC2006 einwandfrei.

Ich habe jetzt den Anfang beider Skriptdateien, befreit von meinen Schulungsanmerkungen, diesem Beitrag angehangen. Der Rest war so oder so ok.

Beispiel 1 sollte unter 2006 Probleme bereite Beispiel 2 aber nicht.
Für mich sind die Beispiele vergleichbar.

Wo liegt nun die Ursache?

------------------
strukturiertes Zeichnen mit www.Werner-Maahs.de

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

---

Bitte um Aufklärung:

Warum sollte Beispiel 1 Probleme bereiten ? Und warum Beispiel 2 nicht ? Wenn ich mir die Scripts so ansehe müsste es genau anders rum sein...

Und welcher Natur sind die Probleme im Beispiel 1 ?

------------------
Grüsse

Thomas

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

---

Na ja, das ist doch klar: Die beiden Scripte sind *nicht* vergleichbar, denn das erste verwendet doch gar keine Polylinie (offensichtlich hast du die Reihenfolge verwechselt). Der Befehl Linie ist doch 3D-fähig, und davon wurde doch schon in den ersten Antworten geredet.

@tunnelbauer: Offensichtlich hängt das mit dem Quickcalc zusammen, ja. Jedenfalls sagt das auch Achim Dabrunz, mit dem ich eben mal kurz darüber geredet habe. Ich habe den QC noch nie benutzt, weil er kein RPL (umgekehrte polnische Notation) kann. Deswegen habe ich auch keine Ahnung davon;-)

Gruß, Axel Strube-Zettler

------------------
Meine AutoLisp-Seiten Mein Angriff auf dein Zwerchfell Mein Lexikon der Fotografie Mein gereimtes Gesülze

[Diese Nachricht wurde von mapcar am 24. Aug. 2005 editiert.]

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

---

Zitat:

---

Original erstellt von mapcar:
Na ja, das ist doch klar: Die beiden ...  verwendet doch gar keine Polylinie (offensichtlich hast du die Reihenfolge verwechselt). Der Befehl Linie ist doch 3D-fähig, und davon wurde doch schon in den ersten Antworten geredet.

---

Also beide Skripts verwenden Polylinie. In der Zeile 13 oder 14.

Das esrte Beispiel soll eine Wellenkontur zeichnen (später als geschlossene Polylinie) diese Routine zeigt hinter der ILL-Funktion aus dem Befehl PL aus (ohne Fehlermeldung), gibt dann in der nächsten Zeile den richtigen Wert zurück, leider im Befehlsmodus was die Meldung 'unbekannter Befehl# hervorruft.
Das zweite Beispiel soll die Kontur einer Nabe erstellen. Läuft auch in AC2006.

Für mich unverständlich warum?

Wenn Ihr mir helfen wollt probiert es bitte aus!

------------------
strukturiertes Zeichnen mit www.Werner-Maahs.de

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

---

Example1.scr.txt Example2.scr.txt maahsscripts.jpg

Also - nachdem ich mir beide Scripts internationalisiert hatte und einen Testdurchlauf starten konnte (    ), kommt folgendes raus (siehe Screenshot) - links oben Script2 in der Mitte Script1.

Ich habe auch die Scripts wieder angehängt (meine Version - sie sind also nur übersetzt, sonst nicht verändert) - und beide funktionieren;

@Maahs:

Es wäre nicht schlecht, wenn wir wissen würden was nicht funktioniert oder welche Fehlermeldung auftaucht, denn:

 

Zitat:

---

Das esrte Beispiel soll eine Wellenkontur zeichnen (später als geschlossene Polylinie) diese Routine zeigt hinter der ILL-Funktion aus dem Befehl PL aus (ohne Fehlermeldung), gibt dann in der nächsten Zeile den richtigen Wert zurück, leider im Befehlsmodus was die Meldung 'unbekannter Befehl# hervorruft.

---

ist nicht besonders sprechend; da wäre ein Copyclip der Command-History hilfreicher...

------------------
Grüsse

Thomas

[Diese Nachricht wurde von tunnelbauer am 24. Aug. 2005 editiert.]

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

---

script1.gif script2.gif

Zitat:

---

Original erstellt von tunnelbauer:
Ich habe auch die Scripts wieder angehängt (meine Version - sie sind also nur übersetzt, sonst nicht verändert) - und beide funktionieren;

---

Nö, beide funktionieren nicht. Sorry @Werner Mahhs, hatte vorhin nur einen Blick darauf geworfen, ausprobieren konnte ich sie nicht, weil ich auch engl. AutoCAD habe. Ich hatte nur den CAL-Ausdruck gesehen und ein Stück weiter oben LINIE. Dass das nur ein L-Segment innerhalb von PLINIE war, habe ich glatt übersehen.

@tunnelbauer: Jedenfalls sieht man in der Kommandozeile, dass der CAL-Ausdruck in beiden Fällen nicht geschluckt wird:

Code:

---

Specify next point or [Arc/Close/Halfwidth/Length/Undo/Width]: 19,25

Specify next point or [Arc/Close/Halfwidth/Length/Undo/Width]: 'CAL
>>>> Expression: ILL([@0,0],[@2<195],[0,24.7],[20,24.7])

Resuming PLINE command.

Specify next point or [Arc/Close/Halfwidth/Length/Undo/Width]: 16.6,24.7

---

Dieses "Resuming PLINE command" heisst, dass ein Fehler auftrat und abgefangen wurde. Das passiert in beiden Skripten so, allerdings fällt es im zweiten Skript kaum auf, und deswegen dachte Werner wohl, das liefe fehlerfrei. Ist aber nicht so, diese Meldung sieht man bei beiden.

Ich habe bei beiden Skripten mal die CAL-Ausdrücke durch errechnete Werte ersetzt: Beim ersten Skript entsteht jetzt eine vermutlich korrekte Geometrie, beim zweiten sieht man einen minimalen optischen Unterschied (rote Kontur/grüne Kontur). Screenshots von beiden Ergebnissen hängen dran.

Gruß, Axel Strube-Zettler

------------------
Meine AutoLisp-Seiten Mein Angriff auf dein Zwerchfell Mein Lexikon der Fotografie Mein gereimtes Gesülze

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

---

  - "Wer lesen kann ist klar im Vorteil" oder wie war das...

(an und für sich hätte ich anhand der Geometrie stutzig werden müssen)
------------------
Grüsse

Thomas

[Diese Nachricht wurde von tunnelbauer am 24. Aug. 2005 editiert.]

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

---

Erstmal Danke , dass Ihr Euch nochmal die Mühe gemacht habt.

@mapcar
Ja ich hab es gesehen.
Die Wellenkontur hast Du vermutlich auch von Hand gezeichnet, denn die ist scheinbar richtig.

@tunnelbauer
Genau dies waren meine Ergebnisse in AC2006.

In AC2005 waren die Ergebniss wie sie mapcar von Hand gezeichnet hat.

Gibt es aus Eurer Sicht eine Lösung, wie ich die Skripts trotzdem hinbekomme.
Oder kann ich die ILL-Funktion für 2D-Befehle in AC2006 knicken?

------------------
strukturiertes Zeichnen mit www.Werner-Maahs.de

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

---

Zitat:

---

Original erstellt von Werner-Maahs.de:
Oder kann ich die ILL-Funktion für 2D-Befehle in AC2006 knicken?

---

Ich fasse mal das wesentliche zusammen, was nun rausgekommen ist (bei mir war ja nicht nur das Interesse, dir zu helfen, sondern vor allem, was *generell* los ist):

1. In 2006 kann man mit CAL alles berechnen, nur keine Polylinienstützpunkte und andere Sachen, die eine 2D-Eingabe zwingend erfordern

2. CAL ist jetzt ein interner AutoCAD-Befehl, der keine Lisp-Listen für den Datentyp 'Vektor' mehr zurückgibt

3. Die Datei geomcal.arx ist nur noch ein leerer Dummy, der einen Fehler bei (arxload"geomcal.arx) verhindert

4. Da (cal ...) in Lisp auch dann noch funktioniert, wenn die geomcal.arx gelöscht wurde, haben wir den Fall zu bestaunen, dass ZUM ERSTEM MAL SEIT DER EINFÜHRUNG VON VISUAL LISP DER INTERPRETER UM EINE NEUE FUNKTION ERWEITERT WURDE, und die heisst eben (cal) und verhält sich fast so wie die alte, kommt aber nicht mehr aus der ARX.

5. Die Hilfe in 2006 bezügl. CAL ist noch auf dem Stand von 2005

Tja, und nun zur Frage: Knicken? Im Prinzip ja, aber es geht von hinten durch die Brust ins Auge: Nimm einfach die neue Lisp-Funktion statt eines CAL-Ausdrucks!

Code:

---

...
17,12
_ARC
@1<0
_LINE
23.5,12
(cal "ILL([@0,0],[@40<-9],[55,0],[55,20])")
_ARC
_CE
55.75,7
...

---

Das funktioniert!

Ach ja, diese neue Lisp-Funktion steht natürlich wieder im Widerspruch zu dem, was ich weiter oben über das Ende von Lisp vermutet habe.

Gruß, Axel Strube-Zettler

------------------
Meine AutoLisp-Seiten Mein Angriff auf dein Zwerchfell Mein Lexikon der Fotografie Mein gereimtes Gesülze

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

---

Da hattest du leider das falsche Acad offen 

Tut mir leid - so war es bis 2005 !
passiert mir auch öfters mal .. SORRY
nix Entwicklung

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

---

habe nachgesehen, du hattest evtl . doch 2006
getestet, aber mit der 2005er arx !!!!
Dat funkt, juchuuuuh

@Maas
benenne deine 2006er geomcal.arx in geomcal.org um und kopiere
dir die 2005er geomcal.arx in das Verzeichnis, nun sollten die Scripte
weiterhin laufen und der "Schnellkal" funktioniert ebenfalls noch da
dieser ja nicht in der Arx definiert ist.

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

---

Tja, *in-die-Ecke-stell-und-schäm*, ich weiß auch nicht, was ich da gestern gemacht habe. Ich glaube nicht, dass ich einfach den Button für 2006 und den für 2005 verwechselt habe - jedenfalls: Als ich eben 2006 gestartet habe, kannte es den Befehl CAL doch nicht mehr, d.h. erst nachdem ich die ARX geladen hatte.

War also (mal wieder) ein Irrtum, dass da eine neue native Funktion eingebaut wurde. Wahrscheinlich hatte ich 2006 doch noch offen, als ich die letzte Variante der Skripte getestet habe, und CAL war irgendwie noch geladen. Keine Ahnung, ich werde es auch nicht mehr rauskriegen. Also: die Welt ist wieder in Ordnung, an Lisp hat sich seit 7 Jahren doch nix geändert;-)

Die geomcal.arx enthält enthält aber trotzdem nur einen Stub (deshalb die 12 KB), allerdings wird, das habe ich erst eben gemerkt, eine Datei namens ACalcEngine.arx nachgeladen, die wohl die eigentliche Funktionalität enthält. Man kann übrigens den 2006er Geomcal in 2005 laden, die Engine wird dann automatisch aus dem 2006er Verzeichnis ins 2005 nachgeladen - das nur am Rande. In 2005 gibt er aber Lisp-Listen zurück.

Es ergibt sich jetzt auch eine neue Möglichkeit: Wenn man die Dateien geomcal.arx, AcCalcEngine.arx (und AcCalcEngineRes.dll gehört auc noch dazu) im 2006er Verzeichnis löscht und dann die geomcal.arx von 2005 lädt, dann hat man wieder den alten CAL-Befehl, der auch Polylinien kann, also Lisp-Listen zurückgibt. Allerdings funktioniert dann QUICKCALC wahrscheinlich nicht mehr;-)

Ich würde das Workaround für die Scripte also so umbauen:

Code:

---

...
17,12
_ARC
@1<0
_LINE
23.5,12
(if(null cal)(arxload"geomcal"))
(cal "ILL([@0,0],[@40<-9],[55,0],[55,20])")
_ARC
_CE
55.75,7
...

---

Nun kann ich nur hoffen,dass meine Pechsträhne hier bald mal abreisst;-) Oder sollte ich mal 'ne Kur beantragen?

Gruß, Axel Strube-Zettler

PS: Und es bleibt die Frage, warum der 2006er CAL - in 2005 geladen - Lisp-Listen zurückgibt. Das verstehe ich derzeit nicht.

------------------
Meine AutoLisp-Seiten Mein Angriff auf dein Zwerchfell Mein Lexikon der Fotografie Mein gereimtes Gesülze

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

---

es reicht wohl auch die 2005er geomcal.arx
in das 2006er zu kopieren .
(dann geht der _qc auch noch)

ACHTUNG ! BITTE nur meinen Weg nutzen (nur die geomcal.arx tauschen)
Edit: dann kann man

(cal "ILL([@0,0],[@40<-9],[55,0],[55,20])") in 2006 nutzen,

der _qc funktioniert weiter

aber KAL Ausdruck=>ILL([@0,0],[@40<-9],[55,0],[55,20])
      liefert weiterhin keine Liste.

Wenn man wie Mapcar vorschlug die 2 neuen Dateien löschen würde
dann sieht es so aus:

Acad öffnen über Link / Es wird der Installer gestartet
Acad öffnen über die acad.exe funktioniert , mit dem Ergebnis:

(cal "ILL([@0,0],[@40<-9],[55,0],[55,20])") funktioniert

"Kal" findet die ("eben gelöschte") AcCalcEngine.arx nicht und
funktioniert dementsprechend nicht !

dem Aufruf des _qc Erfolgt der totale Acad-Absturz

[das 2006er in das 2005er teste ich nun aber auch mal      ]

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

---

Ich werde mich hiermit aus dem Thema ausklinken da ich ja nur unruhe einbringe 
@Axel: Ich habe die 3 2006er Cal-Dateien in das 2005er gebracht und der
KAL liefert mir KEINE Liste zurück !

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

---

Zitat:

---

Original erstellt von cadffm:
es reicht wohl auch die 2005er geomcal.arx
in das 2006er zu kopieren .
(dann geht der _qc auch noch)

---

Gute Idee! Da bin ich noch gar nicht drauf gekommen.

In einer Sache gab's allerdings ein Missverständnis: Die ganze Dateien-Tauscherei war ja nur rein theoretisch gemeint. Mit meinem letzten Vorschlag, wie man das Skript zum Laufen kriegt, hat das ja alles nix zu tun. Sobald eine Klammer drum ist, also (cal"<ausdruck>"), funktioniert es ja immer, egal welche Version, ohne jede Änderung an den Dateien.

Dass das mit dem Dateientausch kein Weg für die Praxis ist, war ja klar. Ich schrieb ja schon oben: "Allerdings funktioniert dann QUICKCALC wahrscheinlich nicht mehr;-)" Dasses aber gleich zum Absturz führt - da fehlt wohl ein bisschen Errorhandling im AutoCAD.

Gruß, Axel Strube-Zettler

------------------
Meine AutoLisp-Seiten Mein Angriff auf dein Zwerchfell Mein Lexikon der Fotografie Mein gereimtes Gesülze

[Diese Nachricht wurde von mapcar am 25. Aug. 2005 editiert.]

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

---

Zitat:

---

Original erstellt von mapcar:
...Sobald eine Klammer drum ist, also (cal"<ausdruck>"), funktioniert es ja immer,
egal welche Version, ohne jede Änderung an den Dateien...

---

Das sehe ich nicht so, genau DAS geht eben nicht mehr.
[warum ist dieser Thread so verflixt ???]

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

---

Also: ich habe jetzt keine Dateien getauscht...
Aber: ich habe - so wie von mapcar beschrieben - vor dem CAL eine Klammer gesetzt und dann den gewüsnchten Ausdruck angegeben und die Klammer wieder geschlossen - und das funktioniert sehr wohl (also bei mir mit englischem AutoCAD)

@cadffm:

Hast du eventuell ein deutsches AutoCAD ? Die Internationalisierung bringt nämlich in dem Fall nix... (warum auch immer...)

also:

Code:

---

(CAL "ILL([@0,0],[@40<-9],[55,0],[55,20])")

---

geht.

Code:

---

(_CAL "ILL([@0,0],[@40<-9],[55,0],[55,20])")

---

geht nicht.

Und für die mit deutschem AutoCAD: anstelle von CAL einfach KAL schreiben und die Welt sollte wieder in Ordnung sein.

Achja: transparenter Aufruf geht natürlich auch nicht....

------------------
Grüsse

Thomas

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

---

danke Thomas,

Die sind ja (sorry) echt bekloppt ! 
Die Aussage von Tunnel kann ich jetzt genau so bestätigen !
(Jupp, habe Acad2006deu)
----
Zum "normalen" aufrufen des Rechners/Befehlszeile funktionieren
übrigens diese Aufrufe:

CAL,  _CAL,  KAL,  _KAL !!  <-- was soll das nu wieder ?

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

---

Zitat:

---

Original erstellt von tunnelbauer:

Und für die mit deutschem AutoCAD: anstelle von CAL einfach KAL schreiben und die Welt sollte wieder in Ordnung sein.

[/B]

---

Mit den Klammer (cal "...") ist die Lösung auch bei der deutschen Version. KAL funktioniert nicht!
Auf meinen (Schul-)Rechnern ist AutoCAD Inventor installier und damit auch AutoCAD. Hier funktioniert es jedenfalls.

Mit ist geholfen. Danke an alle!

------------------
strukturiertes Zeichnen mit www.Werner-Maahs.de

[Diese Nachricht wurde von Werner-Maahs.de am 26. Aug. 2005 editiert.]

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