---

Hi, wertvolle Gemeinde 

grread soll die Überwachung / Auswertung des bewegten Kursor und der Tastatur ermöglichen.
Ich habe schon seit Jahrzehnten Programme laufen, die für erweiterte Punktfänge diese Funktion nutzen.
Auch und vor allem dann, wenn ein Command läuft. ... also wenn cmdactive = 1 ... klar.

Nun friert aber der Cursor in AutoCAD2022. ... sehr Bug-Verdächtig.

Kleines Testprogramm nach ein paar Punkten einer Linie oder Poli aufrufen.

;;; freeze cursor in AC22 when cmdactive=1 tester
(defun foo( / ret)(while(= 5(setq ret(car(grread t 15 0)))))

Genau den Zweck, den grread erfüllen soll(Kursorverfolgung) wird in AC22 nicht mehr erfüllt.

Leemac hat ausdrücklich auf den Wert von grread hingewiesen.
Siehe ... http://www.lee-mac.com/grsnap.html

Hat jemand Rat, wie dieser Fehler beseitigt werden kann?
Liebe Grüße ...
ToXoT

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

---

In meiner Testumgebung Civil 3D 2022.1 mit AutoCAD 2022.1 Update friert der Cursor nicht ein nach dem Start von (foo) oder auch
Kreis (foo). Scheint dann wohl kein grundsätzliches Problem zu sein, oder ich habe die Problembeschreibung nicht richtig erfasst.
Hier ein kurzer Screencast dazu: https://autode.sk/3EvITO8

------------------
Mit freundlichem Gruß

Udo Hübner
www.CAD-Huebner.de

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

---

Danke für deine Nachricht!
Hast Du auch versucht, nach ein paar Linienpunkten und noch nicht abeschlossener Linien (foo)+ENTER einzugeben?
Der Cursor sollte sich - während noch keine Taste gedrückt ist - bewegen lassen.
Habe auf die Ausgabe der Cursor-Punkte verzichtet, weil das die Problematik nicht verdeutlicht.
Bei mir eben nicht.

Danke im Voraus für den Versuch 
ToXot

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

---

Sorry Udo,
deine Sorgfalt eilt mir voraus 
Danke
ToXot

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

---

Servus Udo,
nachdem für mich das Problem mit grread noch immer nicht gelöst ist, hab ich mir deine Antworten genauer angesehen.

Bitte versuch noch einmal - zB mit deinem Kreis Beispiel - folgendes ...
Progrämmchen nach wie vor ...

Code:

---

(defun foo( / ret)(while(= 5(setq ret(car(grread t))))))

---

Test 1 mit Kreis ...
.) Kreis + ENTER
.) Punkt im Zentrum angeben
... Durchmesser wird gefragt ...
.) (foo) + ENTER
... und genau da hängt bei mir der Cursor!
... in allen anderen Versionen war und ist das auch nicht der Fall.

Test 2 mit Linie ...
.) Linie + Enter
.) den Startpunkt klicken
.) (foo) + ENTER
... Cursor hängt.

Ich wäre Dir für ein nochmaliges Feadback sehr dankbar, weil auch das Update 2022.1 denselben BUG hat!

Lieben Gruß ...
ToXoT

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

---

Bereits am 26.Okt hattest du bereits an anderer Stelle die Bestätigung (des veränderten Verhaltens) erhalten,
auch den Hinweis dazu ein AutoDESK (und/oder Autodesk Devel/API) Support-Ticket zu starten. Hast du? Warum nicht?

Zu dem Thread hier:
1. Gerne bestätige ich dir das Verhalten wie von dir entdeckt
2. Udo hatte ja bereits mit 2022.1 getestet - wenn auch nicht genau deinen Fall.
3. Daher hättest du gerne auch seinen Fall testen &kommentieren dürfen :-)
  Es ist nicht generell bei cmdactive=1 der Fall, das siehst du auch in Udos Screencast.
    hier der Beispielfall: (foo) bei der Abfrage des Mittelpunktes des Kreises=Funktioniert, bei Abfrage des Radius jedoch nicht.
4. Ich hänge mich da nicht rein weil diese/deine Anwendung doch sehr speziell ist und die
  Recherche kaum einen Treffer liefert - wie dir wohl selbst bekannt ist.

