---

Hab ich was übersehen?
Bei aktivem Osnap - siehe OSMODE - werden Punkte, wenn sie als Koordinaten-Liste aus Lisp-Programmen geliefert werden, 
durch den Osnap überschrieben.
Die Option Punktlisten vorrangig stufen zu können, wurde bei der SysVAR OSNAPCOORD sträflich vergessen, meine ich.

Dies Kritik gilt aber nicht für BricsCAD, ZWcad usw.
Hier wird eine Punktliste NICHT durch den Osnap überschrieben.

Möglichkeiten die Überschreibung von Punklisten durch OSMODE in AC zu verhindern ...
.) bei der Punktübergabe an laufenden Command den OSMODE deaktivieren und dannach wieder aktivieren.
... hier muss festgestellt werden, ob eine weitere Verarbeitung des Punktes in Lisp erfolgen soll, oder der Punkt bereits als Eingabe an einen laufenden Command übergeben werden soll.
CMDACIVE kann zwar abgefragt werden, ...

Code:

---

(if(and(= 1(getvar'CMDACTIVE))
      (= "AutoCAD"(getvar'PRODUCT)))
(progn(osnap-off) ;;; müsst ihr euch denken
      (command Pointlist)
      (osnap-on)) ;;; ... ebenso
  Pointlist)

---

... um die Überschreibung durch Osmode zu verhindern, aber: die Sache hat einen Haken!!!
Wenn gleichzeitig CMDACTIVE=1 ist und der Punkt durch Lisp erst weiter verarbeitet (erstellt) werden soll.

.) den Punkt in Textform übergeben (siehe SysVar OSNAPCOORD) zu wandeln scheidet wegen mangelnder Prezision aus!

Habt ihr dazu einen Rat?
Ich wäre sehr dankbar.
lg ToXoT
Hab ich was übersehen?
Bei aktivem Osnap - siehe OSMODE - werden Punkte, wenn sie als Koordinaten-Liste aus Lisp-Programmen geliefert werden, 
durch den Osnap überschrieben.
Diese Option wurde bei der SysVAR OSNAPCOORD sträflich vergessen, meine ich.

Dies gilt aber nicht für BricsCAD, ZWcad usw.
Hier wird eine Punktliste NICHT durch den Osnap überschrieben.

Möglichkeiten die Überschreibung von Punklisten durch OSMODE in AC zu verhindern ...
.) bei der Punktübergabe an laufenden Command den OSMODE deaktivieren und dannach wieder aktivieren.
... hier muss festgestellt werden, ob eine weitere Verarbeitung des Punktes in Lisp erfolgen soll, oder der Punkt bereits als Eingabe an einen laufenden Command übergeben werden soll.
CMDACIVE kann zwar abgefragt werden, ...

Code:

---

(if(and(= 1(getvar'CMDACTIVE))
      (= "AutoCAD"(getvar'PRODUCT)))
(progn(osnap-off) ;;; müsst ihr euch denken
      (command Pointlist)
      (osnap-on)) ;;; ... ebenso
  Pointlist)

---

... um die Überschreibung durch Osmode zu verhindern, aber: die Sache hat einen Haken!!!
Wenn gleichzeitig CMDACTIVE=1 ist und der Punkt durch Lisp erst weiter verarbeitet (erstellt) werden soll.

.) den Punkt in Textform übergeben (siehe SysVar OSNAPCOORD) zu wandeln scheidet wegen mangelnder Präzision aus!

Habt ihr dazu einen Rat?
Ich wär sehr dankbar.
lg ToXoT

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

---

Hi,

>>"Hab ich was übersehen?"
Mal sehen.

>>"Bei aktivem Osnap - siehe OSMODE - werden Punkte, wenn sie als Koordinaten-Liste aus Lisp-Programmen geliefert werden, 
durch den Osnap überschrieben."
Zunächst mal: Punkte werden nie überschrieben, es geht darum ob der fortlaufende Objektfang (falls aktiv) berücksichtig wird oder nicht
und dabei geht es auch nur um die Eingabe "per Tastatur" oder deren Simulierung per (send)commands in einem AutoCAD-Befehl.

Anmerkung: Ich denke ja du weißt wovon du sprichst, also bin ICH wohl noch nicht beim richtigen Thema angelangt?
Ein weiterer Hinweis dazu ist "als Koordinaten-Liste aus Lisp-Programmen", also wenn du einen einzelnen Punkt meinst,
dann bin ich bei dir - auch das ist eine Liste (55 55 0), bei eigentlich stelle ich mit darunter eine Liste mit mehreren Unterlisten vor
und ich kennen keinen einzigen AutoCAD-Befehl der die verarbeitet - kann also nicht sein = also verstehe ich da wieder einen Teil nicht.
Bitte kläre mich auf, danke.

>>"Die Option Punktlisten vorrangig stufen zu können, wurde bei der SysVAR OSNAPCOORD sträflich vergessen, meine ich."
Angenommen du irrst und mit Punktlisten hat es nichts zutun: Osnapcoord 2 setzt den Objektfang für die Tastatur außer kraft (Vorgabe)
und der Wert1 macht es auch für Automatisierungen.

>>"Dies Kritik gilt aber nicht für BricsCAD, ZWcad usw."
Hier wird eine Punktliste NICHT durch den Osnap überschrieben.
Etwas lächerlich dem Baum vorzuwerfen er wäre grün belaubt, wo ihn doch die Kinderhände lila und blau darstellen.
(ich meine ja nur)

>>"Möglichkeiten die Überschreibung von Punklisten durch OSMODE in AC zu verhindern ..."
An der Stelle solltest du wirklich mal ein konkretes fertiges Beispiel nennen, wenn nicht für mich dann
für andere die es vielleicht auch gerade nicht blicken.
BTW: Soweit mir bekannt funktioniert Osnapcoord in AutoCAD,LT,Toolsets und allen Kopien identisch.

>>".) aber: die Sache hat einen Haken!!!"
Verstehe ich nicht: Du (der Progger) weiß genau wann sein Programm startet und wann es beendet wird,
also kannst du problemlos (die aktuelle Einstellung merken) und am Anfang.. und am Ende... machen was du willst.)

Jetzt bin ich mal gespannt und freue mich etwas neues lernen  

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

---

>>"Dies Kritik gilt aber nicht für BricsCAD, ZWcad usw."
Nachgesehen: BCAD hat dieselbe Voreinstellung wie ACAD - was zu erwarten war,
und Wert 2 (Vorgabe) kontrolliert wie in AutoCAD nur die Keyboardeingabe, aber nicht die Automatisierung.
Zumindest nicht die über die Befehlszeile, Script oder Makro.
Muss also ein weiterer Hinweis darauf sein das ich noch nicht beim richtigen Thema bin  

EDIT: Wenn auch nicht aus ganz offizieller Quelle - für ZWCAD gilt dasselbe.

Jetzt bitte ich wirklich um Aufklärung wovon du sprichst - Ich lache jetzt schon über mich was ich da wohl mißverstanden habe 

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

---

Zitat:

---

Original erstellt von cadffm:

Jetzt bitte ich wirklich um Aufklärung wovon du sprichst - Ich lache jetzt schon über mich was ich da wohl mißverstanden habe  

---

Ich hab' auch nicht verstanden, worin das Problem besteht. Aber so weit wenigstens:
Das (command pointlist) kann nicht funktionieren. Entweder
(apply 'command pointlist)
oder
(foreach pt pointlist (command pt))
oder
(mapcar '(lambda (pt) (command pt)) pointlist

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

---

Hi,
Ich merk, hier ist "Behutsamkeit" gefragt 
>>Zunächst mal: Punkte werden nie überschrieben,
das kann ich nicht bestätigen!
Nehmen wir als nachvollziehbares Beispiel an ...
.) (command "_Line""0,0""100,0""") + ENTER
.) (setvar OSMODE 2) + ENTER ... Midpoint
.) sicherstellen, dass Osnap = ein ist
.) (command "_Line")
... jetzt die Eingabe eines Punktes als Liste via Tastatur ... und diese könnte ebenso von einem Lisp-Programm gesendet werden  ...
.) (list 20 0 0) + Enter
... und dann guck mal, was Du trotz Tastatureingabe bekommst.
Behaupte, der Punkt schnappt  - zum Trotz - auf den Midpoint der Linie.

... Weiter ...
Eine Punktliste ist eine Liste ohne Unterlisten und besteht entweder aus 2 oder 3 Reals // Integers ... simple (list 1 2 3) ... oder ähnliches.
(getpoint) + Enter und Klick irgendwohin liefert solches.

>> ... und ich kennen keinen einzigen AutoCAD-Befehl der die verarbeitet ...
... die Unrichtigkeit dieser Aussage habe ich schon zuvor beantwortet.

>> ... SysVAR OSNAPCOORD ...
Wenn AC den Return von Lisp-Programmen - der üblicherweise als Punktliste im Command-Prompt ankommen - ebenso als "Tastatureingabe" erkennen//einstufen würde, hätte ich // wir so manche Probleme nicht.
Das hab ich mit dem vorherigen Beispiel auch klar machen wollen.
Obwohl ich mit der Tastatur den Punkt - und das ist erlaubt !!! - als (List 20 0 0) eingeben, beachtet // erkennt AC die Tastatureingabe nicht! ... BC und ZW aber schon.
... und das würd ich nicht als >> ... Etwas lächerlich ... einstufen.

>> ... Du (der Progger) weiß genau wann sein Programm startet und wann es beendet wird ...
Nein, aufgrund der Möglichkeit, dass Lisp sich in die Tiefe verzweigen kann, ist der Zeitpunkt, wann dann das Resultat - der Progger-Mühe - an den Command übergeben werden soll, eben nicht klar.
Nimm mal an - das ist mein "Normalfall" - dass eine Punkt in ein Gelände aus 3dFaces gesetzt werden soll und Lisp errechnet Dir den Durchstoßpunkt eines Vektors mit einer Ebene (zB aus 3 Punkten definiert) ... dann sind für das Resultat - im einfachsten Fall - 5 Punkteingaben notwendig. ... im einfachsten.
Wenn aber einer der 5 Punkte als Teilungspunt errechnet werden soll ... sind es bereits 6 Punkte. ... und die benötigte Punktanzahl kann noch größer werden.
Wann also die Übergabe an Command stattfindet ist nicht eindeutig.
Die Stapelbarkeit und Tiefe der Funktionen ist ja der Hit der KI in Lisp.
Deshalb ist die Tatsache, dass Listen nicht als Keyboard-Eingabe anerkannt werden, eine Niederlage ... meine ich.
… weiteres  beantworte ich bald …
Lg ToXoT

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

---

>> Das (command pointlist) kann nicht funktionieren.
... wie bitte?

Versuch mal ...
.) (command "_line") Enter ... jetzt sollte der Linienbefehl bereits laufen ...
.) (command (list 200 0 0)) ... jetzt sollte die Linie bei 200,0 bereits gestartet sein.
... also ??? was soll diese Aussage?

lg ToXoT

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

---

... wie bitte?
... also ??? was soll diese Aussage?

Die Aussage soll... das was ich auch sagte - als "Pointliste" nehme ich eine Liste mit Unterlsiten an, Tom hatte das auch so interpretiert.
Pointliste '((1 2 3)(4 5 6)usw.)

So macht es dann (auch für dich) Sinn.

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

---

Zitat:

---

Original erstellt von toxot:
>> Das (command pointlist) kann nicht funktionieren.
... wie bitte?

Versuch mal ...
.) (command "_line") Enter ... jetzt sollte der Linienbefehl bereits laufen ...
.) (command (list 200 0 0)) ... jetzt sollte die Linie bei 200,0 bereits gestartet sein.
... also ??? was soll diese Aussage?

