Error Trapping Routine

[TJARONIK]

Hello All,

Does anyone have some error trapping code I could add to a routine I made? May be a silly question and may be posted wayyyyyyyyyyyyyyyyyy down the list of topics. I am just trying to get a fresh thread so that I don't have to search for an hour through the threads.

Thanks in advance.

"Catch" Ya Later,
Tim

 

[TJARONIK]

My apologies. See enclosed lisp routine.

"Catch" Ya Later,
Tim

 

[Chip Harper]

I posted an example lisp yesterday for section cuts, if you want to see another error code example. Look for the thread titled "Revert back to current layer".

 

[TJARONIK]

Chip and others,

I added the error trapping you suggested and I think it is working fine. However, when I type the dtext using this routine and I type more than one line, the error trapping will restore the variables I have told it to restore in the error trap, but... it does not remove/erase the lines of text that were written before the point at which the routine was cancelled. I have pasted the code below. My question is would it be better to do an undo mark and if it errors to return to that undo mark?

Thanks in advance. I REALLY appreciate your input.

(defun CTC( / OSMODE CMDECHO CLAYER TEXTSTYLE DIMSCALE *ERROR* STARTPOINT) (setq OSMODE(getvar "OSMODE")) (setvar "OSMODE" 0) (setq CMDECHO(getvar "CMDECHO")) (setvar "CMDECHO" 0) (setq CLAYER(getvar "CLAYER")) (setq TEXTSTYLE(getvar "TEXTSTYLE")) (setq DIMSCALE(getvar "DIMSCALE")) (defun *ERROR* (msg)     (if       (member msg '("console break" "Function cancelled" "quit / exit abort") )        (princ (strcat "\nError: " msg "\n"))       &nbsp (setvar "CMDECHO" CMDECHO) (setvar "OSMODE" OSMODE) (setvar "CLAYER" CLAYER) (setvar "TEXTSTYLE" TEXTSTYLE) )     (command "-layer" "thaw" "TEXT" "on" "TEXT" "make" "TEXT" "color" "2" "TEXT" "lt" "continuous" "TEXT" "")         (command "-style" "SIMPLEX" "SIMPLEX.shx" "0.00000000" "0.90000000" "0.00000000" "N" "N" "N")      (setq STARTPOINT(getpoint "\nPick the CENTER point: "))      (command "dtext" "j" "Center" STARTPOINT (* DIMSCALE 0.12500000) "0.00000000") (*ERROR* nil) (princ)
)

"Catch" Ya Later,
Tim

 

[Chip Harper]

I would say that the idea with the mark and undo in the error trap is the way to go.

 

[TJARONIK]

My apologies for asking. Can you advise as to how I do that?

Thanks.

"Catch" Ya Later,
Tim

 

[Chip Harper]

Oops .. hit send too soon ... heres an earlier lisp that I added the mark but the user had to manually "Undo" at the command line. It was written for R14 I think.

 

[Tom Smith]

Put a (command "undo" "begin") as early in your CTC function as possible. Usually it's the first thing I do, right after turning cmdecho off (users don't like seeing "undo" commands echoed). Then put a (command "undo" "end") as late in the function as possible. Like right before turning cmdecho back on. Since you're calling *error* explicitly to do your cleanup, a good way to do this would be to put the (command "undo" "end") in the error handler.

 

It's worthwhile to bite the bullet and write a general-purpose error handler that all of your functions can call. It can eliminate a lot of repetitive coding.

 

 

TJARONIK <> wrote:

Chip and others,

I added the error trapping you suggested and I think it is working fine. However, when I type the dtext using this routine and I type more than one line, the error trapping will restore the variables I have told it to restore in the error trap, but... it does not remove/erase the lines of text that were written before the point at which the routine was cancelled. I have pasted the code below. My question is would it be better to do an undo mark and if it errors to return to that undo mark?

Thanks in advance. I REALLY appreciate your input.

(defun CTC( / OSMODE CMDECHO CLAYER TEXTSTYLE DIMSCALE *ERROR* STARTPOINT) (setq OSMODE(getvar "OSMODE")) (setvar "OSMODE" 0) (setq CMDECHO(getvar "CMDECHO")) (setvar "CMDECHO" 0) (setq CLAYER(getvar "CLAYER")) (setq TEXTSTYLE(getvar "TEXTSTYLE")) (setq DIMSCALE(getvar "DIMSCALE")) (defun *ERROR* (msg)     (if       (member msg '("console break" "Function cancelled" "quit / exit abort") )        (princ (strcat "\nError: " msg "\n"))       &nbsp (setvar "CMDECHO" CMDECHO) (setvar "OSMODE" OSMODE) (setvar "CLAYER" CLAYER) (setvar "TEXTSTYLE" TEXTSTYLE) )     (command "-layer" "thaw" "TEXT" "on" "TEXT" "make" "TEXT" "color" "2" "TEXT" "lt" "continuous" "TEXT" "")         (command "-style" "SIMPLEX" "SIMPLEX.shx" "0.00000000" "0.90000000" "0.00000000" "N" "N" "N")      (setq STARTPOINT(getpoint "\nPick the CENTER point: "))      (command "dtext" "j" "Center" STARTPOINT (* DIMSCALE 0.12500000) "0.00000000") (*ERROR* nil) (princ)
)

"Catch" Ya Later,
Tim

 

[TJARONIK]

I'm sorry guys. Maybe I am missing something here. I have tried the suggestions you have made. But my problem still remains. When I type...say.... 3 lines of dtext hit return and before entering the 4th line of text I hit the "esc" key the 3 lines of text I wrote are still there but the variables have reverted to their originals settings. This tells me that the error trap is working as far as variables go but not as far as erasing the entities(dtext) I created. Is the "undo" part something I will have to do manually or is it something that the error trap can handle? Maybe by creating a group of the dtext and if it errors exploding that group which would effectively erase the dtext of that group, but of course first making the group selectable?

"Catch" Ya Later,
Tim a.k.a. Frustrated in Alaska

 

[R. Robert Bell]

<soapbox>

Just what is this insistence on using Undo Marks?

Let's give this a bit of perspective. I, the user, am planning on trying out a few things on my drawing. So I set an Undo Mark, confident that I can get back to this current state by using Undo Back. Now I, the poor unwitting user, uses Bob Billy's routines that set Undo Marks each time I run his code. After using his routine for 100 times, and deciding to return my drawing back to the original state, blissfully use an Undo Back. <huh?> Another Undo Back. <what?> Another Undo Back <curses> Another Undo Back...

Now consider the wise programmer Billy Bob using Undo Begin/End instead, in the same scenario. After hundreds of time using the routine, I issue an Undo Back to return to the original state. <yeah!> I'm back where I started!

<Sample log>
Command: CIRCLE
Specify center point for circle or [3P/2P/Ttr (tan tan radius)]:
Specify radius of circle or [Diameter] <2.2785>:
Command: CMDECHO
Enter new value for CMDECHO <1>: 0
Command: UNDO
Enter the number of operations to undo or [Auto/Control/BEgin/End/Mark/Back] <1>: m

Command: (defun C:L (command "._undo" "_m") (command ".line" pause pause "") (princ))
C:L

Command: L
Command: L
Command: L
Command: L
Command: L
Command: UNDO
Enter the number of operations to undo or [Auto/Control/BEgin/End/Mark/Back] <1>: b (Lisp Expression) GROUP Mark encountered

Command: UNDO
Enter the number of operations to undo or [Auto/Control/BEgin/End/Mark/Back] <1>: b (Lisp Expression) GROUP Mark encountered

Command: UNDO
Enter the number of operations to undo or [Auto/Control/BEgin/End/Mark/Back] <1>: b (Lisp Expression) GROUP Mark encountered

Command: UNDO
Enter the number of operations to undo or [Auto/Control/BEgin/End/Mark/Back] <1>: b (Lisp Expression) GROUP Mark encountered

Command: UNDO
Enter the number of operations to undo or [Auto/Control/BEgin/End/Mark/Back] <1>: b (Lisp Expression) GROUP Mark encountered

;;; Wow, I'm *finally* done. <blech>

Command: UNDO
Enter the number of operations to undo or [Auto/Control/BEgin/End/Mark/Back] <1>: m

Command: (defun C:L (command "._undo" "_be") (command ".line" pause pause "") (command "._undo" "_e") (princ))
C:L

Command: L
Command: L
Command: L
Command: L
Command: L
Command: UNDO
Enter the number of operations to undo or [Auto/Control/BEgin/End/Mark/Back] <1>: b GROUP GROUP GROUP GROUP GROUP Mark encountered

;;; Wow, *that* was quick
</Sample log>

Naturally, error handling will need to be more involved, but I covered that in a thread within the last two days.

</soapbox>

--
R. Robert Bell, MCSE
www.AcadX.com

| Before you start placing dtext add this:
| (command "undo" "mark")
|
| In your error trap code as this:
| (command "undo" "back")
|
| --
|
| Chip Harper
| Member of the AutoDesk Discussion Forum Moderator Program | | |

 

[Timothy Spangler]

With all of this talk about undo and ERROR handlers My question would be this.

If I use undo BEgin before setting any variables, and in the error handler I had undo End, If I had esc'd out of the routine would it change all of my variable back with out having to reset the environment? I usually have a sub that resets all vars after a clean end to the program I also use it for errors. If this is correct then I wouldn't need to add a reset in the error handler. Correct?

Good observation, Herman. It's sloppy programming, strictly speaking, but it's something I never quite resolved in doing an application-specific error handler. If your default setting was cmdecho on, this could be annoying, as it would keep getting turned off with an undo.

The problem with putting the cmdecho controls "inside" the undo controls, though, is that it results in the unattractive multiline "undo" prompts being echoed at beginning and end of your function. So a normal running of a routine with cmdecho initially turned on would always result in at least:

undo Enter the number of operations to undo or
[Auto/Control/BEgin/End/Mark/Back] <1>: begin
<whatever your routine does>
Command: undo Enter the number of operations to undo or [Auto/Control/BEgin/End/Mark/Back] <1>: end

I suppose that wouldn't be awful if you were accustomed to cmdecho always being on. But my users aren't; they expect functions to run quietly, without displaying gibberish that doesn't concern them.

So my excuse for the sloppiness is that I basically always want cmdecho turned off anyway. The only reason to turn it off in a particular routine is just to make sure. The rare times I turn it on are when I'm doing something like using a pause in a command sequence, and I'm depending on Acad to supply the appropriate prompts. In those cases I make sure it gets turned on and then back off again.

I wonder if you have a better suggestion for Tim on how to handle this in his scenario?

But I don't actually do error-handling routine by routine anymore, I just call a general-purpose one that takes a list of variables to be saved and restored. It does things in a more complicated way than Tim probably cares about, but it does handle the cmdecho bugaboo properly.

Which means, if I am reading this correctly, that a normal exit from the routine, followed by an UNDO, will leave CMDECHO .

 

[R. Robert Bell]

Easy enough. Quicky sample code, flesh out to your desire.

(defun C:Test (/ *Error* Doc CmdEcho)
(vl-Load-Com)
(defun *Error* (msg) ; localized error handler, echo *no* messages (vla-EndUndoMark Doc) ; end open undo group (if msg (command "._U") ) (setvar "CmdEcho" CmdEcho) (princ)) (setq Doc (vla-Get-ActiveDocument (vlax-Get-Acad-Object))) (vla-EndUndoMark Doc) ; end any open undo group (vla-StartUndoMark Doc) ; start new group (setq CmdEcho (getvar "CmdEcho")) (setvar "CmdEcho" 0) (command "._Line" pause pause "") (command "._Circle" pause pause)
(*Error* nil))

--
R. Robert Bell, MCSE
www.AcadX.com

| Good observation, Herman. It's sloppy programming, strictly speaking, but | it's something I never quite resolved in doing an application-specific error | handler. If your default setting was cmdecho on, this could be annoying, as | it would keep getting turned off with an undo. | | The problem with putting the cmdecho controls "inside" the undo controls, | though, is that it results in the unattractive multiline "undo" prompts | being echoed at beginning and end of your function. So a normal running of a | routine with cmdecho initially turned on would always result in at least:
|
| undo Enter the number of operations to undo or
| [Auto/Control/BEgin/End/Mark/Back] <1>: begin
| <whatever your routine does>
| Command: undo Enter the number of operations to undo or | [Auto/Control/BEgin/End/Mark/Back] <1>: end | | I suppose that wouldn't be awful if you were accustomed to cmdecho always | being on. But my users aren't; they expect functions to run quietly, without | displaying gibberish that doesn't concern them. | | So my excuse for the sloppiness is that I basically always want cmdecho | turned off anyway. The only reason to turn it off in a particular routine is | just to make sure. The rare times I turn it on are when I'm doing something | like using a pause in a command sequence, and I'm depending on Acad to | supply the appropriate prompts. In those cases I make sure it gets turned on | and then back off again. | | I wonder if you have a better suggestion for Tim on how to handle this in | his scenario? | | But I don't actually do error-handling routine by routine anymore, I just | call a general-purpose one that takes a list of variables to be saved and | restored. It does things in a more complicated way than Tim probably cares | about, but it does handle the cmdecho bugaboo properly. | | | | > In article , Tom | > Smith wrote:
| > > Usually it's the first thing I do, right after turning cmdecho off | > > | > Which means, if I am reading this correctly, that a normal exit from | > the routine, followed by an UNDO, will leave CMDECHO | . | > | | |

 

[R. Robert Bell]

Incorrect. Try the following example.

(defun C:Test (/ *Error* hi)
(defun *Error* (msg)
(alert (strcat "Error left it at " (itoa (getvar "Highlight")))) (princ)) (setvar "Highlight" 1) ; force to 1 for example (alert (strcat "Forced to " (itoa (getvar "Highlight")))) (setq hi (getvar "Highlight")) (setvar "Highlight" 0) ; force to 0 for example (alert (strcat "Set to " (itoa (getvar "Highlight")))) (command "._erase" "_si" pause) (setvar "Highlight" hi) ; reset (alert (strcat "Restored to " (itoa (getvar "Highlight"))))
(princ))

--
R. Robert Bell, MCSE
www.AcadX.com

| With all of this talk about undo and ERROR handlers My question would be | this. | | If I use undo BEgin before setting any variables, and in the error handler I | had undo End, If I had esc'd out of the routine would it change all of my | variable back with out having to reset the environment? I usually have a | sub that resets all vars after a clean end to the program I also use it for | errors. If this is correct then I wouldn't need to add a reset in the error | handler. Correct? | | -- | _________________________________ | Timothy Spangler | | "You cannot escape the responsibility of tomorrow by evading it today" | Abraham Lincoln | _________________________________ | | AutoCAD 2002 | WinXP | Compaq Evo W6000 | Intel Xeon / 1G RAM | | > Good observation, Herman. It's sloppy programming, strictly speaking, but | > it's something I never quite resolved in doing an application-specific | error | > handler. If your default setting was cmdecho on, this could be annoying, | as | > it would keep getting turned off with an undo. | > | > The problem with putting the cmdecho controls "inside" the undo controls, | > though, is that it results in the unattractive multiline "undo" prompts | > being echoed at beginning and end of your function. So a normal running of | a | > routine with cmdecho initially turned on would always result in at least:
| >
| > undo Enter the number of operations to undo or
| > [Auto/Control/BEgin/End/Mark/Back] <1>: begin
| > <whatever your routine does>
| > Command: undo Enter the number of operations to undo or | > [Auto/Control/BEgin/End/Mark/Back] <1>: end | > | > I suppose that wouldn't be awful if you were accustomed to cmdecho always | > being on. But my users aren't; they expect functions to run quietly, | without | > displaying gibberish that doesn't concern them. | > | > So my excuse for the sloppiness is that I basically always want cmdecho | > turned off anyway. The only reason to turn it off in a particular routine | is | > just to make sure. The rare times I turn it on are when I'm doing | something | > like using a pause in a command sequence, and I'm depending on Acad to | > supply the appropriate prompts. In those cases I make sure it gets turned | on | > and then back off again. | > | > I wonder if you have a better suggestion for Tim on how to handle this in | > his scenario? | > | > But I don't actually do error-handling routine by routine anymore, I just | > call a general-purpose one that takes a list of variables to be saved and | > restored. It does things in a more complicated way than Tim probably cares | > about, but it does handle the cmdecho bugaboo properly. | > | > | > | > > In article , Tom | > > Smith wrote:
| > > > Usually it's the first thing I do, right after turning cmdecho off | > > > | > > Which means, if I am reading this correctly, that a normal exit from | > > the routine, followed by an UNDO, will leave CMDECHO | > . | > > | > | > | > | |

 

[Tom Smith]

No, see my provious post. The undo begin/end simply creates a "group" of operations that can be undone at once with a single "u" command. Nothing gets reset unless you do the "u". And in that case it would also undo everything your function just did.

With all of this talk about undo and ERROR handlers My question would be this.

If I use undo BEgin before setting any variables, and in the error handler I had undo End, If I had esc'd out of the routine would it change all of my variable back with out having to reset the environment? I usually have a sub that resets all vars after a clean end to the program I also use it for errors. If this is correct then I wouldn't need to add a reset in the error handler. Correct?

Good observation, Herman. It's sloppy programming, strictly speaking, but it's something I never quite resolved in doing an application-specific error handler. If your default setting was cmdecho on, this could be annoying, as it would keep getting turned off with an undo.

The problem with putting the cmdecho controls "inside" the undo controls, though, is that it results in the unattractive multiline "undo" prompts being echoed at beginning and end of your function. So a normal running

of

a
routine with cmdecho initially turned on would always result in at least:

undo Enter the number of operations to undo or
[Auto/Control/BEgin/End/Mark/Back] <1>: begin
<whatever your routine does>
Command: undo Enter the number of operations to undo or [Auto/Control/BEgin/End/Mark/Back] <1>: end

I suppose that wouldn't be awful if you were accustomed to cmdecho always being on. But my users aren't; they expect functions to run quietly, without displaying gibberish that doesn't concern them.

So my excuse for the sloppiness is that I basically always want cmdecho turned off anyway. The only reason to turn it off in a particular

routine

is
just to make sure. The rare times I turn it on are when I'm doing something like using a pause in a command sequence, and I'm depending on Acad to supply the appropriate prompts. In those cases I make sure it gets

turned

on
and then back off again.

I wonder if you have a better suggestion for Tim on how to handle this in his scenario?

But I don't actually do error-handling routine by routine anymore, I just call a general-purpose one that takes a list of variables to be saved and restored. It does things in a more complicated way than Tim probably cares about, but it does handle the cmdecho bugaboo properly.

 

[TJARONIK]

Gentlemen,

How about this. Can anyone get this thing to work? I do not want to run a thread to death with "this way that way". Again, I am no programmer and I do appreciate everything everyone has said and done. I really do. However, I still can not get this thing to work correctly. In a nutshell and hopefully with some relative simplicity here is what the routine should do.

1.) Check the current layer being used and store it's value.
2.) Check the current text style being used and store it's value.
3.) Store the current dimscale setting for later use.
4.) Check to see if the TEXT layer is thawed and on....even if it is not there the routine continues on to "RE-make" the layer with the color and linetype being set/re-set. If the TEXT layer is there, thawing and turning on the TEXT layer makes it available to type the upcoming dtext.
5.) Ask the user to select the "start point" of the dtext and store that point.
6.) Start the DTEXT command justified according to the particular routine used(i.e. center, top center, etc.), use the "start point" requested from the user earlier, check the dimscale and multiply it by 0.12500000(1/8) and using a rotation angle of 0.00000000.
7.) Return to the layer in use before running this routine.
8.) Return to the text style in use before running this routine.
9.) Resetting any other system variables(i.e. osmode, cmdecho, etc.) to their original states before running this routine.
10.) If the routine errors for whatever reason anywhere during it's operation, return everything back to what it was before running the routine.

