how to change the insertpoint of a block,and keep the insert objects's place

you can, but it's not the best idea. (imho)
a block created elsewhere than 0,0 will not honor trim, extend, and
sometimes osnaps
a quick macro to move objects to 0,0 first, then block them, then move the
block back to where you started will eliminate this bug.

 

Thank you Joe.

Good point about the highlighting. I should do more of that in general. I
did think about handling a missed pick, but neglected that as well.

Regarding origin, I agree with you. One of my goals writing what I posted
was to see how "simple" I could make it and still work. I do think moving
the nested ents is the better way to go though and would be pretty easy to
add. I don't know if you'd call this standard, but you can use the base
command to change the insertion base point in a file that will be used as a
block. I'm not sure what purpose this would serve, but I do remember our
company's old block library having all sorts of random base points (origins)
for some reason. Among other things, I changed all their base points to
0,0,0.

What you describe with RCB1 sounds right. It's like inserting Blk1 and then
redefining Blk2 to only contain Blk1. Blk1's non-geometric properties are
exactly the same in every insertion of Blk2, so when you explode all Blk2's,
what's left is identical throughout. That's the inherent problem. The
genius (and yet so simple) is that it effectively redefines the insertion
point w/o visibly moving the block. The error message you quoted looks like
nested references. Exploding (ssget "x") doesn't cut it. There are still
unexploded references, so the purge fails.

"...But it's actually of more interest to me than this subject." Big ditto!
From what you've posted, I think you've already got most of what is
significant there. The quasi-formulas in the comments reveal the heart of
it. Most of the rest is just input initialization and path picking.

James

 

MP,
There is no such bug for blocks, only for external references.

In addition, AutoCAD 2005 automatically adjusts the insertion point
during wblock commands. (Earlier versions did not adjust).

Regards,
Doug

 

Well, knock me over with a feather.... In over 20 years working with
AutoCAD, I have never, ever defined blocks that way (it never even occurred
to me), and I've never, ever been aware of the problems you describe (except
for most of those years when it wasn't possible to trim or extend to blocks
at all). What's more, I've been sitting here wasting time trying to make it
not work, in both A2K and A2K4, without success except in situations that
also don't work with 0,0-based blocks.

I can't trim or extend to polylines within blocks, ONLY when the block is
not uniformly scaled (even then, I can trim and extend to arcs and circles
and lines in the blocks). [Express Tools' Trim to Nested Entities in A2K4
does make it work for all of those things.] BUT the same things also fail
when I define the block with a 0,0 insertion point, so that doesn't support
your "bug." (It could certainly be considered a bug on its own, but the
insertion base point has nothing to do with it, at least for me.)

On Osnap, I haven't been able to do tangent or perpendicular or quadrant
Osnap to curves (including polylines, arcs and circles), or intersections
involving polyline segments (even straight-line segments), again ONLY in
non-uniformly-scaled block insertions. (It does snap to midpoints and
endpoints and center-points of the curves.) But again, that's equally the
case if I define the blocks with a 0,0 insertion point.

Of course I haven't tried every kind of entity in blocks, or every type of
osnap on every kind of thing. But in no case has defining a block with its
insertion point at 0,0 made any difference.

Do other people have the problems MP describes?

 

I stand corrected..

 

Hi James et al...

I just HAD to leave your first paragraph in my reply. <big self-serving
grin>

I believe your RCB2 is the grand prize winner. Nice routine.

As for your RCB1, it took 3:47 to reconfigure my 2500 block array. My
version of RCB took what I previously thought to be an interminable 0:19.
Wow, what a speed demon it is now!

Does this sort of thing happen with VL every time?
-doug

 

Doug,

Yes this bug does (still) exist. This has to do with entmake
and not using 0,0 as the block definitions insertion point.

Use this to create the block, then draw a line through it
and try to trim. Replace the insertion point with 0,0 and it
works as expected.