lg ToXoT

---

Du hast ein anderes Beispiel genannt, oder ich habe Deine POINTLIST falsch verstanden. Unter POINTLIST verstehe ich eine Liste von Punkten, also eine Liste von Listen, und nicht eine Liste von Zahlen.

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

---

Hi,

>>Zunächst mal: Punkte werden nie überschrieben,
>>das kann ich nicht bestätigen!
Du überschreibst den "vom User gewählten fortlaufenden Objektfang", selbe Ergebnis - aber technisch eine ganz andere Aussage.
Der Punkt wird nicht überschrieben, sondern eine aktive Einstellung (Objektfang).

>>.) (setvar OSMODE 2) + ENTER ... Midpoint
>>.) sicherstellen, dass Osnap
Das machst du ja bereits mit OSMODE = 2

>>"... und dann guck mal, was Du trotz Tastatureingabe bekommst."
Genau das richtige Ergebnis, in Abhängigkeit zu den aktuellen Programmeinstellungen,
der Objektfang ist aktiv und abhängig von dem eingestellten Fangbereich+aktueller Ansicht+
den im Bereich befindlichen Objektenwird der Punkt ermittelt.
In ACAD, wie in BCAD

>>Behaupte, der Punkt schnappt  - zum Trotz - auf den Midpoint der Linie.
Du hast ja auch 1. Objektfang (Mittelpunkt) an,
20.0 befindet sich auf genau der Linie, also wird entsprechend deines Objektfange der Mittelpunkt dieser Linie geschnappt.
(ich nehme jetzt einfach mal den Fall an gibt keine anderen Objekten in dem Bereich, sonst könnte es auch woanders sein)

