catching an error from (command

[Anonymous]

Hi,

I want to use (command..., but depending on the circumstances, the prompts
change.

Is there a way to trap the error if (command....) bombs out so I can use a
second or third set of options? I want to continue until one of them doesn't
fail, kind of like:

(and
(trap-error (command .....))
(trap-error (command .....))
(trap-error (command .....))
)

Thanks,
Mark

[Anonymous]

I suppose you could trap an error with vl-catch-all-apply but
under what circumstances can you not test for the required
input before executing the command?

--
Autodesk Discussion Group Facilitator


"Mark Ingram" wrote in message
news:5682811@discussion.autodesk.com...
Hi,

I want to use (command..., but depending on the circumstances, the prompts
change.

Is there a way to trap the error if (command....) bombs out so I can use a
second or third set of options? I want to continue until one of them doesn't
fail, kind of like:

(and
(trap-error (command .....))
(trap-error (command .....))
(trap-error (command .....))
)

Thanks,
Mark

[Anonymous]

I agree with Jason -- in most cases where I've encountered differences in command prompts, they're predictable. For instance, the prompt sequence may be version-specific, or specific to the context (such as not prompting for text height if it's fixed).

If you can enumerate all the possible options, as you imply, then it would seem you could predict which optiopn is applicable, and use it directly rather than use a trial-and-error method based on bombing out.

Maybe iyou could be more specific about the task at hand.

[Anonymous]

Hi Jason / Tom

In this case Aecobjexplode (ADT4/6/AA08) has different prompt sequence
depending on the type of objects that are in the drawing, and I can test
accurately about 80% of the time which isn't good enough, and causes the
function to fail. I'm using the function in a script processing large groups
of drawings, so if the function fails, the script fails and causes a real
mess.

In the code below, I am able to test for the error successfully, but the
error prompt is still returned causing the script to fail. The function will
finish correctly as the error is caught, but the script bombs due to the
error still throwing the error message to the command prompt.

I've tried vl-cmdf, but it also still echoes the "invalid input" to the
command prompt.

Here's the core issue = this function works by itself, but I need to make
the error trap silent - no command error being echoed to the command prompt.
The vl-error object isn't the issue, it's the command echo. Is there a way
to "wrap" the vl-catch-all-apply to silence the command error echo?

Thanks for your time,
Mark

(and
(if
(vl-catch-all-apply '(lambda () (apply 'command
(list ".-aecobjexplode"
"y" ;..explode to primitive
"c" ;..Views to explode [Current/All]:
"y" ;..Re-use existing names for Layers and Block Definitions?
[Yes/No]
"n" ;..Bind Xrefs?
"n" ;..Explode to anonymous blocks? (if yes, aec objects become
anon blocks)
"y" ;..Maintain Resolved Layer, Color, and Linetype?
"y" ;..Erase AEC objects?
"n" ;..Use short symbol names?
"n" ;..Display status messages?
"y" ;..You should either Bind these Xrefs first or run...
continue?
)
)))
(progn (command)(command) t) ;..t keeps AND going
)
(if
(vl-catch-all-apply '(lambda () (apply 'command
(list ".-aecobjexplode"
"y" ;..explode to primitive
"n" ;..Bind Xrefs?
"n" ;..Explode to anonymous blocks? (if yes, aec objects become
anon blocks)
"y" ;..Maintain Resolved Layer, Color, and Linetype?
"y" ;..Erase AEC objects?
"n" ;..Use short symbol names?
"n" ;..Display status messages?
"y" ;..continue?
)
)))
(progn (command) (command) t) ;..t keeps AND going
)
)

[Anonymous]

The only thing I can think of to try would be the NOMUTT
system variable, but I'm not sure if that will do what you want.

--
Autodesk Discussion Group Facilitator


"Mark Ingram" wrote in message
news:5683530@discussion.autodesk.com...
Here's the core issue = this function works by itself, but I need to make
the error trap silent - no command error being echoed to the command prompt.
The vl-error object isn't the issue, it's the command echo. Is there a way
to "wrap" the vl-catch-all-apply to silence the command error echo?

[Anonymous]

Mark,

