VISUAL LISP ERROR?

OPAdrafting

I've been using VL-STRING-RIGHT-TRIM to clip survey line string numbers from the back end of "code" values in dynamic blocks representing survey points, so WUG6 becomes WUG etc. When I use the following in Brics:

(SETQ CODE2 (VL-STRING-RIGHT-TRIM "0123456789" CODE))

I'm getting an error:

; error : bad argument type ; expected at [vl-string-right-trim]

is it a visual LISP library difference between ACAD and Brics? This line is used in all my LISPs that process survey data, so I literally can't do anything via Brics any help greatly appreciated.

martin@enco.us

My guess is that there is a problem with the contents of CODE. When I type

(setq code "WUG6")
(setq code2 (vl-string-right-trim "0123456789" code))

at the command line it returns "WUG".
Do you have code that verifies that the value of CODE is a string just before the call to vl-string-right-trim? Perhaps something like

(if (= (type CODE) "STRING")
(setq code2 (vl-string-right-trim "0123456789" code))
(progn
(alert "Bad string value")
(print CODE)
)
)

OPAdrafting

I've got 2 versions of the LISP. One for working with dxf transfer taken out of a trimble controller, and one for dealing with fully reduced 12d data.

I can get the non-dxf version to work by manually stripping the digits off the end of the code attribute for the inserted blocks. I still have no idea why I can't use the TRIM function inside the LISP, I'll just work round it by removing the digits in a separate sub-routine, or on import. It could be some nested reference in one of the other LISPs in the suite (it's a little convoluted in parts).

I've posted another thread about a separate issue I'm having with a sysvar setting LISP.

Thx

Torsten Moses

Hi OPAdrafting,

as Martin mentioned - simply check what is inside CODE ... by that code as Martin mentioned,
or simply put a
(print CODE) before the line with (vl-string-right-trim) ...

you can just enter
(setq code "WUG6")
(vl-string-right-trim "0123456789" code)
at commandline ...

many greetings !

OPAdrafting

It was a pretty random issue to do with the way the trimble OS exports dxf's out of the survey controller.

The controller exports the diag_cross block as a CAD block, and then exports the attribute set separately, sort of, into their own layer with suffix _attrib. There are other single point-and-click annotation LISPs I have that are unaffected by this issue, as you select the point block it shows you the attributes as though they are part of the block, but they somehow aren't...???

Anyway, every time I tried to use my automated routines with the alert from Martin it just returned "empty" - nil. So the LISP couldn't even see the attributes.

I resolved it by selecting then moving all the point blocks into a single layer "SURVEY-POINTS" and everything went back to working correctly.

This is an issue that only happens sometimes and I think it is a setting in the trimble controller OS that's at fault.

Thx for your help anyway