>>"Eine Punktliste ist eine Liste ohne Unterlisten..
Das fehlte noch in der Beschreibung um ganz sicher zu sein wovon du sprichst,
weil aber alles andere nicht so richtig zutrifft (andere CAD-Programme / osnapcoord), waren wir noch an dieser Erklärung interessiert. Erledigt.

>> ... SysVAR OSNAPCOORD ...
>>Wenn AC den Return von Lisp-Programmen - der üblicherweise als Punktliste im Command-Prompt ankommen - ebenso als "Tastatureingabe" erkennen//einstufen würde,"
>> hätte ich // wir so manche Probleme nicht.
Dafür ist osnapcoord ja da. Wert=2 übergeht den Objektfang bei Keyboardeingabe, aber nicht in Automatisierungen (in deinm Fall ein Lispausdruck)
Wie in (mir bekanntem) BCAD auch.

>>"Das hab ich mit dem vorherigen Beispiel auch klar machen wollen."
Hier sollte es aber keinen Unterschied zu anderen Programmen geben, daher wundert uns die Aussage etwas,
zudem funktioniert osnapcoord in AutoCAD, was auch nicht deiner Aussage entspricht, auch hier: Warum bist du anderer Meinung?
DEN Knackpunkt haben wir noch nicht.

>>"Obwohl ich mit der Tastatur den Punkt - und das ist erlaubt !!! - als (List 20 0 0) eingeben, beachtet // erkennt AC die Tastatureingabe nicht!"
Doch schon, aber die Punkteingabe erfolgt durch Lisp = Automatisierung, daher bleibt der Objektfang bei osnapcoord=2 aktiv.

>>" ... BC und ZW aber schon."
Okay, dann mal angenommen ich habe mit allem soweit recht, dann geht es dir explizit um die Lispeingabe in der Befehlszeile?
(wobei du geschrieben hast ich "darf" das auch in einer Lispprogramm/einer Lispdatei testen -> wo deine Aussage dann definitiv wieder nicht passen würde)
Ich teste das gerne auch mal in einem alten Bricscad, aber egal wie das Ergebnis ist, es würde nichts ändern, siehe nächster Punkt.
[EDIT: Funktioniert genau so wie ich es sagte - in BCADv16 getestet, mit was testest du denn?]

>>... und das würd ich nicht als >> ... Etwas lächerlich ... einstufen.
Damit meinte ich das Osnapcoord eine Erfindung von AutoDESK ist, einige andere Hersteller haben das Programm im großen und ganzen nachprogrammiert
und damit meine ich nicht Befehl Linie (wie soll man den sonst nennen) sondern knallhart kopiert bis in so Details wie Variablen mit demselben Namen usw.
Wenn es bei anderen Programmen anders funktioniert, dann sind diese an der Stelle beim kopieren abgewichen..
Dem Erfinder zu sagen es läuft falsch (nach Jahrzehnten wo es so funktioniert und nicht anders), das habe ich als "lächerlich" betitelt.
(BTW: Es wäre bei anderen Dingen wünschenswert wenn Adesk einiges nachzieht oder glattzieht, aber man erkennt heute auch schon das die den anderen nacheifern  
was sicher auch ganz angenehm ist - einfach mal nachmachen zu können.)

>> ... Du (der Progger) weiß genau wann sein Programm startet und wann es beendet wird ..."
Nein, aufgrund der Möglichkeit, dass Lisp sich in die Tiefe verzweigen kann, ist der Zeitpunkt, wann dann das Resultat - der Progger-Mühe - an den Command übergeben werden soll, eben nicht klar."
Da kann ich nicht ganz folgen, aber jeder Programm sollte für sich sicherstellen eine bekannte Umgebung zu haben, sonst ist das Ergebnis ja nur Zufall.
Gerne nehme ich konkrete Beispiel an - aber für den Thread wird es nicht so wichtig sein nehme ich an.

>>"Nimm mal an - das ist mein "Normalfall" -....Wann also die Übergabe an Command stattfindet ist nicht eindeutig."
Dafür gibt es im Zweifelsfall osnapcoord, in allen der genannten Programmen.