(entmake
'(
(0 . "BLOCK")
(100 . "AcDbEntity")
(8 . "0")
(100 . "AcDbBlockBegin")
(70 . 0)
(10 1.0 1.0 0.0)
(2 . "test")
)
)

(entmake
'(
(0 . "CIRCLE")
(100 . "AcDbEntity")
(8 . "0")
(100 . "AcDbCircle")
(10 1.0 1.0 0.0)
(40 . 0.5)
)
)

(entmake '((0 . "endblk")))

 

Thanks for the illustration Jason.

Guess it depends on how you make the block. I have never
run across that error because, when entmaking blocks, I've never
seen an advantage in using an IP other than 0,0. The error is
interesting however.

Now compare that to a block made with the block command.
The block command must do the translation automatically because
I have never had a problem using the block command and picking
any insertion point and having trim work correctly.

I just tested it with a rectangle 3,3 4,4 and block "box" with IP 3,3.
A table search on the block table shows the ip as 0,0,0 indicating
the translation occurs.

So when using entmake, IP must be 0,0,0 for trim to work. Thanks.

Regards,
Doug

 

I stumbled onto that by accident a couple of years
ago. Was making blocks on the fly, using a picked
point for the block definition, then noticed problems
with trimming. Drove me crazy for a while!

 

Thank you Doug. I'm confused by your reported times though. Are you saying
RCB was THAT much quicker than RCB1? (0:19 vs 3:47) I would expect RCB1 to
be a little quicker if anything. I thought they were pretty nearly
identical in approach. Based on what I've seen others post I thought that
vl- methods have a little edge over command, all else being equal. I wonder
where the hang up is.

James

 

I tested them twice each. Yours did indeed take almost 4 minutes.

At first I thought your RCB2 had simply hung up my computer, because it
stopped with the command line
"Select new insertion point for block:" displayed. I then brought up the
textscreen (F2), and then I could see that it was working, slowly repainting
the screen with new blocks over the textscreen... visibly taking about 1
second to replace about 10 blocks.
-doug

 

Hi Kent,

A block's "origin" as defined in the block table/collection is always 0,0,0
regardless of whether you pick a point or accept the default 0,0,0 when creating the
block.

Try this on blocks created either way.

(defun c:test ( / blocks obj )
(setq blocks
(vla-get-blocks
(vla-get-activedocument
(vlax-get-acad-object))))
(setq obj (vlax-ename->vla-object
(car (entsel "\nSelect block: "))))
(vlax-get
(vla-item blocks
(vlax-get obj 'Name)) 'Origin)
)

My point regarding James' RCB2 function was that after it modifies a block, the
origin is not 0,0,0.

Joe Burke

 

That's really weird. I am curious what would make THAT much difference. If
you don't mind helping educate me a little bit...

Can you tell if the hangup is in the explode loop or not?
....
(ssget "x" (list '(0 . "INSERT") (cons 2 name)))
(vlax-for obj (vla-get-activeselectionset doc)
(vl-cmdf "._explode" (vlax-vla-object->ename obj) "")
)
....

If so, what kind of results do you get with one of these variations or your
version of the same loop?
....
;;Variation 1
(ssget "x" (list '(0 . "INSERT") (cons 2 name)))
(vlax-for obj (vla-get-activeselectionset doc)
(vl-cmdf "._explode" (vlax-vla-object->ename obj) "")
(vlax-release-object obj)
)
....
....
;; Variation 2
(setq ss (ssget "x" (list '(0 . "INSERT") (cons 2 name)))
cnt (if ss (sslength ss) 0)
)
(repeat cnt
(setq cnt (1- cnt))
(vl-cmdf "._explode" (ssname ss cnt) "");; Or "command"
)
....
James

 

Hi James ~

Not certain if it's the explode or not, though in my own routine, the
explode is essentially all there is.

Here's the entire routine you wrote, with variations which I alternately
commented in & out.
I note below what the timing was for each variation. (counting
one-america-two-america...<g>)

;;; ReConfigureBlock
;;; Doug's approach using vl- methods (mostly)
(defun c:rcb1 (/ doc obj name opt blk npt orgn tname blks tblk lst)
(setvar "cmdecho" 0)
(setq doc (vla-get-activedocument (vlax-get-acad-object)))
(vla-startundomark doc)
(setq obj (car (entsel "\nTouch block to reconfigure:"))
obj (vlax-ename->vla-object obj)
name (vla-get-name obj)
opt (getpoint "\nPoint to a blank place to work in:")
blk (vla-get-block (vla-get-activelayout doc))
npt (vlax-3d-point (trans opt 1 0))
obj (vla-insertblock blk npt name 1 1 1 0)
npt (getpoint "\nSelect new insertion point for block:")
opt (vlax-3d-point (mapcar '- npt opt))
npt (vlax-3d-point (trans npt 1 0))
orgn (vlax-3d-point '(0 0 0))
tname (strcat "RCB-Old-" name)
blks (vla-get-blocks doc)
blk (vla-add blks orgn tname)
tblk (vla-item blks name)
lst (vlax-invoke obj 'explode)
)
(prompt "\n")
(vla-delete obj)
(mapcar '(lambda (obj) (vla-move obj npt orgn)) lst)
(vlax-invoke doc 'copyobjects lst blk)
(mapcar 'vla-delete lst)
(vlax-for obj tblk (vla-delete obj))
(vla-insertblock tblk opt tname 1 1 1 0)

;********** ORIGINAL VERSION *****************
(ssget "x" (list '(0 . "INSERT") (cons 2 name)))
(vlax-for obj (vla-get-activeselectionset doc)
(vl-cmdf "._explode" (vlax-vla-object->ename obj) "")
)

Testing it on a 576-block drawing, it took 55 seconds to complete.

;********** VARIATION 1 **********************
;(ssget "x" (list '(0 . "INSERT") (cons 2 name)))
;(vlax-for obj (vla-get-activeselectionset doc)
; (vl-cmdf "._explode" (vlax-vla-object->ename obj) "")
; (vlax-release-object obj)
; )

Again, 576 blocks took 44 seconds, but the blocks were skewy as heck.

;********** VARIATION 2 **********************
;(setq ss (ssget "x" (list '(0 . "INSERT") (cons 2 name)))
; cnt (if ss (sslength ss) 0)

;(repeat cnt
; (setq cnt (1- cnt))
; (vl-cmdf "._explode" (ssname ss cnt) "");; Or "command"


This time it took 44 seconds again, but all blocks behaved properly.

;********** CLOSING CODE***************

(vl-cmdf "._purge" "B" name "N")
(vla-put-name blk name)
(vla-endundomark doc)
(princ)
)
;*********** END OF ROUTINE *****************

My own RCB routine took 6.5 seconds for 576 blocks, your RCB2 took about
1.5.
-doug

 

Wow, do I feel silly now! LOL Taking the extra "" out of the explode calls
makes just a wee bit of difference... Sorry 'bout the little detour Doug.

(vl-cmdf "._explode" (vlax-vla-object->ename obj)); was ... obj) "")

I cobbled together a file with 768 inserts and tested using Joe's posted
timer function (and the appropriate ""'s removed).

5.94s ;rcb
3.85s ;rcb1-original
6.92s ;rcb1-var1
4.62s ;rcb1-var2-vl-cmdf
4.89s ;rcb1-var2-command
2.20s ;rcb2

There was one thing of genuine interest to me here. For anyone looking for
empirical data on vlax-release-object, notice that the only difference from
rcb1-original to rcb1-var1 was the ADDITION of vlax-release-object to the
explode loop. I've seen people say it never hurts... Weell, I'm not so
sure about that.

Thank you Doug.

James

 

Hi James,

I thought something like that extra "" was the cause of the slow times Doug reported.
Just didn't have time to investigate.

Interesting regarding the vlax-release-object call. I'm never sure when I should do
that, other than when working with ODBX files. With those the result of not doing it
is clear. An attempt to open the file normally results in "read only" if you don't
release in code.

Joe Burke