Das Verhalten ist auch in der aktuellen Produktversion von 2022 so und ebenfalls im neuesten Produkt 2023
Halt uns auf dem Laufenden 

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

---

Dank Dir für die rasche Antwort und den Versuch sich dem dringenden Problem zu nähern!

Ich möchte ein wenig verständlich machen, warum dieses Thema in meinenem Umfeld von großer Bedeutung ist...
Seit Urzeiten verwenden meine Programme einen bis ins 3D erweiterten Punktfang.
So konnte ich - schon bevor AC fähig war - die Vorschau auf den Treffer des Fangs anzeigen und schwierigste 3D Projekte verwirklichen.
Ausserdem ist mein Standard-Punktfang nicht ständig aktiv, sondern muß mit der RM-Taste gerufen werden. Spezielle und singuläre Punktfänge (viele nich im Umfang von AC) werden mit einem zweiten Klick auf RM für ein VB-Popup an der Mausposition gerufen.

Es geht also um Ergonomie und Sicherheit beim Arbeiten im CAD. 

Dadurch konnten wir in vielen Architekturbüros Fehler - entstanden durch die Standardpunktfänge von AC (... zu viele in Kombi mit zu klein gezoomt)vermeiden.

GRREAD soll und sollte eben viele Fuktionen in Bezug auf den Cursor ermöglichen ... und wenn dann der Cursor stecken bleibt, wie in AC2022 dann ist für mich Schluß mit lustig.

Es ist auch eigenartig, dass dem Zentrum der Arbeit im CAD - der Cursorpotition - so wenig Aufmersamkeit geschenkt wurde / wird.
Erst OpenDCL nähert sich dieser Tatsache sorgfältiger.

Weder ist DCL fähig, ein POPUP an die Cursor-Position zu setzen, noch gibt es VLA / VLAX Routinen die Positions-Werte (auch für Multiscreen Umgebungen) liefern können.

Es irritiert mich doch sehr, dass dieser dringliche BUG noch immer nicht beseitigt ist.

Bin UDO sehr dankbar, er ist aber mit seinem Test knapp am Problem vorbeigeschrammt.
Draw-Befehle haben ein sehr ambivalentes Verhalten im Bezug auf die erste Punkteingabe.

Wenn zB. Kreis oder Linie gerufen wird, ist bis zu Abschluß CMDACTIVE=1 ... Klar und richtig.
Aber: wenn vor dem Setzen des ersten Punktes zB: (grread t)+ENTER gerufen wird, wird eigenartiter und unsinniger Weise LASTPOINT als Resultat angenommen.

... nicht genug ...

wird erst nach dem setzen des ersten Punktes einer Linie oder des Kreises die wiederholte Eingabe von (grread t) mit "point or keyword required" auf ein Problem (richtigerweise) hingewiesen.

Und hier stoppt der Cursor, wenn grread in einer While-Schleife läuft, um Osmode Zustände zu bearbeiten.
Auch Lee Mac hat hier hilfreiche Programme geschrieben, die sogar die Anzeige der Osnaps nachahmen.

Aus diesem Grund hat UDO das stecken des Cursors nicht bemerkt. Und Ich damals drauf reingefallen und war der Annahme, dass in seine AC-Version das Problem eben nicht existiert.
Auf das kam ich leider erst jetzt drauf.

Vielleicht hat jemand noch einen Tip, wie die Funktionalität von GRREAD wiederhergestellt // erhalten // ersetzt werden kann.

Dank Euch!
ToXoT

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

---

Ich kann nicht verstehen, warum ein echter BUG hier keine Antwort findet.
Es geht hier um die zentral wichtige Funktion GRREAD in AC, die in den Versionen 2021 und 2022 nicht funktionieren.

Ersuche dringend um Antwort!

ToXoT

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

---

Sag mal, was stimmt denn mit dir nicht?

Du hast da eine Änderung/Bug gefunden den es in einer sehr speziellen Situation gibt:
(Wenn innerhalb eines AutoCAD-Befehls aufgerufen).

Andere bestätigten das veränderte Cerhalten
und ab jetzt gibt es nur noch eine Adresse: Autodesk
Niemand sonst kann das Programm ändern.

An der Stelle warst du bereits im Oktober angelangt.

Was erwartest du von anderen Anwendern?