>>"Die Stapelbarkeit und Tiefe der Funktionen ist ja der Hit der KI in Lisp"
Auch wenn es schon angesprochen wurde,
Dir ist soch bekannt wo einfach nur AutoCAD-Befehle fernsteuerst (command, das ist nie unbekannt.
Da man theoretisch auch osnapcoord oder auch anderes setzen kann wie man will (der User zwischendrin oder auch anderen Programme),
müßte man ohne sicherstellen das alles passt - zum Zeitpunkt des Command.

>>"Deshalb ist die Tatsache, dass Listen nicht als Keyboard-Eingabe anerkannt werden, eine Niederlage ... meine ich."
Deine Punktangabe per Tastatur (ohne Klammer) würde genauso ein Ergebnis hervorrufen - wenn osnapcoord auf 1 steht.

Du kannst es also drehen und wenden wie du willst, "Man(n)" muß sich kümmern um diesen Punkt.

-

Wieder bin ich gespannt was zurückkommt, bisher passt noch alles "in meiner Welt"  

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

---

Zitat:

---

Original erstellt von toxot:

Die Stapelbarkeit und Tiefe der Funktionen ist ja der Hit der KI in Lisp.

---

Nöö, ganz sicher nicht, denn beides ist in so ziemlich allen anderen Programmiersprachen genau so möglich. IMO ist das sogar Voraussetzung dafür, dass es sich um eine Programmiersprache handelt, und eben nicht nur um eine Makrosprache.

Die Eignung von LISP für KI rührt zum einen daher, dass Lisp-Funktionen selbst Listen sind und damit der wichtigste Datentyp von Lisp. Eine Lisp-Funktion kann also problemlos andere Lisp-Funktionen und damit auch sich selbst während der Laufzeit verändern. Ein Programm, das sich zielgerichtet an veränderte Rahmenbedingungen selbst anpassen kann, ist ein lernfähiges Programm, und Lernfähigkeit ist ein wesentlicher Apekt jeder KI.
Zum anderen ist aber auch die Möglichkeit der Makroprogrammierung ein wesentlicher Aspekt der KI-Relevanz von Lisp. Dummerweise fehlt diese extrem wichtige Möglichkeit in AutoLisp/VisualLisp usw völlig. In AutoLisp kann man leider noch nicht mal sowas einfaches wie ein "+" programmieren, oder ein "setq" oder "defun". Vor gut 20 Jahren, nach der Übernahme von VitalLISP, hat Autodesk noch versprochen, das in VisualLisp umbenannte VitalLisp u.a. auch in Richtung CommonLisp zu erweitern. Das wäre dann diese Makroprogrammierung gewesen.

Zitat:

---

Deshalb ist die Tatsache, dass Listen nicht als Keyboard-Eingabe anerkannt werden, eine Niederlage ... meine ich.

---

Nöö, nicht wirklich, denn Listen sind Konstrukte des Lisp-Interpreters. Mit der öffnenden Klammer als Eingabe in der Befehlszeile wechselt AutoCAD in den Lisp-Interpreter, und nur der versteht, was (list 1 2 3) bedeutet, denn nur der kann die Lisp-Funktion (list ...) interpretieren. Wenn man also mit einer Systemvariablen festlegen kann, dass Punkteingaben in Lisp-Funktionen wörtlich genommen werden und nicht durch den OSNAP abgeändert werden sollen, dann muss das IMO auch für Lisp-Aufrufe aus der Befehlszeile gelten. Da sind BricsCAD und AutoCAD aber wohl unterschiedlich programmiert. Vermutlich hängt es davon ab, von wo aus die Command-Pipeline gestartet wird.

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

---

>>" Da sind BricsCAD und AutoCAD aber wohl unterschiedlich programmiert."
V16 und SEHR wahrscheinlich ältere aber schon mal nicht.

>>"Vermutlich hängt es davon ab, von wo aus die Command-Pipeline gestartet wird."
Super Idee,

@toxot
Ich fragte oben ja schon nach der BCAD-Version von der du schreibst, also?
Ich könnte mir ja noch vorstellen das sich etwas geändert hat* seit der Blade-Versionen zB., das wäre V18.2

*geändert, aber zu einem "falsch" geändert - ausgehend davon das man eine Funktion nachprogrammiert hat und die in der
Vergangenheit auch 1:1 funktionierten - also 1:1 zu AutoCAD.
Wenn dies jetzt nicht mehr der Fall wäre, dann ist es im Sinne der Kopie und der Funktionalität älterer Versionen ein Fehler,
oder falls es bewußt gemacht wurde, eine gewünschte Abweichung von dem Ursprung.

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

---

@cadffm
zu ...
>> Die Aussage soll... das was ich auch sagte - als "Pointliste" nehme ich eine Liste mit Unterlisten an, Tom hatte das auch so interpretiert.
Pointliste '((1 2 3)(4 5 6)usw.)

Das war von mir so nicht gemeint ... ich verstehe deine "Pointlist" als List of Pointlists ... oder wenn‘st willst: als Liste von Real//Integer-Lists die eigentlich - für mich - PunktlisteN sind.
Auch wenn Du / Ihr das also so nicht interpretiert habt, war es von mir so gemeint.
Eine Pointlist ist für mich (List 0 0 0) oder '(0 0 0) ... oder das was (getpoint) liefert. Vielleicht ist das in deinem Umfeld einfach ein Punkt.Für mich ist dieser Punkt aber eine Liste im Unterschied zum PunktString "0,0,0".
Friedenspfeife?
Das geht aber am eigentlichen Thema vorbei.
Ich hatte oben auch eine Möglichkeit vergessen, den Osnap in AC zu überschreiben, die ich wenigstens hier noch anbringen ...
Weitere Möglichkeit ...
.) man schreibt zuerst den Punkt in die SysVar LASTPOINT
.) und unterstellt AC mit (command "@") dass es sich um eine Tastatureingabe gehandelt hat.
Das funktioniert, wird als „Tastaturengabe“ anerkannt und überschreibt den Osnap!
... oder ...
.) über schickt über Sendkey den Punkt via VBA an AC
… eben „von hinten durch die Brust ins Auge. … lassen wir das, um ein solch in Wirklichkeit triviales Problem zu lösen.
Ich versuch jetzt aber nochmal das eigentliche Problematik zu schildern.
.) In Lisp können über diverse Subroutinen Punkte errechnet werden, wobei die Tiefe im Sinne von Menge an Subroutinen die daran beteiligt sein können von Vorneherein nicht bekannt ist und auch unwesentlich  ist, zumindest sein sollte.
Wann die eigentliche Übergabe an den Command-Prompt erfolgt wird als nicht bekannt angenommen. Jedenfalls ist es der letzte Return-Value.
.) diese Subroutinen senden sich diese Punkte in Listenform  und geben das Ergebnis – uU an andere Subroutinen  wieder in derselben Listenform weiter.
.) wenn aber das Endergebnis dann in eben derselben Listenform im Command landet, wird dieser durch Lisp übergebene Punkt  - zB: (1.111111111111111 2.22222222222222222 0) – NICHT als Tastatureingabe bewertet und durch den Osnap überschrieben.
.) wird der Punkt aber – ebenso durch Lisp übergeben - als String – zB: „1.111111111111111,2.22222222222222222,0“ – übergeben, wird er durch den Osnap nicht überschrieben und als Tastatureingabe bewertet … hat aber dramatisch an Präzision – wie breits bemerkt - verloren.
LG ToXoT
... oder ...
.) über schickt über Sendkey den Punkt via VBA an AC

lg ToXoT

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

---

>>Friedenspfeife?
Gar nicht nötig, man musste es nur geklärt haben. Done.

>>Das geht aber am eigentlichen Thema vorbei.
>>Ich hatte oben auch eine Möglichkeit vergessen, den Osnap in AC zu überschreiben,
Nochmal an dieser Stelle, wir (CIH) sehe bisher nichts in deinen Zeilen was sich in den Programmen unterscheide!
(Zcad kann ich nicht testen, BCAD nur in V16)

Den Rest schaue ich mir später an, wobei irgendwelche workarounds überhaupt nicht nötig sind,
zumindest nicht speziell in ACAD, wenn dann auch in den anderen Programmen.

Welche Version ist es denn nun in der osnapcoord=2 BCAD nicht interessiert in Automatisierungen?

bis später 

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

---

@archtools
Danke für Deine sehr erfahrene Sicht was ... Lisp angeht!!!
Bezüglich der "Niederlage, dass Listen nicht als ... " bin ich dennoch anderer Meinung.
Wenn ein CAD-Hersteller seiner Anwendung eine Programmiersprache hinzufügt, die IMO den eigentlichen Erfolg dieses Programmes ausmacht, dann sollten die Rückgabewerte auch respektiert werden ... als ob es sich um eine User-Eingabe handelt.
Und da Lisp eben Listen verarbeitet, sollte ein Punkt als Liste ebenso anerkannt werden.
Auch dann, wenn der Command-Prompt von AC in den Lisp-Interpreter wechselt, sollte dessen "Aussage" oder das Ergebnis des Interpreters als solches gelten!
Ich arbeite ja schon seit Anbeginn der Zeiten ohne Osnap ... weil meine Tools ihn schon vorher kannten, bevor AD diesen in AC zwar eingeführt aber nicht angezeit hatte. OK?
Das hat mich massiv irritiert! ... grread war die Lösung ... heute ein BUG in AC22 + AC23!
Erst jetzt taucht dieses Thema wieder auf, weil meine Programme "Beine" bekommen haben und Büros sich an mich - ob der Problematik - wenden.
LG ToXoT

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

