Jump to content

Recommended Posts

Posted

Hi there.

 

In a routine I made I used grread to allow me to trap the use of "escape" to cancel the selection without exiting the routine. I was very disappointed to see that (in AutoCAD 2015 sp2) it sporadically fail and exit anyway. What I found out is that in 2015 if the Track argument is T , escape trapping will most likely fail in the first 1 to 3 times escape is used. Of course the Track argument is required when grread is used to give a dynamic preview. Here is my command line showing it bomb at the 3rd try for aa and the 2nd time for bb

Command: (aa t)

escape

escape

escape; error: Function cancelled

Command: (bb t)

Pressed escape

Pressed escape ; error: Function cancelled

 

If the Track argument is false, it still can blow even if usually it traps 20-50 times correctly before letting one slip. I tried 2 approaches, both using catch-all-apply, one using error-p to trap, the other one forcing a nil value to the input. Both approaches have similar results.

 

Can you try (aa T) and (bb T), then try to spam escape. Please tell me if it works or fails, along with the product/year you tried it on. (note: Use Enter to exit the 2 functions)

;http://www.theswamp.org/index.php?topic=27900.msg334947#msg334947
;_GetChar by mp modified to test grread escape traping

(defun aa (track / done data key result);

   ;;  return the character for the key pressed
   
   (while (not done)
       ;;  stay in the loop until the user presses a key
       (vl-catch-all-apply
          '(lambda ( )
               (setq
                   data nil
                   data (grread track 14 1)
               )
           )
       )
       (setq
           key    (car data)
           result (cadr data)
       )
       (cond
           ;;  user pressed <esc>
           ((null data) (princ "\nescape"))
           ;;  user pressed a key
           ((eq 2 key) (setq done t))
           ;;  user hit right mouse button, consider same as enter
           ((eq 25 key)(setq done t result 13))
       )
   )

   (chr result)

)

;http://www.theswamp.org/index.php?topic=27900.msg334940#msg334940
;test by cab modified to test grread escape traping
;originally (grread t 11 0). End up failing either if grread track argument is nil or t
;hit enter to exit