Das du überhaupt keinen Suchtreffer findest sollte dir ja selbst zeigen
wie exotisch dein Anwendungsfall ist,
daher drücke ich dir (uns) alle Daumen
was die Bug-Korrektur angeht.
Halt uns also auf dem Laufenden wie dein eröffneter Supportfall zu grread 2022/2023 verlaufen ist,
ich werde es noch an anderer Stelle melden.

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

---

Hallo Cadffm,

danke für Deine rasche Antwort und die Bestätigung.
... den persönlichen Angriff lass ich gerne weg!
Werd mich an AD wenden, da es leider auch keinen COM // OpenDCL Ersatz gibt.
Ich kann Dir versichern, dass meiner Anwendung nicht "Exotik" zu unterstellen ist.
Programmierer haben es nicht gern, wenn die Basis ihrer Arbeit schwankt.
Werd mich bei Dir / Euch melden, sobald es Neuigkeiten diesbezüglich gibt.

Gruß ...
ToXoT

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

---

>>".. den persönlichen Angriff lass ich gerne weg!"
Das ist nett, denn ich selbst halte derartige Formulierungen nicht automatisch als einen Angriff.
Durchaus wird derartige Formulierung auch als nachdrückliches Stilmittel eingesetzt um
den Angesprochenen zum erneuten analysieren der Gesamtsituation zu bewegen 

>>"Werd mich an AD wenden, "
Wurde dir direkt schon im Oktober gesagt, ein halbes Jahr (und eine AutoCAD-Version weiter!) für die 'Katz

>>"Ich kann Dir versichern, dass meiner Anwendung nicht "Exotik" zu unterstellen ist."
Du scheinst die Aussage nicht recht zu verstehen, ich antworte dennoch mit OH DOCH 

1. Programmierung ist ja schon eher selten in der Anwenderschaft, also sind die betroffenen schon mal
  der kleine Kreis der "Programmierer" - Das ist aber natürlich immer der Fall, bei jeder Programmierung.

2. GRREAD ist sicher recht wenig in Gebraucht (könnte man wahllos 1mio Tools von Festplatten ziehen, in wieviel davon wäre wohl Grread im Einsatz?)
  und mit "recht wenig" sind wir recht sicher bei "verschwindend gering".

3. Jetzt sind wir schon bei einer maximal homöopathischen Menge an Leuten/Funktionen!

  Und nun kommst du und sprichst von einem kleinen Teil dieser homöopathischen Menge,
  nämlich grread "transparent" innerhalb eines Befehls.

Das IST sehr exotisch in der Häufigkeit, wobei Grread an sich ja schon eher selten zum Einsatz kommt.

-

Ich habe gerade selbst mal nachgeschaut:
In meiner "Snipped und Beispiele" Schublade (mit Ausnahmen sind das alles nur "Findlinge" die ich mir mal bei Seite geleget habe)
finde ich ~30 LspDateien in den grread im Einsatz sind und auf die Schnelle konnte ich keinen Fall sehen der dafür vorgesehen ist
während eines AutoCAD-Befehls eingesetzt zu werden.
Bedeutet also: Von 30 Programmen funktionieren 30 Programme weiterhin ohne Probleme.

Auch habe ich darüber anscheinend noch nicht viel oder noch nie etwas für mich wichtiges gelesen,
ansonsten könnte ich mich erinnern. Das passt eben auch ganz gut dazu das dieses Problem seit
einem Jahr besteht, aber im engl/deu www noch nichts darüber zu lesen ist: Dein Anwendungsfall ist eben recht exotisch!

Exotisch oder nicht, es sollte sich nicht ändern (oder wenigstens vom Hersteller so absichtlich vorgenommen worden sein),
da ist jeder in der ganzen Welt auf deiner Seite. Wenn du Probleme mit SETQ hättest..
oder wenigstens mit GRREAD in der eigenen Routine (nicht transparent in einem AutoCAD-Befehl),
dann würde es viele Aufschreie geben, es wäre einiges nachzulesen.
AutoDESK hätte in den letzten 1,5 Jahren (Beta-Test Zeitraum mit eingerechnet) auch schon viele
Bugmeldungen dazu erhalten.