---

Also bis auf den VBA part (jetzt mal ausgeklammert und aufgeschoben - sitze nicht am PC),
klingt das alles "falsch" für mich.[EDIT: Bzw. nicht nötig /EDIT]
Technisch wie auch die Sicht darauf.

Aber wie erwähnt, ich sitze gerade nicht am PC und schreibe nur aus dem effeff.
Ob String oder Liste sollte egal sein, ist es das nicht, so überrascht es mich und ich sage Danke!
Ich schreibe aber 100e Scripte Macros und auch (commands
und da geht es zu 90% um string Angaben.

Aber ich will ja Fehler meinerseits nicht ausschliessen.

Wäre aber toll wenn nicht nur wir, sondern auch DU dein "Wissen" überprüfen würdest.

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

---

@cadffm
... erst mal herzlichen Dank!
Aber, Du bist so schnell und umfangreich, dass ich gar nicht weiß worauf ich Antworten soll.
Ich arbeit immer mit dem aktuellen BC ... zZ BC23. Und das in mehreren Sprachen.
Wenn ich von AC was brauch, steig ich (umständlich) über Anydesk in diverse Büros ein, die AC gemietet haben. Meist die großen Desingn-Versionen mit Revit oder uralte Versionen vor der "Miete".
In BC hab ich den Vorteil, dass meine Tools - viel Stoff - in der gewohnten Umgebung auch im BIM arbeiten kann.
Die Punktfänge meiner #TOOLS sind eine Zentrale für möglichst fehlerfreies und schnelles Arbeiten in komplexen Zeichnungen geworden ... es sind an die 30 Routinen bis ins 3D.
Ich sehe den Punktfang als die eigentliche Zentrale des CAD. Zumindest dann, wenns im 3D richtig "zur Sache geht".
Ablauf ist normalerweise ...
.) Osnap ist off und bleibt off
... Der Osnap ist also auch bei Zoom oder PAN mal gar nicht aktiv.
.) es soll irgendwas gezeichnt werden
.) auf der RM-Taste liegt beim ersten Klick der Standardfang ... eine Kombi aus End, Int ... usw.
.) ist dieser nicht zufriedenstellend oder könnte zu einer Fehleingabe (aufgrund: zu klein gezoomt und zu viele Osmode-Kombis ... OK?... Folgen machmal: katastrophal) führen, dann wird die RM-Taste ein zweites mal gedrückt und eine spezielles Menu an der Moustaste mit den 30 Einzelfängen angezeigt.
Es wechseln sich also Kombi-Fang und Einzel-Fang permanet ab.
Die Fänge sind fehlertolerant und könnten beliebig gestapelt werden.
Inzwischen wartet der Command noch immer auf den Punkt.
So lange der OSMODE=0 oder wenigstens inactiv ist ... kein Problem mit den übergebenen Punkten als Liste!
Erst wenn der Osnap aktiv wird, beginnt das Drama in AC ... und nur in AC!
... auch wenn OSNAPCOORD=1.
lG ToXoT

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

---

Ich freu mich schon später am PC den Rest zu (be) antworten :-)

Nur fehlt mir gerade - aus dem lesen heraus und dem effeff
der reproduzierbare "Fail" Fall.

Vielleicht sehe ich es später am PC, gern darfst du aber auch eine simple Schritt für Schritt Anleitung geben.
Gerne auch mit einem Programmcode oder sonstwas.
Aktuell wüsste ich nicht wie der User etwas machen sollte was die folgende Punkteingabe beeinflusst (bei Osnapcoord=1)

Auch nett: Teste/Kommentiere doch bitte meine Statements die gegen deine Aussagen sprechen.

Du siehst: Ich bin gerne mit in dem Thema, aber es ist schwer zu Folgen.
Danke vorab,
ich freue mich schon etwas Neues über BoderA CAD zu lernen,
aber noch bin ich da nicht :-(

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

---

Zitat:

---

Original erstellt von toxot:
Bezüglich der "Niederlage, dass Listen nicht als ... " bin ich dennoch anderer Meinung.
Wenn ein CAD-Hersteller seiner Anwendung eine Programmiersprache hinzufügt, die IMO den eigentlichen Erfolg dieses Programmes ausmacht, dann sollten die Rückgabewerte auch respektiert werden ... als ob es sich um eine User-Eingabe handelt.

---

Das wäre extrem kontraproduktiv, und würde die meisten AutoCAD-Programme unbrauchbar machen. Ein Lisp-Programm in CAD BERECHNET die Koordinatenpunkte, und zeichnet sie nicht angelehnt an was, was da eventuell oder eventuell auch nicht schon da ist.

Es gibt in AutoCAD aber nun mal die Command-Pipeline, die von vielen Programmierern nahezu ausschließlich dazu genutzt wird, Zeichnungselemente über durch Lisp berechnete Koordinatenpunkte zu erzeugen. Die Command-Pipeline macht aber etwas, was man als Programmierer in aller Regel definitiv NICHT haben will, nämlich den OSNAP zu berücksichtigen. Deshalb gibt's die Systemveriable, die das steuert.

Aber auch mit der Systemvariablen kann man den Input so oder anders sehen, je nachdem, ob man in der Command-Pipeline Koordinatenpunkte als Strings mit Komma dazwischen angibt, oder durch Lisp "berechnen" lässt, indem man (list 1 2 3) eingibt, oder '(1 2 3). Es gibt dabei kein "wahr" oder "falsch", sondern das ist in AutoCAD so programmiert, wie die Programmierer das für sinnvoll erachtet haben.

Was anderes ist es, wenn es in BricsCAD et al ein von AutoCAD abweiochendes verhalten in dieser Sache gibt. Diese Programme wollen voll kompatibel zu AutoCAD sein, und sollten deshalb ihr Verhalten nicht nach den ideen der eigenen programmierer gestalten, sondern so, dass sich BricsCAD et al IMMER genau so verhält wie AutoCAD.

Falls Du da also abweichendes Verhalten in BricsCAD festgestellt hast, dann melde das doch einfach an Bricsys.

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

---

noch immer nicht wieder CAD, ein Kommentar mehr:

>>"als ob es sich um eine User-Eingabe handelt"
Die Aussage verstehe ich ja überhaupt nicht!
Bitte stelle osnapcoord auf 0 und sag mir wie das Verhalten "Usereingabe" von dem Verhalten *egal wie* abweicht?
Und wie bei allem vorhergehenden auch: Gilt für A und B CAD.
Dafür ist die Variable ja da.

Noch immer auf ein Beispiel wartend
und hoffend das es in BCAD keine Änderungen in den letzten Versionen gab.

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

---

@cadffm
>>"als ob es sich um eine User-Eingabe handelt" ... Die Aussage verstehe ich ja überhaupt nicht!
Gemeint ist hier der Kern des Problems.
.) Wenn - mit höchst möglichen Präzision - in Lisp ein Punkt errechnet oder in anderer Form erfasst wird, dann liegt dieser Punt als Liste aus 3 Reals vor.
Also zB: (list realX realY realZ).
.) Wenn nun Lisp diesen Punkt an den Command in dieser Form übergibt, dann wird - entsprechend den Elementen, die sich in der Nähe oder unter diesem Punkte befinden, der gelieferte Punkt entsprechend OSMODE überschrieben. Hier ist eben Schluss mit Lustig.
Wozu wurde also ein Lisp bemüht, wenn letztendlich sein Return-Wert ungültig wird.
Es sollte ja wenigstens eine Möglichkeit geben, die Koordinate (list realX realY realZ) EINFACH ZU SETZEN. ... ohne Wenn und Aber ... auch dann, wenn irgendein Osnap "ON" ist.
Um die Lösung dieses äußert trivialen Problems hab ich ersucht.
Ohne sich die Finger auf der F3-Taste wund zu klopfen oder sich die Präzision mit Punkt-Strings zu ruinieren.
Es fehlt ja in OSMODECOORD nur eine Option: dass auch ein Punkt - wie er üblicherweise aus Lisp in Form einer Liste aus drei Reals geliefert wird - auch als HÖHERRANGIG als der OSMODE einzustufen ist, wenn ein Command läuft ... oder hab ich was übersehen?