Now, exactly the code to do the error part of the routine is proving to be varied. I can use the routine without any error trapping just fine. I have been doing lines and circles long enough to know how to get to where I want to be with ease. All I am trying to do is to make a routine that is as easy for John Q. Drawer to use that will require as little "thinking" about layers, styles, justifications, etc. as possible. I have yet to see a routine like this that does what I am asking it to do. I think it will be very useful as we all use dtext. I am NOT going to profit from this in any way shape or form.

If anyone can take the attached "Basic" code(DTC_ORG.lsp) I have written and write a working error trapping routine in it according to what I have outlined above, that would be FANTASTIC. I am NOT asking you to make a special effort to do this, but if you would like to....Please do. All I can offer is my gratitude and respect for your knowledge and time. If not, I will keep using the routine I wrote about 7 or 8 years ago. It's basic and real programmers would be disgusted at my coding technique, but hey it works. This is my job, not my life. When my day ends today, I am going home, get my fly fishing gear and heading out to the river to catch some more awesome Alaskan Silver(Coho) Salmon which provides me with personal joy and feeds my family.

And finally, Everyone that has posted their comments and suggestions I thank you from the bottom of my heart. It is good people like you that make this world a much more enjoyable place to live. You ROCK.

T H A N K Y O U.................

"Catch" Ya Later,
Tim

 