PS: Ich habe natürlich nicht alle 30 Progrämmchen getestet und auch sonst keinen "Stresstest" probiert,
sollte also irgendeine technische Aussage nicht zutreffen - Dann gib uns bitte noch ein Beispiel dazu.
(außer 'während eines AutoCAD-Befehls' natürlich)

Wie schon geschrieben: "den persönlichen Angriff" ist nur wie es bei dir ankommt, es ist aber keineswegs als persönlicher Angriff gemeint-
ist nur (m)eine retorische Aufforderung die Sache noch einmal mit Abstand zu betrachten. Hat nicht ganz funktioniert 
Man fragt sich nur ob du alle Informationen überliest (wohl kaum) oder warum du diese zu ignorieren scheinst.

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

---

Habe es jetzt mal in der AutoDESK Feedback Ecke als Bug angegeben.
Das war zwar nicht die richtige Stelle dafür, aber eventuell entwickelt sich daraus ja doch noch etwas
in die richtige Richtung :-)

Neben deinem "händischen Beispiel" mit Kreis+Durchmesser+(foo)
habe ich diese Funktion zum testen mitgegeben:
(defun c:GRT nil
  (setq ret 0)
  (defun foo () (while (= 5 (car(grread t 15 0))) (terpri)(princ (itoa(setq ret (1+ ret))))) 15)
  (alert "1. Pick the center point and\n2. move the cursor: Can you see the cursor moving?\n\n3. Click again to draw the 15rad Circle")
  (command "_.CIRCLE" PAUSE (foo))
  (alert "In 2022/2023 the crosshair doesn't follow your movements, this is the bug i am talking about!")
)

Auch das erhöht die Erfolgschance: Plug'n'play, copy'n'paste Beispiele welche möglichst keinen Interpretationsspielraum bieten.
1. Versuchen es dann ggf. mehr Leute
2. Erkennen damit auch mehr Leute das Problem

Ich drücke uns die Daumen, dir natürlich ganz besonders.

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

---

Ergänzung:

Mit MEINER Beispielfunktion siehst du auch mehr von dem Problem!

In 2021 und älter erhält grread neuen Input wenn du den Cursor bewegst,
in 2022 erhält grread ständig input! Auch wenn keine Eingaben (wie Bewegung der Maus) erfolgen.

Noch eine Sacher mehr welche die Chance erhöht von Adesk Rückmeldung zu bekommen.

Somit sehe ich dein "Cursorproblem" nur als Nebeneffekt für das eigentliche Problem an,
GRREAD erhält Unmengen an Daten, ich vermute die Cursor-Anzeige wird in dem Fall unterdrückt.

Ob das Unterdrücken jetzt ein absichtlicher Effekt ist im AutoCAD oder nicht kann ich schlecht,
bewerten in diesem speziellen Fall.

Heimliche Vermutung meinerseits: Das hängt im Ursprung mit den neuen 'schwebenden Dateifenster' zusammen.

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

---

Hallo Cadffm,
dank Dir für deine Sorgfalt und dein Bemühen!
Ich selber arbeite schon lange nur mehr mit BricsCAD, wo grread einfach funktioniert und das performanter!
Meine Programme werden in mehreren Arch. und Ing. Büros (nach wie vor / noch immer) verwendet, für die - wie für mich - die erweiterten Punkfänge eben wertvoll und alles andere als "exotisch" sind.
So wurde mir dieses Problem von mehreren Seiten zugetragen und die Ursache war via Fernwartung schnell gefunden.
Man musste ja nur während CMDACIVE=1 ... (grread t) ... eingeben, und schon war es passiert.
Bin Dir aber für dein Bemühen sehr dankbar, weil Du - neben Udo - dich um das Problem gekümmert und mir sehr wertvolles Feedback gegeben hast!!!
Dein Tip, dass der Fehler mit den neuen schwebenden Zeichnungsfenstern zusammenhängen könnte, hat was.
Auch, dass grread jetzt auch ohne Mausbewegung permanent feuert.
Wir werden sehen, wie sich die Sache jetzt entwickelt.
Beste Dir / Euch
ToXoT

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

---

Zitat:

---

Original erstellt von toxot:

Ich selber arbeite schon lange nur mehr mit BricsCAD, wo grread einfach funktioniert und das performanter!

---

