Author Topic: Quit without causing error  (Read 5459 times)

0 Members and 1 Guest are viewing this topic.

MP

  • Seagull
  • Posts: 17750
  • Have thousands of dwgs to process? Contact me.
Re: Quit without causing error
« Reply #15 on: April 03, 2015, 04:35:21 PM »
Coffee does not laugh, especially out loud. Semantically speaking that is.

Engineering Technologist • CAD Automation Practitioner
Automation ▸ Design ▸ Drafting ▸ Document Control ▸ Client
cadanalyst@gmail.comhttp://cadanalyst.slack.comhttp://linkedin.com/in/cadanalyst

Jeff H

  • Needs a day job
  • Posts: 6151
Re: Quit without causing error
« Reply #16 on: April 03, 2015, 06:28:05 PM »
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

  • Seagull
  • Posts: 17750
  • Have thousands of dwgs to process? Contact me.
Re: Quit without causing error
« Reply #17 on: April 03, 2015, 06:34:02 PM »
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
Engineering Technologist • CAD Automation Practitioner
Automation ▸ Design ▸ Drafting ▸ Document Control ▸ Client
cadanalyst@gmail.comhttp://cadanalyst.slack.comhttp://linkedin.com/in/cadanalyst

Kerry

  • Mesozoic relic
  • Seagull
  • Posts: 11654
  • class keyThumper<T>:ILazy<T>
Re: Quit without causing error
« Reply #18 on: April 03, 2015, 06:40:14 PM »
[interuption]

Quote
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]
kdub, kdub_nz in other timelines.
Perfection is not optional.
Everything will work just as you expect it to, unless your expectations are incorrect.
Discipline: None at all.

ur_naz

  • Newt
  • Posts: 68
  • Made in Ukraine
Re: Quit without causing error
« Reply #19 on: April 08, 2015, 07:45:56 PM »
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

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: Quit without causing error
« Reply #20 on: April 09, 2015, 01:51:42 AM »
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
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

Kerry

  • Mesozoic relic
  • Seagull
  • Posts: 11654
  • class keyThumper<T>:ILazy<T>
Re: Quit without causing error
« Reply #21 on: April 09, 2015, 01:55:06 AM »
< .. >

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.



kdub, kdub_nz in other timelines.
Perfection is not optional.
Everything will work just as you expect it to, unless your expectations are incorrect.
Discipline: None at all.