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

Discussion in 'AutoCAD' started by dream0001, Oct 4, 2004.

  1. dream0001

    MP Guest

    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.
    MP, Oct 12, 2004
    1. Advertisements

  2. dream0001

    James Allen Guest

    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

    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 Allen, Oct 12, 2004
    1. Advertisements

  3. dream0001

    Doug Broad Guest

    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).

    Doug Broad, Oct 12, 2004
  4. 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?
    Kent Cooper, AIA, Oct 12, 2004
  5. dream0001

    MP Guest

    I stand corrected..
    MP, Oct 12, 2004
  6. dream0001

    Douglas Barr Guest

    Hi James et al...

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

    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?
    Douglas Barr, Oct 12, 2004
  7. 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.

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

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

    (entmake '((0 . "endblk")))
    Jason Piercey, Oct 12, 2004
  8. dream0001

    Doug Broad Guest

    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.

    Doug Broad, Oct 12, 2004
  9. 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!
    Jason Piercey, Oct 12, 2004
  10. dream0001

    James Allen Guest

    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 Allen, Oct 12, 2004
  11. dream0001

    Douglas Barr Guest

    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.
    Douglas Barr, Oct 12, 2004
  12. dream0001

    Joe Burke Guest

    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

    Try this on blocks created either way.

    (defun c:test ( / blocks obj )
    (setq blocks
    (setq obj (vlax-ename->vla-object
    (car (entsel "\nSelect block: "))))
    (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
    Joe Burke, Oct 12, 2004
  13. dream0001

    James Allen Guest

    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 Allen, Oct 13, 2004
  14. dream0001

    Douglas Barr Guest

    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

    ;;; 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)
    ;*********** END OF ROUTINE *****************

    My own RCB routine took 6.5 seconds for 576 blocks, your RCB2 took about
    Douglas Barr, Oct 14, 2004
  15. dream0001

    James Allen Guest

    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 Allen, Oct 16, 2004
  16. dream0001

    Joe Burke Guest

    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
    Joe Burke, Oct 19, 2004
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.