Topic: Quit without causing error

[mailmaverick]

I have a routine in which number of input datas are asked from the user before actual program execution starts.

All inputs are graphically through DCL. There are 5-6 DCL Windows which open one by one and the user has to select required data.

In case the user presses Cancel in any one of the DCL Window, the program execution must stop there itself.

As per DCL, I know how to know that the user has pressed Cancel. But problem is how to stop program execution ?

Till date, I know only of (quit). (quit) is also an error because when we do program debugging and Tick the option of Last Break Source, the program stops at every (quit) call. Thus, it means that (quit) is not a normal way of exiting program and is an error.

What is the normal way of exiting a LISP routine, without an error ?

[JohnK]

You need an error handler.

[mailmaverick]

Dear John

As I mentioned in my original post, if user presses Cancel, then it is not an error.

Program has to stop without an error.

If I use errorhandler routine, then in that also, I have to use (quit).

[ronjonp]

..
What is the normal way of exiting a LISP routine, without an error ?

Step through your code and check what throws errors. Then account for that.

Simple Example:

Code - Auto/Visual Lisp: [Select]

1. ;; Bombs if user presses enter or misses pick
2. (setq el (entget (car (entsel))))
3. ;; No error unless ESC
4. (if (setq e (car (entsel)))
5.   (setq el (entget e))
6. )

[MP]

You need to capture the cancel event, save said state to a variable and then have the various levels of your program gracefully exit based on said state (or any other appropriate state). I can't provide a code snip because I'm on my mobile. It's all do-able tho, I and others have done it. tl;dr: In before Lee.

[mailmaverick]

..
What is the normal way of exiting a LISP routine, without an error ?

Step through your code and check what throws errors. Then account for that.

Simple Example:

Code - Auto/Visual Lisp: [Select]

1. ;; Bombs if user presses enter or misses pick
2. (setq el (entget (car (entsel))))
3. ;; No error unless ESC
4. (if (setq e (car (entsel)))
5.   (setq el (entget e))
6. )

Dear Ron, as I mentioned earlier, there is no error.

I want to just quit the routine.

[JohnK]

Dear John

As I mentioned in my original post, if user presses Cancel, then it is not an error.

Program has to stop without an error.

If I use errorhandler routine, then in that also, I have to use (quit).

1. Read MPs post.
2. You need an error handler (many people have them the following is only a start and one version).
http://www.theswamp.org/index.php?topic=13730.msg167503#msg167503

[ronjonp]

..
What is the normal way of exiting a LISP routine, without an error ?

Step through your code and check what throws errors. Then account for that.

Simple Example:

Code - Auto/Visual Lisp: [Select]

1. ;; Bombs if user presses enter or misses pick
2. (setq el (entget (car (entsel))))
3. ;; No error unless ESC
4. (if (setq e (car (entsel)))
5.   (setq el (entget e))
6. )

Dear Ron, as I mentioned earlier, there is no error.

I want to just quit the routine.

In my mind (quit) is an error event. That's why you need an error event handler (*error*). You either use an error event handler or you tighten up your code.

[MP]

Pressing escape is not an error, it is an event. You don't need an error handler, you need an event handler. Semantically yours, MP.

[CAB]

In my mind (quit) is an error. That's why you need an error handler. You either use an error handler or you tighten up your code.

[ronjonp]

Pressing escape is not an error, it is an event. You don't need an error handler, you need an event handler. Semantically yours, MP.

  Edit above.

[MP]

C'mon you guys. Do I need to do this from my mobile? Put a button on the dialog. Call it btn_cancel. Caption it "Cancel". Set it's is_cancel property to true. Capture said event. Deal with it. 

[Lee Mac]

tl;dr: In before Lee.

 

[MP]

[JohnK]

Coffee does not laugh, especially out loud. Semantically speaking that is.

[MP]

Coffee does not laugh, especially out loud. Semantically speaking that is.

[Jeff H]

What if you have a event handler that causes an error and caught in your error handler that causes the previous event that is caught by event handler.
...
...
Mind=Blown

[MP]

What if you have a event handler that causes an error and caught in your error handler that causes the previous event that is caught by event handler.

Windows 1.0

[Kerry]

[interuption]

All inputs are graphically through DCL. There are 5-6 DCL Windows which open one by one and the user has to select required data.

I just had a vision of life before dialogs, when data entry had to be done by iterating through text prompts.


[/return to your normal program]

[ur_naz]

you may use sequent cheking instead interrupting

Code - Auto/Visual Lisp: [Select]

1. ;; run 1st dlg and get a as boolean
2. (setq a (run_dlg1))
3.  
4. ;; run 2nd dlg and get b
5. (if a (setq b (run_dlg2)))
6.  
7.  ;; run 3rd dlg and get c
8. (if b (setq c (run_dlg3)))
9.  
10. ;; Do the same as long as u need
11.  
12. ;; run 100500th dlg
13. (if qwerty1 (setq qwerty2 (run_dlg100500)))
14.  
15. ;; when tired run yo function
16. (if qwerty2 (run_ur_f_kng_rtn))

[irneb]

You either use an error event handler or you tighten up your code.

Exactly! If you don't want to make an *error* event handler which closes the code gracefully on quit/cancel events, then your code needs to be written such that it expects and caters for those cancel events. The easiest way to go about this is to do what every experienced programmer should be doing in any case: make small atomic functions performing only one single task.

I.e. instead of opening and closing each dialog in one ginormous function, have a single function for each dialog. Then in each of those functions it either returns nil (to indicate cancel), some value (to indicate the input), or a nil/T for Cancel/Ok and setq the inputs to some other variable (though I don't like the later option - smells too much of using global variables, you could quote some arguments to these functions of course).

Then catering for such things as cancels is a very simple matter of wrapping all the calls to these dialog functions in an and. Something like this (using the idea of nil for cancel, else the inputs as a list of values):

Code - Auto/Visual Lisp: [Select]

1. (if (and (setq val1 (dialog1)) (setq val2 (dialog2)) ... (setq valN (dialogN)))
2.    (progn
3.       ;; Perform actions when user entered all data without any cancels, i.e. pressed the "OK" button in all dialogs.
4.    )
5.    ;; Else if you need to do something on a cancel you can do it here, otherwise just don't put anything in this spot.
6. )
7. ;; Any code which needs to happen irrespective if the user pressed cancel or not can go here

[Kerry]

< .. >

Then catering for such things as cancels is a very simple matter of wrapping all the calls to these dialog functions in an and. Something like this (using the idea of nil for cancel, else the inputs as a list of values):
< .. >

That would be the way I'd do it.