[John Purchase]

I have become interested in the various comments regarding this problem

I am not sure why you do not use the DTEXT command followed by the Justify option as shown below:-

&nbsp;

Regards

John

&nbsp;

Command: dtext

&nbsp;

Current text style:&nbsp; "SIMPLEX"&nbsp; Text height:&nbsp; 0.125 Specify start point of text or [Justify/Style]: j Enter an option [Align/Fit/Center/Middle/Right/TL/TC/TR/ML/MC/MR/BL/BC/BR]: bc

&nbsp;

Specify bottom-center point of text: end
of
Specify height &lt;0.125&gt;:

&nbsp;

Specify rotation angle of text &lt;0&gt;:

&nbsp;

Enter text: my text
Enter text:

 

[John Purchase]

Tim

I have hacked around with your routine and have come up with the attached.

Although it does not look nice it appears to work.

What do you think?

John

"TJARONIK" &lt;&gt; wrote:

John,

Because I want to type.... DTC to start the dtext command with a justification of center, DTM to start the dtext command with a justification of middle, etc. Because I always use the same text style and layer with set colors, I have chosen to include those in the routine so that when I type DTC or whatever, it will make sure those are set for me and I don't have to do any checking to make sure I am on the right layer or on the right text style. The routine will also check the dimscale and scale the text accordingly. Makes it a "no-brainer" way to type dtext.

