VLIDE: Loading a LISP with breakpoint fails

[guitarguy1685]

So this happens to me from time to time.  In a lisp, I'll insert a break point with F9 so that I can debug the lisp.  Sometimes when I do this the entire function is highlighted in blue and doesn't load.  I get stuck in VLIDE and then I have to press F8 until I'm out.  The lisp is never loaded.  If I don't press F8 I have to close VLIDE which tells me I'm in a loop.

 

Somtimes these are very short lisps and everything seems okay, but I can't figure out what causes this.  Any ideas?

[rlx]

Don't think a lisp routine itself would be responsible for this kind of behaviour but even if it could , testing the same routine on an other machine should give the same result. So either your vlide installation has become corrupt or some other software is interfering with it. Disabling all auto loaded lisp routines / reactors could be a start. Another lisp routine could be causing an error but put the blame on your sweet innocent new born routine.

 

Maybe your F9 key is a hot key for another application loaded in your windows system tray? To test this , use the hand symbol for placing a break. I have tried AutoCad 2020 for example on my notebook and my touchpad behavier feels somehow different. Normaly double tab could close AutoCad , now I have to really press hard in lower left corner. So driver problem? Or maybe just something stupid like your keyboard needs a (permanent) vacation... or key-repeat speed is set too high.

 

Before loading a routine always save first , run check lisp code and then load it and place breaks. And when you go to lunch , close AutoCad so you start fresh & clean. Other more exotic explanation would involve an unstable cpu (can happen when you experiment with a higher clock frequency and cpu gets too hot) or a faulty memory chip. Although rare events , I have had them all... result : totally unpredictable computer followed by going nuts (still not fully recovered from that after all these years)

 

And else ... re-install / upgrade

 

ps. In the debug menu you have the option 'stop once' , is this on or off? make sure its off...

Edited April 5, 2019 by rlx

[BIGAL]

You can cut and paste code direct to command line but can not have blank lines also change defun so variables are not reset use (defun c:xxx () etc I tend to write code pasting a few lines at a time. Just find vlide locks up to hard on errors.

 

I put (princ in places and print variable values so can see if something is not working. Remove when finished stuff like in a  repeat  (princ x)

 

A  hammer approach use (exit) in code but run outside Vlide. Then use the !varname method to see what value variables are.

[rlx]

Like BIGAL suggests , if this happens ALL the time to your code (instead of random) than its defenitly your own code. If debug is set to 'break on error' its doing just that :  what its suppost to do.  In that case you need to learn how to debug. You have asked this before

 

lots of links on internet how to debug your visual lisp code

 

https://www.afralisp.net/autolisp/tutorials/debugging.php

 

https://hyperpics.blogs.com/beyond_the_ui/2017/03/debugging-autolisp-programs-part-2-basic-debugging.html

 

but still most important make sure all code is inside a defun so it can be loaded in the first place. If you do'nt , code will run directly when loading. And before loading , like I said before , use the option 'check code in editor' first.

[rlx]

chapter 4 , page 32 and beyond...

 

not sure if its copyrighted (anymore) because its all over the internet forums, but if so , don't be a scrooge and buy it. I did , in Kindle format on Amazon.

 

And if that doesn't work , just post the code thats bugging ya...

The_Visual_LISP_Developers_Bible.pdf