Stupid runing of a Lisp program - CUI load vs Load Application

[eakos1]

Hello,

I’ve created more programs, we made a toolbar for them, the programs were added through the CUI (Customize User Interface) . So the programs will load automatically by starting the AutoCAD program.

But one program LINE_REMOVE_ZIGZAG somehow works strange / wrong this way. But if I load this program through the Tools/Load Application than works fine.

   vs 

The program makes in the polyline:

1. deletes from the polyline the segments with 0 length
2. if between two ARCs are two or more lines will leave only one
   
3. f one ARC segment became from more ARCs with the same radius than maks from them only one ARC
   
4. Checks if there is a "zigzag" in the polyline

An example for good an stupid working:

    

What I could figure out, that there are two "big" SUB rutine in the program. Removing the lines with zero length and union of the ARCs. 

I've made from this two separate programs and added them to AutoCAD so they should load automatically by starting the program. 

Only added the Removing the zero length (RDI:clean_poly) had no affect to the running of the program - it worked still stupid way. 

But added the  RDI:ARC_union to the automatic load by start - the program worked well. Probably in this SUBrutine should be something. 

Has anybody an idea how can make the loading way once running good and once wrongly the program ???

The same code should run the same way always, or ??? 

Has anybody experienced similar thing? 

[Sea-Haven]

I have always made custom toolbars and not used the cui. So click on icon and the 1st thing is Load lisp then run it, gets around any preloading etc. For preloaded use again a custom lisp that is Appload and added to start up suite, within the auto loaded lisp are the option of defuns or using the "(autoload" inbuilt function that loads a lisp when you type a command name.

Happy to provide more info, this is one of my pop menu.

[Kent1Cooper]

I can't explain why it would work differently depending on the loading situation, but in looking at your drawing, I wonder whether it could be affected by the fact that some arc segments that combine incorrectly do not actually have common center points / equal radii.

This is part of the starting-state drawing, in which I put the incorrect resulting arcs, dimmer/dashed, so you can see where the difference occurs.  The white things are Lines drawn between the centers of the adjacent arc segments that are being combined incorrectly.  In the cyan one at right, it's clear the centers are not quite in the same place, though the radii seem to be equal down to the maximum accuracy I could investigate.  In the green ones, the white look like points, but they are very short Lines, and the radii of the arc segments are also different by very small amounts.

If they should be combined only if they are truly concentric/tangent/equal-radius, then I wonder how the one that "gets it right" does that.  If that's because of a tolerance/fuzz-factor, might that have something to do with why the other approach "gets it wrong"?  I don't have any ideas, if the difference is only in how they're loaded, but maybe it's a place to start looking for an explanation.

[eakos1]

Thank you, I realized it too. I've changed my code, now I'm checking the distance between the two center point, furthermore the calculation of new bulge was also wrong - also corrected. 

[eakos1]

Very strange. When I loaded my program through the Load Application then worked well, I was happy. But soon I realized that this program destroyed other programs, from that point other program worked stupid way. When I not loaded this program the others worked well. 

But now with this modification seems everything fine. 

[Kent1Cooper]

---

@eakos1 wrote:

.... this program destroyed other programs, .... 

---

That implies that there are things in this program and in those others that are not localized, so their definitions remain in effect after the programs are run, and can be overwritten by non-localized variables/sub-routines of the same names coming from other programs.  Those can be variables created with (setq) and also sub-routines created with (defun).  Go through and make sure all those variable and sub-routine names are in the localized variables list, both here and in those other programs, and you may eliminate the interferences.  I didn't check in detail, but I see at least some sub-routines here, such as change_width, that are not in the list.