Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

HideObject within Block

Is this intentional - that you can't HideObject individual entities within a Block? Before wasting time converting Blocks into Xrefs, does this apply to Xrefs also?

Having only just started using HideObject seriously, I am disappointed if it won't work within a Block, as I use and constantly modify Blocks extensively as vital part of my workflow.

Why must this be? Is there any way round it?

«1

Comments

  • A block is an entity all on it's own, so trying to select just items from a block wouldn't work, the only way I could see that being possible would be place the items within the block on their own layers and turn off the individual layers (but that might give it's own set of problems). I don't see Xrefs behaving any differently!

  • I open a Block in RefEdit, then everything in it is editable, deletable, addable - but not HideObject-able.
    Don't see why it shouldn't be.
    Entities within the Block are on different Layers - and yes I can turn off whole layers within the Block, which is what I relied on and did regularly before I started using HideObject.

  • In refedit you are opening the block definition, but once you insert a block it is a separate object and treated as one object.

  • edited October 2018

    Yes but once inserted, or multiple insertions as I do, by double-clicking on any one of those instances and then OK in the Refedit dialog that pops up, the Block definition becomes available for every kind of editing just like any non-Block'd entities - incl I'd have hoped HideObject - until the Refedit session is closed.

    I'm not trying to HideObject any entities within the Block (or the whole Block as one object) without first opening it in RefEdit.

  • Are you talking about that HIDE/ISOLATE thing or a different option ?

    Because to me this HIDE looks like being only a temporary visibility
    thing. If I close and reopen my file, all these visibilities will be lost.
    So I can understand that Blocks will also not behave as if they would
    save these visibilities.

    (BTW that dead end street Block Editing behavior is endless tedious.
    Why can't I go from an active Block Editing session down one level to
    edit the child Blocks and their childdren in nested Blocks.
    And why can't I just go out of Block Edit but have save or discard
    options instead of just saving changes like outside of Blocks.
    I mean there is an UNDO anyway)

  • If you insert 2 blocks, then open one in refedit and change the color of just one object in the block and then close refedit, you will see that the color changes in both blocks. Refedit doesn't open the block you choose, it opens the block definition for that block type and any changes are made to all blocks of that same type. But the objects in each of the individual blocks are not the same object (copies) they each are unique objects with their own entity ID number, they just keep the same properties as the objects in the block definition. HideObject works on individual entities

  • I'm fine with your first paragraph.

    But the objects in each of the individual blocks are not the same object (copies) they each are unique objects with their own entity ID number, they just keep the same properties as the objects in the block definition. HideObject works on individual entities

    Did I get that right that in instanced copies from a Block definition,
    the objects are stored separately in file ?
    So an ACAD Block just a link to properties ?

    I thought the meaning of a Block/Cell/Symbol /... is to have it saved
    only one time in the Block definition Library, all Block instances are
    absolutely identical to their definition and instances are just stored
    by their positions, orientation and scale values only,
    to also save file size.
    So not the Objects inside the Block have IDs but the Block instance itself.

  • edited October 2018

    That's a bit clarifying Steven, thanks.

    Your first sentence is exactly what I understand, and rely on bigtime.

    Your last sentence "HideObject works on individual entities" must be the crux of the matter -
    so what I'd like is that a HIDEOBJECT operation on an individual entity gets transmitted, just like a colour change, to the Block definition, thence to all the other instances of the Block.

    Michael said, "Are you talking about that HIDE/ISOLATE thing ...?" Yes.

    "HIDE looks like being only a temporary visibility thing. If I close and reopen my file, all these visibilities will be lost."
    There are Settings which determine what happens to a HIDEOBJECT operation on save/close/reopen etc - they can be persited.

    Yes, going in and out of RefEdit is a bit tedious, as I do it constantly -
    and if I forget to be 100% systematic, can get elements which belong elsewhere entangled in the wrong Block - or even inadvertently nest one in another.
    It's v difficult to diagnose and quickly subtract the offending entities or Block from where it shouldn't be, without creating yet more tangle.
    The quickest way is just to sadly Undo work back to the point where all looks healthy, and start again.

    Here's a picc of how I'm using blocks:

    The top row is four instances of the same block, rotated to suit the four elevational orientations, so I can project Xlines down the page, to comstruct elevations, sections etc.
    the second row and the fourth, fifth and last likewise.
    Each block is a large drawing, a full floorplan, which gets constantly modified and added to by opening any one of its instances in RefEdit then closing when done, and all instances update identically.

    Believe me, I need HideObject while within a Refedit session - otherwise have to revert to cumbersome previous practice - a discipline of umpteen Layers which get switched on/off when needing to clear obstructions
    e.g. so as to select a whole lot in one box-select instead of individually,
    or hatch something without lots of subdivsion by other entities.

    Blocks.JPG
    438 x 756 - 48K
  • The DWG DATABASE contains a block name and an insertion point. But when it comes to producing the blocks on screen or paper for that matter, then the program draws the elements by using the block definition as a reference source so each block is drawn in exactly the same way, taking that a step further, on a sheet of paper all the blocks look exactly the same but they don't all use the same ink.
    I agree HideObject would be a nice feature to have working on individual block objects, Autocad dynamic blocks do have a visibility option, but this is generally quite limited to one object (or group of objects) and has to be decided at the time of creating / editing the block and doesn't work with random objects of choice.

  • There are Settings which determine what happens to a HIDEOBJECT operation on save/close/reopen etc - they can be persited.

    Oh, didn't know that !
    Found it now.

    on a sheet of paper all the blocks look exactly the same but they don't all use the same ink.

    Ah, like that ACAD-only feature,
    Block Definition on Layer 0,
    when inserting Instances they appear in Layer Style of which placed on ...

  • @Steven_g said:
    But the objects in each of the individual blocks are not the same object (copies) they each are unique objects with their own entity ID number, they just keep the same properties as the objects in the block definition.

    I have to jump in to say that this is incorrect. But I do understand how you might get confused by the behavior of the _RefEdit command, and how dynamic blocks and BricsCAD components create linked 'anonymous' variant block definitions.

  • I wish I new more about Lisp, I was convinced that all objects in a drawing had a unique Handle even those within blocks, to me it seems strange that they might not. However a bit of searching turned up this Lisp from "hmsilva" https://forums.autodesk.com/t5/visual-lisp-autolisp-and-general/ability-to-hide-objects-that-are-inside-a-block-or-xref/td-p/5114058
    It does hide the item in every block, but it does let you select the item without going into refedit.

  • edited October 2018

    @Steven_g said:
    ..... I was convinced that all objects in a drawing had a unique Handle even those within blocks.....

    Same here. To test it, I made a block consisting of a rectangle and a line, then made a copy of the block, then used Refedit to edit each of the two insertions of the block. I got different Handles for the rectangle in each insertion.

    I read the Handles in the Properties bar, and also used a DXF code dump and read the value of code 5.

    If I explode one insertion, the rectangle in that insertion appears to get a new Handle, and -- strangely -- the rectangle inside the other insertion also appears to get a new Handle. If I rotate one of the block insertions, that appears to give the rectangles in both insertions new handles also.

  • So, looks like not impossible. Cd no doubt be more elegantly done by Brics coders. Thanks

  • @Anthony Apostolaros:
    As I already mentioned the _RefEdit command can lead to confusion. When you _RefEdit an insert you are working on temporary copies of the entities in the block definition. These copies obviously have a different handle, as handles are unique. The original entities in the definition are temporarily made invisible. This has the effect of hiding all the inserts of the block and giving the user the illusion of having 'opened' an insert.
    When you explode an insert you are in fact creating new entities with new handles. The block definition and the entities inside it remain.

  • I've started a Feature Request SR 84577 -

    "I would strongly request that that HIDEOBJECT and its two companions, could be made to work on individual elements within a Block (or Xref) when opened in REFEDIT".

  • @Roy Klein Gebbinck said:
    ...When you _RefEdit an insert you are working on temporary copies of the entities in the block definition. ...

    Interesting. In the early days, before Refedit, if you wanted to edit a block you had to insert the block at a marked point, then explode it, then edit the exploded entities, and then redefine the block as consisting of those new entities, using that marked point as the insertion point. It sounds like the Refedit command is doing the same thing, but automating it as much as possible.

  • @Anthony Apostolaros:
    Yes, that is a good way to describe the _RefEdit command. Apart from automating things the command has another advantage over the old manual approach: you don't have to worry about entities on frozen layers.

  • edited October 2018

    How to change block insertion point without altering the location of already inserted blocks???

    Hello everybody,

    Is there a way to alter the insertion point for a particular block without changing the location of blocks??? I'd like to change the insertion point for future insertions, without changing the LOCATION of the blocks I've already inserted. I realized that, I can just create a new block and name with the revised insertion point, but the block list becomes, harder and its difficult to find the block. Please help me and guide about this, thanks!!!

  • edited November 2018

    Angel892, in regards to editing the base point, I would expect that someone has written a LISP (or other language) utility to do just what you want. I probably 1st obtains a list of all instances of that block, with its location, and stores that. Then, perhaps it permits you to edit the block insertion point in some way, and then uses its stored list of instances to move the other instances.

    So, you need to search the Internet for something like; block move base *.lsp or block move utility

    -Joe

  • Sorry if I am missing the point, since I only glossed over the thread. But, if the goal is to do something equivalent to the hide/show feature in AutoDesk's Dynamic Blocks, then one idea may be to make the object you wish to hide/show an element that you scale down to a very small size to make it nearly invisible. You will still get a dot the size of the line-weights used, but even that may be hidden by the line weights of a closely adjacent line.

    So, if you want an optional feature, like a heater on a freezer door,the dimensions of the drawing elements associated with it may be assigned to a table, with "No Heater" and "With Heater" being two model # type of choices. Then you put the dimension values to be perhaps 0.01" if the "No Heater" option is chosen.

    I don't know if it is possible to have more than one table driving a parametric block. But, if not it might be necessary to have only one table, that lists the models like this, "Door #123, with heater", "Door #123, Without heater", etc.

    -Joe

    -Joe

  • As OP, my problem solved!
    But not the problem as Joe Dunfee said it:
    "if the goal is to do something equivalent to the hide/show feature in AutoDesk's Dynamic Blocks ..."

    No, it wasn't that at the time I did the OP! I said:
    "Is this intentional - that you can't HideObject individual entities within a Block?" and
    "I open a Block in RefEdit, then everything in it is editable, deletable, addable - but not HideObject-able." Then
    "I've started a Feature Request SR 84577 -
    "I would strongly request that that HIDEOBJECT and its two companions, could be made to work on individual elements within a Block (or Xref) when opened in REFEDIT".

    The answer there included:
    "These commands were disabled during REFEDIT because the relevant data was lost by REFEDIT. REFEDIT has a difficult transfer mechanism for retrieving data from block and writing it back.
    This is to inform you that our team is aware about the current behavior and it's working to provide a fix for this issue."

    Shortly after, with v19, BEDIT came in as an alternative to REFEDIT, but unfortunately, although BEDIT does accept HIDEOBJECT, it doesn't do it while still visible in context, as REFEDIT does. So REFEDIT doesn't provide the 'fix' I need.

    However! Just discovered that the wonderful facility in Structure panel, to HIDE or SHOW objects individually, does work within REFEDIT!
    So, problem solved, for me.

  • ngel892, in regards to editing the base point, I would expect that someone has written a LISP (or other language) utility to do just what you want. I probably 1st obtains a list of all instances of that block, with its location, and stores that. Then, perhaps mobdro apk app it permits you to edit the block insertion point in some way, and then uses its stored list of instances to move the other instances.

  • The latest version of Brics has now removed HIDEOBJECT and its two companions from new BEDIT.
    Wonder why - not that I use BEDIT, prefering the old REFEDIT.

  • Don't understand BEDIT either.
    I always need to edit in context.

    What I first thought with new Block Edit was that I could now
    double click on a nested Block to open,
    double click on a inner nested Block in the Block to open,
    and so on.
    Like I do in Vectorworks.

    And why is there a Reject Changes at all ?
    Leave Block's "Edit Mode" and everything is saved.
    Isn't that what an UnDo is for ?

  • @Tom Foster said:
    However! Just discovered that the wonderful facility in Structure panel, to HIDE or SHOW objects individually, does work within REFEDIT!
    So, problem solved, for me.

    Just to clarify (to me) the OP raised the point that HIDEOBJECTS wasn't available when editing a block using REFEDIT?

    : HIDEOBJECTS
    
    ** Command HIDEOBJECTS is not allowed during reference editing. Use REFCLOSE to end **
    

    Subsequently you found that this was available in V19 in early releases using BEDIT or via the Structure panel.

    HIDEOBJECTS visibility is governed by OBJECTISOLATIONMODE. By default object visibility is only retained for the current drawing session, on re-opening the drawing the hidden objects will redisplay. OBJECTISOLATIONMODE is saved to your profile, not with the drawing. If you send the drawing to someone else, or open in a different version, then object visibility will be dependent on the settings of the recipient.

    Things get a little funky if you change visibility from within a block definition. When opening somewhere else the state of OBJECTISOLATIONMODE is ignored for these blocks, they retain the state they were previously set to. Not a problem for BricsCAD V19 users (if they are aware), they can change the visibility like you have discovered. This isn't the case for users on earlier versions of BricsCAD, nor in AutoCAD. They would be left without the ability to redisplay (unless they resorted to programming) any hidden entities. In the case of AutoCAD, they don't allow you to use HIDEOBJECTS in REFEDIT or BEDIT. I'm assuming to avoid this situation from occurring.

    Regards,
    Jason Bourhill
    CAD Concepts


    Come to the Australasia BricsCAD Conference


  • edited January 26

    There is an alternative approach for users with BricsCAD Platinum and above. Instead of trying to change the visibility of entities within a block, you can use BMMECH along with BMFORM to create a component with sub-components. Then BMINSERT into the drawing that you want to use it with. Having done this you can change the visibility of the sub-components from the mechanical browser.

    Attach a drawing and screengrab to illustrate what I mean.

    Regards,
    Jason Bourhill
    CAD Concepts


    Come to the Australasia BricsCAD Conference


    dwg
    dwg
    Block-Visibility.dwg
    42K
    BlockVisibility.png
    615 x 726 - 37K
  • Thanks Jason - personally I'm v happy with using structure panel for most HIDEOBJECT etc operations, both inside and within REFEDIT, and am not bothered about Hide or Show persisting to the next session.

  • The new feature to selectively re-activate hidden Objects was what I was
    always missing in standard Hide, Isolate and Show All System.
    Show selective by objects is a great feature.

    Of course the ability to control Visibilities from Structure Panel was
    very obvious and necessary too.

  • @biosese said:
    ngel892, in regards to editing the base point, I would expect that someone has written a LISP (or other language) utility to do just what you want. I probably 1st obtains a list of all instances of that block, with its location, and stores that. Then, perhaps mobdro PC it permits you to edit the block insertion point in some way, and then uses its stored list of instances to move the other instances.

    Thanks for sharing your experience with us.

Sign In or Register to comment.
Origami
Origami is the Japanese word for paper folding. ORI means to fold and KAMI means paper and involves the creation of paper forms usually entirely by folding.

Powered by VanillaForums, Designed by Steam