My advice would be to deal with binding the xrefs first, then you can do
something like this:
(if (ssget "x" '((0 . "viewport")))
(command ".-aecobjexplode" "Y" "C" "Y" "Y" "Y" "N" "N")
(command ".-aecobjexplode" "Y" "Y" "Y" "Y" "N" "N")
)
This is what I do. I say Yes to Explode to anonymous, so you will need to
modify the above to suit. I don't ever get the Continue prompt, so it's not
answered in my code. If you still do get it sometimes, you could follow the
above with:
(if (> (getvar "cmdactive") 0) (command "Y"))
and then
(while (> (getvar "cmdactive") 0) (command ""))
to answer anything else (though I can't imagine what).

HTH

Ken Krupa
Autodesk Authorized Developer
Krupa CADD Solutions
www.krupacadd.com
KCS Productivity Pack for AEC
KCS Productivity Pack for AutoCAD



"Mark Ingram" wrote in message
news:5683530@discussion.autodesk.com...
Hi Jason / Tom

In this case Aecobjexplode (ADT4/6/AA08) has different prompt sequence
depending on the type of objects that are in the drawing, and I can test
accurately about 80% of the time which isn't good enough, and causes the
function to fail. I'm using the function in a script processing large groups
of drawings, so if the function fails, the script fails and causes a real
mess.

In the code below, I am able to test for the error successfully, but the
error prompt is still returned causing the script to fail. The function will
finish correctly as the error is caught, but the script bombs due to the
error still throwing the error message to the command prompt.

I've tried vl-cmdf, but it also still echoes the "invalid input" to the
command prompt.

Here's the core issue = this function works by itself, but I need to make
the error trap silent - no command error being echoed to the command prompt.
The vl-error object isn't the issue, it's the command echo. Is there a way
to "wrap" the vl-catch-all-apply to silence the command error echo?

Thanks for your time,
Mark

(and
(if
(vl-catch-all-apply '(lambda () (apply 'command
(list ".-aecobjexplode"
"y" ;..explode to primitive
"c" ;..Views to explode [Current/All]:
"y" ;..Re-use existing names for Layers and Block Definitions?
[Yes/No]
"n" ;..Bind Xrefs?
"n" ;..Explode to anonymous blocks? (if yes, aec objects become
anon blocks)
"y" ;..Maintain Resolved Layer, Color, and Linetype?
"y" ;..Erase AEC objects?
"n" ;..Use short symbol names?
"n" ;..Display status messages?
"y" ;..You should either Bind these Xrefs first or run...
continue?
)
)))
(progn (command)(command) t) ;..t keeps AND going
)
(if
(vl-catch-all-apply '(lambda () (apply 'command
(list ".-aecobjexplode"
"y" ;..explode to primitive
"n" ;..Bind Xrefs?
"n" ;..Explode to anonymous blocks? (if yes, aec objects become
anon blocks)
"y" ;..Maintain Resolved Layer, Color, and Linetype?
"y" ;..Erase AEC objects?
"n" ;..Use short symbol names?
"n" ;..Display status messages?
"y" ;..continue?
)
)))
(progn (command) (command) t) ;..t keeps AND going
)
)

[Anonymous]

Unfortunately, it doesn't silence prompts for incorrect input, only command
options. Thanks though.

[Anonymous]

Hi Ken,

Thanks, that might work if we were always binding xrefs. Unfortunately we
don't most of the time which is creating the headache. If the xrefs aren't
bound, there are some unpredictable prompt orders in 2008. For 2006 I had 8
scenarios - VPORTS / XREFS / BINDING / I forget the 4th. Now in 2008 there
seems to be an additional prompt if there are ADT objects in the drawing. So
now I'm looking at 16.

The test code I posted is pared down quite a bit. That's why I wanted to try
(and... because there are 4 possible correct scenarios for BOTH if & then
responses to (ssget "x" '((0 . "viewport"))) depending on the content of the
drawing.

Any other suggestions including further ideas to the one you already posted
gladly taken.

Thanks,
Mark

[Anonymous]

I've also run into a few 1-off scenarios where 0 or 1 vports in the drawing
cause a different prompt order than more than 1 vport.

:o)