Der Großteil meiner Kunden, darunter auch sehr große Industriekunden, ist auf BricsCAD umgestiegen, und ich bin jetzt mit der V22 engültig auch mit meiner Entwicklung auf BricsCAD umgestiegen. BLADE - die Lisp Entwicklungsumegbung mit Debugger in BricCAD - ist IMO zwar noch nicht ganz so leistungsfähig wie VLIDE in AutoCAD, aber es geht schon.

Genau mit GRREAD hatte aber BricsCAD auch einen sehr exotischen Bug, der mindestens bis in die Version V14 zurück verfolgt werden konnte. War eben eine exotische Situation, in die erst einer meiner Kunden mit der V21 reingestolpert ist. Da wurde dann bei einem nach GRREAD folgenden Command-Aufruf der erste an den Command übergebene Punkt nicht als der übergeben, der explizit im Lisp-Quellcode stand, sondern der Wert aus der Variablen LASTPOINT. Und dann wurde natürlich irgendwas falsches gezeichnet ...

BricsCAD hat sicher nicht weniger Fehler als AutoCAD. Aber der BricsCAD Support ist extrem gut, und man kriegt idR schon wenige Tage nach Meldung eines Bugs eine neue Version, in der dieser behoben ist. Vielleicht sollte Bricsys das so machen wie seinerzeit Donald Knuth (der Gottvater der Algorithmik, der heute leider nur noch wenigen bekannt ist) mit seinem bis heute unübertroffenen Textsatzprogramm TeX (den meisten  als Form von LaTeX bekannt). Der hat ab einem bestimmten Zeitpunkt der Entwicklung die Meldung von Bugs mit Geld belohnt, und der Betrag stieg immer weiter, je fehlerfreier das Programm wurde. Er (bzw die Orginasation, die TeX weiter führt) hat nun schon seit einigen Jahren nichts mehr ausbezahlen müssen.

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

---

@archtools

der Support von BC ist tatsächlich vorbildlich!
Es scheint auch ein Vorteil zu sein, dass BC in Europa entwickelt wird.
.. .weiters ist die Geschwindigkeit oft um ein vielfaches höher.
... die sogenannten Optionen / Einstellungen sind vorbildlich aufgeräumt und mit Suchfunktion sogar ergonomisch.

In der BIM-Version bleibt man in gewohnter Umgebung! ... da kommt Freude auf.

Das Preis/Leistungsverhältnis stimmt und die Software kann nach wie vor gekauft werden.
Mietsoftware ist ja in Bezug niedrige Auslastung ist als "Geschäftsmodell" unzulänglich, oder gar unfair.
Schon lange fehlt ein Lizenzmodell, dass Bezug auf die tatsächliche Verwendungszeit und das Einsatzziel nimmt!!! ... Oder?
Man spürt bei BC einfach, dass die Entwickler ein gutes Produkt wollen.

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

---

nicht wichtig, aber falls es in 2023.0.0 anders gewesen sein sollte - Ich kann mich nicht erinnern:

Test1 (Kreis zeichnen)
in ACAD 2023.1.2 kann ich den Cursor frei bewegen, aber der Kreis hängt NICHT sichtbar am Cursor
und falls man es aktiviert hat - auch die dynamische Anzeige fehlt für die Zeit des (foo) ist der Kreis also nicht sichtbar.

Eine positive Entwicklung, aber noch immer nicht wie es sollte.

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

---

@cadffm
Danke für die Info!
Ich kann erst nächste Woche testen/bestätigen.

Bitte probier auch was passiert, wenn Du eine Poli zeichnest und nach ein paar Punkten
(foo) aufrufst. Siehe Programm unten.

Wenn sich dann mit der MR-Taste der Screen zoomen und panen lässt, ist der Bug weg 
Während (foo) läuft, ist aber (in dieser Version: noch) keine Gummiband sichtbar.
Wenn Du dann die LM-Taste klickst, sollte ein weiterer Punkt der Poli gezeichnet worden sein.

Hier nochmal das Programm foo ... mit grread-Wertefluss Ausgabe.

Code:

---

(defun foo( / grr) ; + grread output printed ...
  (while(=(car(setq grr(grread 5)))5)(princ grr)(terpri))
  (command(nth 1 grr)))

---

lG ToXoT

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

---

Negative in 2022, positiv in 2023 

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