(defun bb (track / input LastPT ent obj )
 (vl-load-com)
 (while ; stay in loop until one of the COND statements return nil
   (progn
     (setq input (vl-catch-all-apply 'grread (list track (+ 1 2  0)))
   (cond
     ((vl-catch-all-error-p input)
  (princ "\nPressed escape ")
  t ; exit
     )
     ((= 5 (car input)) ; pointing device
      (cond
        ((and LastPT (< (distance (cadr input) LastPT) 0.0001))) ; no update if same point
        ((setq ent (nentselp (setq LastPT (cadr input))))
   (setq obj (vlax-ename->vla-object (car ent)))
   (princ (strcat "\nFound a " (vla-get-objectname obj) " at "(vl-princ-to-string (cadr ent))))
)
      )
      t ; stay in loop
     )
     ((= 2 (car input)) ; Keyboard input
      (princ (vl-prin1-to-string input))
      (if (= (cadr input) 13)
          nil ;exit loop
          t) ; stay in loop
      )
     ((= 3 (car input))  ; Selected 3d point
      (if (setq ent (nentselp (cadr input)))
(progn
   (setq obj (vlax-ename->vla-object (car ent)))
   (princ (strcat "\nFound a " (vla-get-objectname obj) " at the point selected: "(vl-princ-to-string (cadr ent))))
   )
)
      t ; stay in loop
      )
     )
    )
   ) ; while
 (princ)
 )

 

Is the problem only in cad 2015? (comments / suggestions welcome)

Posted

All 4 variations seems to work fine on my ACAD 2017 (they're printing that escape has been pressed).

Just once I was able to sumulate an error - I think with (bb t), but it was something initial so I wasn't able to reproduce it in the further tests.

Posted

in your bb version shouldn't you use nil instead of t?

 

 

 ((vl-catch-all-error-p input) (princ "\nPressed escape ") t ); exit 

 

 

 ((vl-catch-all-error-p input) (princ "\nPressed escape ") nil ) 

 

 

assuming you want to leave loop when escape is pressed...

 

 

gr.Rlx

Posted

 ((vl-catch-all-error-p input) (princ "\nPressed escape ") nil ) 

 

assuming you want to leave loop when escape is pressed...

 

You can even:

 

 ((vl-catch-all-error-p input) (prompt "\nPressed escape ") ) 

Posted
You can even:

 

 ((vl-catch-all-error-p input) (prompt "\nPressed escape ") ) 

 

 

Well done Grrr, you even saved 3 characters! :beer:

Posted
Well done Grrr, you even saved 3 characters! :beer:

 

I know this prompt/princ return trick by investigating some of Lee's codes, where he was while-looping a cond structure, and sometimes he princ'ed and sometimes prompt'ed.

:beer:

Posted

...Can you try (aa T) and (bb T), then try to spam escape. Please tell me if it works or fails, along with the product/year you tried it on

 

hi Jef & guys

tested on ac2007

(aa nil) - cursor missing but you set curtype=1, then no issue :)

so all 4 tested okey without error

Posted

@RLX

in your bb version shouldn't you use nil instead of t?
No, see below.

 

assuming you want to leave loop when escape is pressed...
Nah, I stay in the loop after escape is pressed. The lisp I made is (supposed to) go "back" without interrupting the lisp, for example think how ssget works: if you input the first point, hitting escape wont exit/error the ssget, but rather just cancel the 1rst point... I did something supposed to behave like that but escape trap failed 50% of time and exit anyway. I use tracking T as I track mouse position to update a dynamic display too. The examples here is some snippets I found and modified solelly to see if they would bomb too by mashiing escape (hence why I modified them to stay in the grread after hitting escape), trying to find out if the escape trap failing of my code could be due to something else like a combination of grread with some other function I use, but on my side my code and both examples all have the same behavior/random fail. It enabled me to pinpoint the culprits, which are aparently a combination of using grread with tracking along with 2015.

 

Just once I was able to sumulate an error - I think with (bb t), but it was something initial so I wasn't able to reproduce it in the further tests.
Even once is once too many imo. Kind'of sad to make a code that can crash unexpectedly because of a bug that reside outside of my code - so bug that I cannot fix. It is like there is a reactor that interrupts the code before it errors, but sometimes the reactor is triggered too slowly - after the error is evaluated?

 

Well, thanks for trying and giving feedback guys, I appreciate!

ps.: it is not the first time that I find a bug that seems to exist only on CAD 2015.

Posted
@RLX

No, see below.

 

Nah, I stay in the loop after escape is pressed. The lisp I made is (supposed to) go "back" without interrupting the lisp, for example think how ssget works: if you input the first point, hitting escape wont exit/error the ssget, but rather just cancel the 1rst point... I did something supposed to behave like that but escape trap failed 50% of time and exit anyway. I use tracking T as I track mouse position to update a dynamic display too. The examples here is some snippets I found and modified solelly to see if they would bomb too by mashiing escape (hence why I modified them to stay in the grread after hitting escape), trying to find out if the escape trap failing of my code could be due to something else like a combination of grread with some other function I use, but on my side my code and both examples all have the same behavior/random fail. It enabled me to pinpoint the culprits, which are aparently a combination of using grread with tracking along with 2015.

 

Even once is once too many imo. Kind'of sad to make a code that can crash unexpectedly because of a bug that reside outside of my code - so bug that I cannot fix. It is like there is a reactor that interrupts the code before it errors, but sometimes the reactor is triggered too slowly - after the error is evaluated?

 

Well, thanks for trying and giving feedback guys, I appreciate!

ps.: it is not the first time that I find a bug that seems to exist only on CAD 2015.

 

did a double grread a while back ( http://www.cadtutor.net/forum/showthread.php?102976-Lisp-for-copy-text...variations-on-the-theme/page2 ) but in the end it all depends on what your app is suppost to do. I only use grread for special cases (or for fun of course) But I hope you find an acceptable solution :beer:

Posted
But I hope you find an acceptable solution :beer:
So far everything works as planned beside when escape trapping fail... which was only the whole point of making the code I made.^^

An acceptable solution? I think I might have found one, but I need a lisp editor. Let's wait and see when Bricscad 18.2 (with BLADE editor) will be available for Linux. I really can't wait to give a serious try at ditching both Autodesk and Microsoft. :twisted:

winlol.png

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...