Warum wurde bei Einführung der SysVar OSMODECOORD - und die war ja offensichtlich notwendig ... ja? - auf die Usereingabe am Keyboard oder Skript Rücksicht genommen und auf durch Lisp gelieferte Liste aus Reals vergessen???

Ich hoffe, Gesagtes fällt auf fruchtbaren Boden.
lG ToXoT

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

---

Hi toxot,

jetzt komme ich nicht nach mit dem Schreiben, aber die erste Zeile meines gerade entstehenden neuen Posts ist:
Ha! Jetzt bin ich endlich bei dir, zumindest zu Teil 

Wenn du also in ~20-30min noch online bist [F5] 

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

---

Zitat:

---

.) Wenn - mit höchst möglichen Präzision - in Lisp ein Punkt errechnet oder in anderer Form erfasst wird, dann liegt dieser Punt als Liste aus 3 Reals vor.
Also zB: (list realX realY realZ).
.) Wenn nun Lisp diesen Punkt an den Command in dieser Form übergibt, dann wird - entsprechend den Elementen, die sich in der Nähe oder unter diesem Punkte befinden, der gelieferte Punkt entsprechend OSMODE überschrieben.[/i]

---

Nein, er wird nie überschrieben. Du musst erst mal unterscheiden zwischen einem errechneten und an eine Variable gebundenen Koordinatentupel (sowas wie (setq pt1 (list 1 2 3))) und den Punkten in einem Entity, also z.B. (... (10 1 2 3)) für den Anfangspunkt einer Linie. Wenn Du die Linie mit (command "._line" pt1 '(4 5 6) "") zeichnest, dann verändert sich pt1 dadurch niemals. Der Punkt PT1 bleibt solange unverändert, bis Du der Variablen einen neuen Wert zuweist.

Was Du nicht verstehen willst, ist die Command-Pipeline. Die ist nun mal was völlig anderes, als beispielsweise eine Linie mittels ENTMAKE oder den Objektmethoden zu erzeugen. Die Command-Pipeline bildet nun mal Nutzereingaben ab, und soll sich grundsätzlich genau so verhalten, wie die gleichen Eingaben in der Befehlszeile.

Falls Dir die Nebeneffekte der Command-Pipeline nicht behagen, dann steht es Dir ja frei, die echten Lisp-Funktionen zum Erzeugen der Entities zu verwenden. Warum nutzt Du nicht ENTMAKE, wenn Dir COMMAND nicht behagt?

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

---

>>"dann verändert sich pt1 dadurch niemals"
Das stimmt, aber die Koordinate welche von AutoCAD an den Befehl Linie übergeben wird durchaus und das ist das Problem.
Abhängig von... den besagten Dingen.

Und wenn deine Zeile gekürzt wird:
(command pt1 '(4 5 6) "")
und "völlig losgelöst" übergeben wird wenn LINIE bereits läuft, dann kommt auch noch toxot Bug hinzu, den ich selbst endlich sehe.

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

---

Ha! Jetzt bin ich endlich bei dir, zumindest zu Teil   
Verschieden getestet, aber praktisch alles "Testfehler" (also Anwenderfehler),
zur falschen Zeit das falsche gemacht   

Warum mir das nie aufgefallen war oder ich es wieder vergessen habe - keine Ahnung. Nach einem Dejavue fühlt es sich nicht an.
Ich bin etwas Baff und freue mich zugleich :-) <Danke für das Durchhalten und die Geduld>

Also: Ein AutoCAD-Befehl läuft bereits, nehmen wir dein LINIE-Beispiel, und ich gebe dann als ersten Punkt (list 20 0 0)
was man ja weder beim Programmieren noch beim Zeichnen so macht, zumindest nicht für gewöhnlich.
Was ich hingegen öfters mache und mir es dabei hätte auch passieren können:
Ich gebe eine Variable direkt an !A = gleiches Thema, nur ist es mir nie um die Ohren geflogen.

Und es ist noch etwas gruseliger.

(command "_.LINE" '(20 0 0)'(75 0 0) "" "_.REGEN")
wie von mir erwartet korrekt.

Befehl Linie ist bereits gestartet und dann
(command '(20 0 0)'(75 0 0) "" "_.REGEN")
Zeigt ein Fehlverhalten für die erste Punktangabe(Objektfang wird berücksichtigt),
die zweite Punktangabe wird richtig verarbeitet(Objektfang wird ignoriert).

Na sowas? Für Dich so oder so ähnlich nichts neues, ich hingegen bin schon etwas verwundert   

(progn(command "_.LINE")(command '(20 0 0)'(75 0 0) "" "_.REGEN"))
hingegen funktioniert (wie bis vor kurzem 'wie erwartet', aber nach dem Bug im Test zuvor war ich da nicht mehr sicher   

-

Irgendwie fühlt sich das nun an wie wacklige Knie und ich verzichte aktuell auf Kommentare zu irgendwas aus der bisherigen Diskussion,
außer zu deiner letzten Antwort, weil wir uns überschnitten haben:

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

>>"Gemeint ist hier der Kern des Problems. Wenn - mit höchst möglichen Präzision"
So weit waren wir oben überhaupt noch nicht, ich konnte dir ja noch überhaupt nicht folgen - Vergessen wir den Punkt / obsolet.

>>" Hier ist eben Schluss mit Lustig.
>>"Wozu wurde also ein Lisp bemüht, wenn letztendlich sein Return-Wert ungültig wird."
hier hole ich ein anderes Zitat gleich noch hinzu:
>>"Es fehlt ja in OSMODECOORD nur eine Option: dass auch ein Punkt - wie er üblicherweise aus Lisp in Form einer Liste aus drei Reals geliefert wird - >>"auch als HÖHERRANGIG als der OSMODE einzustufen ist, wenn ein Command läuft ... oder hab ich was übersehen?"
Nix "höherrangig", osnapcoord handelt diesen konkreten Fall einfach falsch - oder gar nicht/wie auch immer, bin immernoch baff   

Da muss ich mich mal räuspern und antworte dazu in dem Gedanken(!) es würde keine Unregelmäßigkeit geben:
1. Der User hat den fortlaufenden Objektfang gewählt (ob voreingestellt oder nicht, osmode ist die Einstellung des Anwenders),
   es ist also Users Wille das der Objektfang berücksichtigt wird, Punkt.
2. Jetzt gibt es eine Variable die besagt: Aber wenn die Punktangabe per Tastatur gemacht wird, statt per Maus zB. oder per Automatisierung,
   dann ignoriere den fortlaufenden Objektfang - was ja auch super sinnvoll ist (2) und wenn es nach mir gehen würde, dann wäre Wert1 default.
3. Beim Wert (1) SOLLTE der Objektfang für Automatisierungen ignoriert werden, was auch für die bei Makro,Script,(send)commands funktioniert*

*bis auf diese Situation von der wir jetzt hier reden (schwere Geburt, ich kann nur noch mal um Entschuldigung bitten - Absicht war das sicher nicht)

Dieser FAIL Fall ist ja gar doppelt FAIL, denn der Objektfang sollte ja osnapcoord ignoriert werden bei
a) für Tastatureingaben und b) für Automatisierung
In die Befehlszeile (list 20 0 0) eingeben ist definitiv eines von beiden (der Fall der "Automatisierung" sollte es sein IMHO, aber selbst wenn nicht, dann wäre es noch immer die Tastatureingabe.
Ich staune   

>>"Es sollte ja wenigstens eine Möglichkeit geben, die Koordinate (list realX realY realZ) EINFACH ZU SETZEN. ... ohne Wenn und Aber ... auch dann, wenn irgendein Osnap "ON" ist."
Problem ist die eine Situation von "nur Koordinate senden", einem einem Progrämmchen wie 1000fach zu finden ist das kein Problem
(command "_.LINE" (list (/ 1 3.0) 0 0) (list (/ 1 pi) 0 0) "") zb.oder auch
(progn (command "_.LINE") (foreach p (list(list (/ 1 3.0) 0 0) (list (/ 1 pi) 0 0)) (command p))(command ""))

Das ein Befehl *wodurch auch immer 'außerhalb'* aktiv ist und dann mein Programm kommt um einen Punkt zu senden habe ich wohl selten!?
Außer bei so wie Objektfang-Helferlein, da könnte das vorkommen und Uhuuuu da bin ich auch wieder in deiner Welt!
Ich erinnere mich an das grread Thema und deine Erklärungen.

Ein Beispielcode+Beschreibung der Schritte wäre nett, was sollen wir uns mühsam auch den Fingern saugen an was wie (ich zumindest) überhaupt nicht denken.
Vielleicht hast du ein Beispiel welches auch für den Nicht-vom-Fach Menschen als "sinnvoll" erhaltet und getestet werden kann?
Meine Fantasie ist nach dem Schock wohl auf 0 gesunken   

>>"Um die Lösung dieses äußert trivialen Problems hab ich ersucht."
Ich bin zu müde dem heute nachzugehen, aber zugleich auch recht sicher dass du schon alles probiert hast und die Workarounds bereits alle kennst.
Die Frage ob deine Funktionen/Code so sein müssen wie sie sind - können wir aktuell nicht beurteilen. Aber auch da habe ich wenig Hoffnung.

>>"Ohne sich die Finger auf der F3-Taste wund zu klopfen oder sich die Präzision mit Punkt-Strings zu ruinieren."
ääähm.
Sprichst du nun vom einTIPPEN oder von der Überhabe im (command?
Im command würde ich einfach den Objektfang KEIN/_non erzwingen, fertig.

>>"Warum wurde bei Einführung der SysVar OSMODECOORD - und die war ja offensichtlich notwendig ... ja? - auf die Usereingabe am Keyboard oder Skript Rücksicht genommen und auf durch Lisp gelieferte Liste aus Reals vergessen???"
Ist es ja EIGENTLICH nicht! Macro,Script (send)commands - alles gleich sollange es von "innerhalb ACADs" kommt.
Du hast da eine Lücke im System aufgezeigt!

>>"Ich hoffe, Gesagtes fällt auf fruchtbaren Boden"
Zum Glück hatte ich es zuvor endlich gerafft

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

---

@cadffm

Dir gilt mein höchster Respekt!
Mit großartiger Sorgfalt triffst Du den Punkt.

Ich werd versuchen, ein kleines Progrämmchen zu bauen, weil meine #TOOLS hochgradig durch Subroutinen vernetzt sind ... Du verstehst, es wären Ordner an Code.

Du hast auch genau erkannt, dass die Problematik mit grread verbunden ist  ... einfach herrlich!!!

Für mich ist seit Anbeginn der Zeiten ein Punkt eine Liste, quoted List oder ein String. Drum verwend ich seit eh und je den Ausdruck PunktListe, PunktString - mit @ als Spezialform ...  ... deshalb diese kleine Meinungsversch ...
Verwend auch gern die Variablen p_L p_$.

Wenn man mehr und mehr zu überblicken hat, werden irgendwann die Schreibweisen sehr wichtig. ... die Stufen der Selbstdisziplinierung.

Ich meld mich, wenn ich in der Sache Progrämmchen weiter bin.
Denk da an ein einfaches Midpoint-Programm, das während es die beiden Punkte abfragt nochmal gestartet werden kann ... und noch mal ... usw. bis es endlich das Ergebnis all dieser virtuellen Punkte an den Command als letztendlich gültigen Midpoint übergibt.

Dank dir nochmal und sehr lieben Gruß ...
ToXoT

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

---

@cadffm

... die Sache wird ja immer schauderhafter.
Hab schon Lösung für die Kombi aus " Osnap + Objektfang-Helferlein-Programme" ...
und wollt sie soeben hier niederschreiben, da stoß ich schon wieder auf neuen Unfug.
Auf die Idee von Dir mit "_non" den Osnap einmalig außer Kraft zu setzten bin ich noch nicht gekommen ... Danke ... ABER ... ...
Bitte bestätigen ...
.) Osmode = 1 ... Endpunkt
.) Linie von (0 0) nach (100 0) ... unsere Voraussetzung.
.) Dann weitere Linien ... (command "_line" '(50 50))
... jetzt geht‘s in ein neues Problem, siehe folgende Varianten …
Var b) (command "_non" '(10 0))  ... funktioniert ... weiter mit "undo"
Var a) (command "_non" '(10 0 0)) ... funktioniert ... weiter mit "undo"
Var c) (vl-cmdf "_non" '(10 0))  ... funktioniert ... weiter mit "undo"
Var d) (vl-cmdf "_non" '(10 0 0)) ... funktioniert (bei mir) NICHT!
... Ausgabe ... mit Kopie der Command-Line ...
Specify next point or [Undo]: (vl-cmdf "_non" '(10 0 0))
Application ERROR: Invalid type sent as command input
… wie bitte?
Zudem ist dieses „Verhalten“ instabil … für manche Punkt: Ja … für andere: Nein.
Das wird ja immer schlimmer ... jetzt kenn ich mich nix mehr aus

Bin fassungslos ... ToXoT

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

---

für die Mitleser, das das mit dem "undo" darf man gerne ignorieren, damit hat es nichts zutun und verwirrt hier nur unnötig mehr,
auch geht es nicht um die Verwendung von "_non".

Es geht einfach nur um vl-cmdf und die Übergabe von '(10 0 0)
oder auch  von 11-19 oder 110- (119 0 0) usw.

Befehl: (vl-cmdf "_.CIRCLE" '(10 0 0) "10")
AnwendungsFEHLER: Ungültiger Typ als Befehlseingabe ausgegeben.

@Toxot
Ich denke da stolperst du über eines der Problemchen die man immer wieder findet und die nicht von Adesk dokumentiert oder behoben werden.
Wenn mir mal langweilig ist suche ich gerne mal ein anderes Beispiel bei dem es wie hier offensichtlich
eine interne Prüfung gibt welche bestimmte Werte dann anders verarbeitet.

In deinem Fall hier erinnert es mich an eine Eselbrücke (ich nutze vl-cmdf seltenst, aber man kennt das ja "da war was").

vl-cmdf und Listen mit drei Integern ist nicht zu verwenden, wie du schon gesehen hast.
(kannst ja einen einfachen Test mit print und repeat laufen lassen und du wirst ein Muster sehen)

Gemerkt hatte ich mir das so: Ich weiß nicht was "vl-cmdf" bedeutet,
also merkte ich mir "visuallisp-commandfloat".
Ist natürlich Quatsch, aber das ist bei Eselbrücken ja zulässig UND: Es funktioniert, ich habe mich heute daran erinnert    

Wenn du also '(10.0 0 0) oder (list (float 10) 0 0) schreiben würdest, kein Problem mehr ... soweit mir bekannt ist.
Wenn du also '(10.0 0.0 0.0) oder (mapar 'float '(10 0 0)) schreiben würdest, kein Problem mehr ... soweit mir bekannt ist.

   

PS: Aber nicht nur Tom, auch mich interessiert warum der User hier so freie Hand hat und du wie im Kindergarten mit Commands spielst,
statt alles in deinem Programm über die API zu kontrollieren?

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

---

zuerst mal haben wir jetzt schon ganz schön viele Baustellen offen.
Zu ...

Zitat:

---

PS: Aber nicht nur Tom, auch mich interessiert warum der User hier so freie Hand hat und du wie im Kindergarten mit Commands spielst,
statt alles in deinem Programm über die API zu kontrollieren?

---

Wenn ihr mir einen Tip geben könntet, wie ein "Osnap-Helferlein-Lispprogramm" den errechneten Punkt an den laufenden (zB) Line-Befehl übergeben könnte, wär ich dankbar.
Ein AcitveX-Ersatz für GRREAD wäre auch dringend notwendig. Oder täusch ich mich da?
Die Bemerkung "wie im Kindergarten mit Command spielst" versteh ich dann schon gar nicht mehr.
Glaubt mir, ich wäre froh wäre diese Sammelsurium an Fehlern - siehe OSNAPCOORd, VL-CMDF und GRREAD - nie dagewesen.
Für meine wertvollen Osnap-Helferlein - außer jene AC-Versionen, die nicht mal mehr mit GRREAD umgehen können - bin ich aber vorangekommen.
Hier die zentrale Routine, die für die Übergabe des Punktes sorgt ...

Code:

---

(defun #p-force2cmd(p)
  (if(and(=(getvar'CMDACTIVE)1)
        (or(= #p_need_pnt_N 0)
          (not #p_need_pnt_N)))
  (vl-cmdf "_non" P)
  p))

---

Die globale Variable #p_need_pnt_N kümmert sich um den Punktestapel, da meine Helferleins selbst auch stapelbar gerufen werden können und teilweise mehrere Punkte für den resultierenden Punkt benötigen.
Erst wenn der Stapel zu 0 wird, ist der Punkt für die Übergabe an den Command  - egal welchen - bereit.
Nehmt mal an, ein Durchstoßpunkt einer Ebene - 3 Punkte - und einem Vektor - 2 Punkte - wird benötigt. Dieses Helferlein benötigt also 5 Punkte. Daher gibt erst beim 5.Punkt #p-force2cmd den Punkt an den Command weiter.
Es kann aber (auch) sein, dass irgendeiner oder mehrere Punkte durch weitere Helferlein auch weitere Punkte benötigen. Dann steigt die Zahl der points-needed weiter an.
Erst wenn die Variable #p_need_pnt_N zu 0 geworden ist, ist der Punkt fertig berechnet … usw.
Und warum ich mit COMMAND // VL-COMMAND Kindergarten spiele, hat aussschließlich mit dem Fehlverhalten von OSNAPCOORD zu tun.
Bitte das im Hinterkopf behalten oder so nicht in den Raum werfen!!!
Sonst wäre unsere Arbeit - die wir immerhin für den Hersteller leisten - nicht notwendig.
Unterschätzt mal bitte den Wert UNSERER Arbeit.

Danke! ... ToXoT
PS: die saubere Formatierung des Codes bekomm ich nicht hin.

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

---

>>"zuerst mal haben wir jetzt schon ganz schön viele Baustellen offen"
Wenn du mehr möchtest, sag bescheid!
Man findet im www genügend über was man bisher nicht selbst gestolpert ist.

>>"Kindergarten spiele, hat aussschließlich" ... "so nicht in den Raum werfen!!!
Neee, das hast du vollkommen falsch verstanden, weshalb ich (und Tom und andere) noch immer keine Antwort darauf haben -
da brauchts wohl noch ein paar Worte (= Zeit) mehr.

Die Rückmeldung jetzt ist (zu) kurz, aber ich wollte mich kurz gemeldet haben um zu sagen:
Heute vermutlich keine Zeit mehr dafür, vielleicht morgen oder spät abends.

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