Topic: Astable oscillation of lisp menu command - why is this?

[AKS]

I am looking for help in regard to AutoCAD endlessly repeating lisp commands. I suspect there is a basic concept I am not aware of and that you guys might help. The commands appear to generate an error and then re-execute in endless astable oscillation. Escaping is only possible by riding the escape key until it stops. The oscillation will restart after escaping if another different command is not first activated. This happens when the command is activated as a custom tool palette item, as a custom ribbon item or even when entered by keyboard. I know this is not machine specific.  A while ago I posted this problem in another forum as a issue using tpnavigate in a tool palette command. That is how I first encountered it, so please bear with me here. Now I see it happening in a lisp that I have been modifying. Seeing the problem occurring to a simple lisp sequence using out of the box AutoCAD commands used in a menu context and also seeing it occurring in this modified lisp application is why I am posting here. This lisp takes one argument.

Focusing on the lisp that I have modified, I know the modification works just fine as I developed it through the IDE. In fact, and I bet this is a huge hint for you guys in the know, it always works without oscillation the first time it is invoked after loading. During the oscillation I can see that an error automatically generates at the point where a getpoint occurs. It appears to me that an error response is automatically fed to getpoint instead of waiting for a picked point, whereupon the lisp errors out but then restarts as if the return or spacebar key had been pressed. Presumably the restarted lisp sees that error generating input when it reaches the getpoint and thus the restart cycle goes on and on.

Part of the modification I made to the lisp, which contains both the original function and a modified version ( The original incidentally does not oscillate.), eliminated a getword continue or not prompt used to control a while loop. The modified lisp uses an unspecified while for that loop so that the interface requires no additional user response to continue. The escape key stops the process.  Another modification replaces an original entsel within that while loop with a specified while not ent & not point loop used to return a selected line and a point on that line. This is a solution to the problem of entsel not actually returning a point on the selected element. This issue is discussed here at theswamp but a working example was not presented that I could understand, so this lisp passes a getpoint to a nentselp to wind up with both the selected element and the point on that element. The visual effects of combining getpoint with a nearest osnap turns out in this application to be better than the entsel visual.  This while loop seems to survive any input, screen or keyboard, except an escape, which is as desired. It is this getpoint mentioned above in the oscillation description. There are no other getpoints in the lisp.

This lisp has a prompted mode which it knows to do based upon the argument passed at invocation. The prompted mode runs a getstring prior to entering the main while loop mentioned above. Oscillation does not happen when running in this prompted mode.

The lisp has its own internal error handler and resetter which appears to be functioning.

Seing this problem happening to both this modified lisp and a run of the mill regular menu lisp command makes me think I am missing a simple, dope slapping, basic concept, like how to properly zero out the AutoCAD state before and possibly after invoking a command. For example, and I might be wrong about this, if a place Line command is used before the lisp, then I'll see that Line command reinvoked after escaping out of the lisp or after the tpnavigate tool palette command. The menu commands use proceeding ^C^C which I now believe mean nothing in this case as I can see that nothing short of reloading the lisp prevents oscillation when the lisp has already been invoked once. It is as if the loaded and already once run lisp is in a state of suspension when restarted. 

Sorry this has been so long a post but I thought it is necessary to clearly describe the situation. Help would be much obliged.

Thank you. aks

[CAB]

Long as the post is I still don't have enough information to solve your problem. 
Starting with ^C^C cancels any active command so no problem there.
Sometimes the pause used to pause for user input is redefined within a lisp causing problems.
Most often a while loop is receiving the wrong result and loops forever.

Best results come from posting some sample code for analysis.
If you don't want to post the entire code strip out non relevant code & post something that does cause
the infinite loop.

[AKS]

Thanks. I'll post the code when I have the chance. I think I can say the while loop is not looping forever, in fact it may not even loop (i.e. repeat ) once. I can see the lisp's exiting error handler output following the getpoint prompt in each oscillation. It is the lisp's invoking command that repeats just like in the tpnavigate tool palette menu case it is the invoking command that repeats. That code is simply, if I can remember it right, is any variation of ^C^C(-tpnavigate "thepalettename");. By variation I mean I've tried adding pauses, spaces, returns and cancels every where to see if it made any difference. The tpnavigate case is interesting in that its oscillation does not always occur.

[irneb]

Have you tried placing a break point somewhere to be able to step into each action in the lisp? Thn also add some watches to check how variables' values' change. That way you can try to figure out where the problem occurs.

BTW, this sounds a lot like a sticky spacebar/enter key. But obviously I can't say with any type of sertainty - just a guess in the wind 

[AKS]

Yes I have been break pointing and watching. I can actually ride the oscillation with the debugger going but I do not know how to get the IDE to tell me the specific error condition. So I see where the error occurs (at the getpoint) but not a explanation of what is the error. I am convinced this must be a basic concept thing that I am totally clueless about and that you guys might take for granted. For example for in the tpnaviagte oscillation I actually was using ^c^c(command "tpnavigate" "palletename"); which I now see can be accomplished with ^c^ctpnaviagte;palletename;. I do not know what the fundamental difference is but I suspect it is significant. I have not yet determined if the difference will not result in the oscillation for that item.