vla functions

I see on Michael Puckett's exhaustive list some functions that are not
implemented on my installation (LDT4), notably vla-get-centroid. How can
I get these functions?

rs

 

How do you know they aren't implemented?

Jeff

 

Jeff, here are the commands I tried, strung together in a defun.

(defun c:chk()
(setq pln(car(entsel))) ;select a closed pline
(setq v-pline (vlax-ename->vla-object pln))
(print (vlax-get-property v-pline 'Color)) ; 256
(print (vlax-property-available-p v-pline 'area)) ;T
(print (vlax-property-available-p v-pline 'centroid)) ;nil
(vla-get-centroid v-pline)
; error: ActiveX Server returned the error: unknown name: Centroid
(princ))

rs

 

Use

(vlax-dump-object <vla-object> t)

to determine what methods are supported.

I think you will find that a polyline (heavy or light)
does not have a centroid.

 

How odd! Ok, I'll try a region . . .

rs

 

Ok, changed it to a region and (vlax-dump-object) showed a centroid. So
next I tried (vla-get-centroid v-obj) and got the comment #<variant 8197
....>. Same thing with (vlax-get-property v-obj 'centroid), although
property-available-p says yes.

Where do I look to find what #<variant 8197 ...> is (and the other 8196
variants)?

rs

 

Try it this way and you don't have to
mess with the variants.

(vlax-get <vla-object> 'centroid)

 

If you really want to deal with the variant.....

(vlax-safearray->list
(vlax-variant-value
(vla-get-centroid <vla-object>)) )

 

plines can cross themselves many times, including having parts where lines
align with each other - which is impossible for real object - thus
calculating a mass prop not really necessary, although in theory it could be
done (mass prop of a series of islands with holes and other islands inside)
--


Jamie Duncan

Consulting - If you're not part of the solution, there's good money in
prolonging the problem.

 

Conceded. Though, mathematically, there is no reason why a complex
topology can't still have a centroid. When you say "does not have a
centroid" you are referring to Acad's reluctance to calculate one.



rs

 

Only if I know what a variant is. However, your command produced a point
string. Wait, I'll go look up "variant" . . . <SHUFFLE Shuffle suff...>

<shuffle Shuffle SHUFFLE> Ok, I'm back. I know how to make 'em and read
'em but Help doesn't want to tell me what they are used for. Apropos is
no help either.

Thanks for your patience,

rs

 

I don't have a textbook definition of a variant.

I believe it is just a 'universal container' that
can contain any type of data... strings, reals,
integers, etc....

Perhaps one of the more knowledgeable folks
will jump in an provide a true definition.

 

Watch for word wrapped url:

http://msdn.microsoft.com/library/d...y/en-us/office97/html/output/F1/D6/S5B2D2.asp

or http://tinyurl.com/2fyup

 

Thank you. I'll save it for after reboot.

rs

 

You're welcome; cheers.

 

Ok, I get it. Somehow this "variant" concept has wiggled its way from
VBasic to VLisp. For the best, I hope.

rs

 

One reason why LISP programmers have such a hard time
grasping the concept behind a VARIANT is because they
use them all the time, without realizing it.

AutoLISP variables are from a conceptual and functional
perspective, variants.

VARIANTS are containers capable of holding any type of
fixed-size data (and pointers to non-fixed size data),
along with 'metadata' that tells you what type of data
is contained in the variant.

Well, it just so happens that LISP variables (nodes) are
exactly the same thing. They are containers that store
both data and metadata (the AutoLISP (type) function is
what returns the metadata, which tells you what data
type the node contains).

Hence, access to variants and LISP variables (internally),
is facilitated by using the metadata associated with each
variant or LISP variable.

Consider something simple like an equality test (=).

In LISP, the values of two variables are equal (eq), only if:

1. Their metadata indicates they are of the same type.

2. The type-specific equality comparison test succeeds

So in fact, a simple type comparison between two LISP variables
actually isn't simple at all, because it requires that both the
data types (metdata) be compared, and if that succeeds, then
their data values must also be compared.

The reason that so many LISP programmers have problems with
variants, is because of the lousy support for them (e.g., lack
of transparency, like that which Visual Basic programmers enjoy).

What is meant by 'transparency' is that in VB, almost anywhere
that a native type (like a double, or an integer) can be used,
a variant containing that type can be used in lieu of same, and
VB automatically gets the value from the variant and uses it.

Unfortunately, that's not the case with LISP.

Hence, when a LISP function expects a double, and you give it
a variant that contains a double, the LISP function barfs on it,
because of the lack of transparent support for variants.

If there were that support, you could use a variant anywhere
that a native type is expected, if the variant's contents is
type-compatible with the expected type.

And, that's why you must use (vlax-variant-value) to get the
data out of the variant.

And that's why as an ActiveX scripting language, LISP sucks.

 

Thanks for 'splainin' that in terms even i can understand, Tony.
It may all sink in yet.....

Jeff

 

Beautifully stated. I will save it for future reference. Thank you.

rs