IDE Will Not Show Steps Through Loaded App

[Bill Tillman]

I'm running AutoCAD 2013 with the latest Service Pack #2. I like to break parts of these LISP programs into smaller files so as to make changes to the entire project easier. OK, so I'm running one of the big files and it reaches a point where loading one of the smaller programs is needed. That goes well.

 

This is where I may not fully understand how the IDE works. If I hit a bug in the little program I toggle a break point in the small file and save it. Then rerun the main program expecting it to pause at the break point I set. But it does not stop and continues on running through the entire smaller program and then completes the bigger program unless I have other break points set therein.

 

Now, what I have found is that if I set the break point just before the smaller program is loaded I can step through the smaller program. Perhaps this is the only way it works.

 

Then there is this big problem. After coding all day I hit a bug and then toggle the break point just before the small app is loaded as I mentioned above. But this time when it starts stepping through the smaller program, none of the lines being executed are highlighted. As I continue to F8 step through the program, I can see that it is continuing to step through it, but I cannot see which line is being run. The screen flickers ever so slightly but nothing is highlighted. Rebooting seems to correct the problem. But this happens almost everyday and usually after several hours of coding. About the same time I'm ready to take off my shoe and throw it through the monitor...step through...get it?

[BlackBox]

Breakpoints are not saved with the code file(s)... They're only recognized within VLIDE itself.

 

To step through the way you're after, open each nested file, set the appropriate break points, and load each snippet of code from within VLIDE... The implied task here being that if your 'large' code calls the LOAD function, you may need to comment that out, as when you loaded that snippet with/without breakpoints the dependent functions were already defined.

 

 

 

[Edit] - You're just getting spoiled coding in Visual Studio, methinks. Next you'll be like 'Why'd my VLIDE intellisense stop working!?!'

[Bill Tillman]

[Edit] - You're just getting spoiled coding in Visual Studio, methinks. Next you'll be like 'Why'd my VLIDE intellisense stop working!?!'

 

There is no doubt that programming in Visual Studio is most of the time, a pleasant diversion. And I am being asked to do more and more of it around here in addition to LISP. According to some sources, one should be able to make the complete move away from LISP into VB.NET or C#.NET and do everything you can do with LISP. I can tell you that 18 months ago when I started this gig, had I known then what I know now, I would have done lots of things differently. C'est la vie.

 

As to why my VLISP IDE stops highlighting the lines of code being executed in the loaded apps...I think that's just memory creep or M$ bugs. But it happens almost everyday.

 

And yes, one must comment out the LOAD lines otherwise the main program will reload the smaller program sans the break points.

 

And remember, the purpose of development is to create time for debugging.

[Tyke]

I agree with BB on this one. In Visual Studio .NET 2010 and 2012 the breakpoints are saved with the file, as are bookmarks. But I don't know of any other programming for AutoCAD that does it. VBA, LISP and Visual LISP never did when I tried it.

 

You might try inserting your small files into your main program, just for debugging purposes and then moving them out when they run OK.

[BlackBox]

There is no doubt that programming in Visual Studio is most of the time a pleasant diversion. And I am being asked to do more and more of it around here in addition to LISP. According to some sources, one should be able to make the complete move away from LISP into VB.NET or C#.NET and do everything you can do with LISP. I can tell you that 18 months ago when I started this gig, had I known then what I know now, I would have done lots of things differently. C'est la vie.

 

I wish I could find that ADNDevBlog article I recently commented in... The author use managed code to call LISP via SendStringToExecute() (if memory serves) as a demonstrative way of accomplishing whatever the task was at hand... Pathetic... The only response I could muster tactfully was something to the effect of "Really!?" followed by an image link to Tommy Lee Jones' 'implied facepalm' pic.

 

I agree with BB on this one. In Visual Studio .NET 2010 and 2012 the breakpoints are saved with the file, as are bookmarks. But I don't know of any other programming for AutoCAD that does it. VBA, LISP and Visual LISP never did when I tried it.

 

You might try inserting your small files into your main program, just for debugging purposes and then moving them out when they run OK.

 

Perhaps using LISP++ in lieu of VLIDE (never tried it personally)?

 

 

 

Also, as an aside, instead of having your main code load your dependent code file(s), perhaps it's instead better to add a header to the main code to load the dependent code file(s) on first run, so that even if you demand load (via AUTOLOAD) the main code, the actual body of the main code file doesn't do the loading... Slows performance, and obviously creates this issue for you now. Simpler, methinks.

 

Good luck!

[Bill Tillman]

I have often resorted to exactly what Tyke suggests, moving the smaller code into the main code until the debugging is under control. The project I'm working is an automated drawing creation with so many IFs it often gets out of hand. But breaking the code up into smaller chunks is not so much for performance as it is to be able to make a change only once to one file which will then transfer to all the big programs which call on it.

[Tyke]

I have often resorted to exactly what Tyke suggests, moving the smaller code into the main code until the debugging is under control. The project I'm working is an automated drawing creation with so many IFs it often gets out of hand. But breaking the code up into smaller chunks is not so much for performance as it is to be able to make a change only once to one file which will then transfer to all the big programs which call on it.

 

That's a good principle Bill. It's something that I'm going to implement in VS on my next project. I've used code snippets up to now, but they just bloat the program. A series of small routines (DLLs or LISP routines) which would be called with passing parameters and would return a value (like a function) or do something (like a sub). It makes software maintenance much easier and the program code much more readable.

[Bill Tillman]

I'm revisiting this post due to something I seem to have discovered by accident. As I referenced above, I use a modular approach to these projects and break code into different files that are only loaded if needed. In trying to debug I found that the IDE wouldn't always being showing the steps through the secondary code which got loaded by the main program. When stepping through the code it would show the file in the IDE but it would not highlight the lines as they were being run. Yesterday, and much to my surprise, I found that if I don't have the secondary file(s) open in the IDE, I was able to see the lines being highlighted as they were being individually run. This creates only a slight problem because I'm often editing numerous files while working on this project. But it does appear that if I want to see the lines in the secondary loaded files being highlighted I must close that file down first before running the main program. That seems to resolve this issue.

 

Oh, I forgot to mention that you have to toggle a breakpoint somewhere near or at least before you load and execute the secondary file.

 

Now, I don't do drugs anymore...not for a long time...but if I recall correctly, there were times when the IDE would highlight the individual lines in the secondary file as I stepped through it even though the file was opened in the IDE in another window. I'm sure of this because I remember when the problem would happen I would reboot my computer and it would start working again...at least that is how I remember it. In any case, I seem to find, that on this setup anyway, closing the secondary file window before running the main program allows me to see the highlighted lines in the secondary file as I step through it. And that's important for debugging these files, some of which approach 4K to 5K lines in length.

Edited September 19, 2013 by Bill Tillman

[Bill Tillman]

Just to confirm this point again today I was working on code from more than one source which gets loaded if and only if needed. If you want to step through the code in these secondary programs, you will have to close them first after saving them. Once it's closed and you start your debug session just pick a point somewhere along the way but close enough to the location where the secondary file gets loaded. Then and only then, will you get to see the individual lines in the secondary files being highlighted as they are being executed. I had to come back and look at this post again because I knew I discovered something about this, just couldn't remember what.... Old age I guess!