"Catch" Ya Later,
Tim

 

[TJARONIK]

John,
for some reason I can not download the attatchment. Could you email it to me or paste the code in here? Thanks in advance.

"Catc" Ya Later,
Tim

 

[John Purchase]

Tim

I changed your code slightly to include the subroutine (mlayer) which I have found very useful in many other of my routines in the past.

If the layer TEXT does not already exist then this subroutine makes it for you.

I agree I also have been unable to erase the text after hitting the "esc" key but It can be erased by typing "u" on the following command line. (Not so bad?)

I have been using Autocad for approx 20 years and possibly like you self taught.I am now semi retired but I&nbsp;still find Autolisp&nbsp;interesting

&nbsp;If&nbsp; a solution can be found for this problem I would like to now what it is.

The following is an extract from Autodesk Customation Guide for R13&nbsp; :-

The AutoCAD DTEXT and SKETCH commands read the keyboard and digitizer directly and therefore cannot be used with the AutoLISP command function. If the SCRIPT command is used with the command function, it should be the last function call in the AutoLISP routine.

Not much has changed!!??

Regards

John

&nbsp;

&nbsp;

"TJARONIK" &lt;&gt; wrote:

Never mind. I was able to download it. Although it is coded differently it still does not erase the text you have written if you hit the "esc" key. Did it work for you? Maybe it's my configuration or something?

"Catch" Ya Later,
Tim