Insert existing block on another layout

I am looking to insert an existing block on a layout that is not active. What's the best way to do this?

 

1) Entmake

2) Switch to correct layout then use (command "-insert".....)

3) Some other way I'm not aware of...

 

I think entmake would be best especially when it has to be done on many layouts. I've tried using Lee's code from this thread but it ends up redefining the block and I don't want that.

 

And of course the drawback to just switching to the layout and inserting the block is if it needs to be done on many layouts then it's not only slow but programmatically its junior league.

One way:

 

(entmake
 (list
   (cons 0 "INSERT")
   (cons 2 "YourBlock")
   (list 10 0 0 0)
   (cons 410 "YourLayout")
 )
)

 

Of course - the above is only for non-attributed blocks. For attributed block you will have to entmake the attributes also.

Well my block has attributes (of course) and I tried the code below but the attributes don't get placed at the coordinates I specify. Instead the attributes are all placed at 0,0.

 

(entmake
 (list
   (cons 0 "INSERT")
   (cons 2 blkname)
   (cons 10 '(0 0 0))
   (cons 410 "SH 10")
 )
)
(entmake
 (list
   (cons 0 "ATTRIB")
   (cons 10 '(10 10 0))
   (cons 1 "XXX")
   (cons 2 "SH_REV")
   (cons 7 "ROMANS")
   (cons 40 0.125)
   (cons 70 0)
   (cons 72 0)
   (cons 74 2)
 )
)
(entmake
 (list
   (cons 0 "SEQEND")
 )
)

As DXF 74 is non-zero, you'll need a DXF 11 Alignment Point, else 0,0,0 will be used.

Oops....

 

When I'm working with DXF codes I've been using the AutoCAD 2009 DXF Reference and I guess I should have read further down the page on ATTRIBs as this is written at the bottom of that section. Thanks!

 

If group 72 and/or 74 values are nonzero then the text insertion point values are ignored, and new values are calculated by AutoCAD based on the text alignment point and the length of the text string itself (after applying the text style). If the 72 and 74 values are zero or missing, then the text alignment point is ignored and recalculated based on the text insertion point and the length of the text string itself (after applying the text style).

As DXF 74 is non-zero, you'll need a DXF 11 Alignment Point, else 0,0,0 will be used.

 

Ok since the DXF 10 code is ignored when DXF 74 is non-zero can I just omit it from my code?

 

EDIT:

 

Also, is the value for rotation DXF code 50 not supposed to be in degrees? I tried using (cons 50 270) to make the attribute read down and it's barely rotated at all and in the wrong direction.

 

Edited January 13, 2011 by lfe011969

Duh! That's the angle in radians.

I believe DXF 10 is a requirement for Attribs.

 

And yes, angles are always in Radians (the proper way to define an angle - degrees are other scales are arbitrary to make the numbers 'nice').

What? 3.161459 for "back that way" isn't "nice" enough for you lol

 

dJE

What? 3.161459 for "back that way" isn't "nice" enough for you lol

 

3.14159

 

The point I make is that Radians are properly geometrically defined, degrees/grads are an arbitrary scale.

You also make the point that no-one can ever tell when I'm trying to be funny, nevermind ^_^

 

dJE

3.14159

 

The point I make is that Radians are properly geometrically defined, degrees/grads are an arbitrary scale.

The point I make is that Radians are properly geometrically defined, degrees/grads are an arbitrary scale.

It may be "geometrically" defined, but it certainly isn't the best alternative when working on PC's with angles. That PI is never accurate on any PC, and then using fractions of it makes it even worse. To give you an example:

 

Say you've got a 45 degree angle, that would be PI/4 = 0.7853981633974482 right? If it was left as 45 degrees it can be written exactly in Binary IEEE 754:

01000010001101000000000000000000

But doing the same angle in radians:

00111111010010010000111111011011

Which is actually = 0.7853981852531433 ... converted back to degrees = 45.00000125223908..... which is not equal to 45 degrees.

 

It may be the "scientific" method because it's using the most "geometric" system, but it's IMO the most stupid decision ever made for any form of PC whatsoever.

but it's IMO the most stupid decision ever made for any form of PC whatsoever.

 

Disagree.

 

Far more errors would arise if angles were stored in other arbitrary systems. Very rarely does one merely store an angle but rather perform calculations on such angle, now consider, for example, calculating the sine of the angle: by storing it in degrees, it now has to be converted to radians (inducing more error) before the Taylor expansion of the sine function can be used to perform the calculation. A similar argument would apply to cosine, tangent and practically any other trigonometric function. Furthermore, the storage of any values between calculations would involve the conversion back to degrees, introducing even more error, then back to radians before another calculation is made - these conversions would far outweigh the accuracy lost by approximating an irrational using the mantissa of a double-precision floating point.