More nested block editing oddities

Yes. Yet. Another. Thread. On. This. Matter.

Annoyance 327:

  1. Isolate block instance
  2. Edit block instance
  3. Select object within block instance
  4. Hide that object
  5. Show objects

Result: All objects are now visible, even objects outside of the instance. I now have to stop editing the block, and start all above steps over again, in order to edit the next nested part.
Expected: Only objects in the block currently being edited should be shown.

(I’ve had the above happen with isolate/unisolate as well, but can’t find exact repro steps right now.*)

Annoyance 698:

  1. Isolate block instance
  2. Edit block instance
  3. Select object within block instance
  4. Isolate that object
  5. Exit block editing

image

Result: The above popup appears that regardless of what you chose explodes the hidden objects out of the block! Note, these exploded items persists even after you undo the operation!
Expected: I honestly don’t know what to expect here. Block editing is just such a mess. :frowning:

(Actually already mentioned here, but now I managed figure out how to reproduce it.)

EDIT: (*) Today, the steps work exactly the same for isolate too, but they didn’t when I tried yesterday. It’s a mess.

3 Likes

Annoyance 459:

  1. Edit block instance
  2. Select nested block
  3. Attempt to edit nested block

Result: I must now expand the property tabs to be ridiculously large in order to read the full name of the nested block so that I know that I have chosen the correct one in the list, and then often click to miminize each indivisual root nested block to search through the entire list, because it’s not in alphabetical order.
Expected: If I can’t just continue double clicking to edit nested blocks, I at least expected to see the full name of the selected nested block either in the tool tips for the object type/name or in the command line bar when I selected it, so I at least don’t have to search so bloody much. Ideally, when I select a block in the viewport, the Block Edit list should just jump straight to that block (as an option, I guess).

Annoyance 481:

  1. Edit block instance with several hundreds of nested blocks
  2. Try to find a nested block far down the list
  3. Minimize the expanded blocks in order to shorten the list

Result: Each time you minimize a top level nested block, the list jumps to the top!
Expected: If there’s no “collapse all” command, at least don’t force the user to scroll down every time.

In BricsCAD when editing block in place hide and isolate commands are not allowed. But there is editing in a separate window where they work, but the rest of the model is not visible. As a workaround of hiding you can use ShowSelected to unhide only block objects.

McNeel will never hear our plight regarding blocks, so do like me : get a huge screen :slight_smile:

Hello - Annoyance 698 is indeed a bug and has been fixed.

https://mcneel.myjetbrains.com/youtrack/issue/RH-46745

I am not sure I understand 327 though - Show shows everything that is hidden that is what it does. Use Unisolate or ShowSelected to get just some.

-Pascal

1 Like

Great! Wow, 2 years old bug, eh? It just really goes to show that nobody edits blocks in Rhino. :slight_smile:

(Also, again, fix only in WIP, which according to @wim isn’t production ready… I wish there was a “stable” WIP release that I could use that guaranteed wouldn’t eat my files…)

Annoyance 231:

  1. Edit a block instance with nested blocks
  2. Attempt to select an instance by name

Result: This pops up a new window, separate from the already opened Block Edit window, which doesn’t just include the nested blocks you’re currently editing, but ALL blocks in the file (which you shouldn’t be allowed to even select, since Rhino locks these while editing a block).
Expected: Why can’t I just click in the Block Edit list to select a block?

@Pascal this is similar to 327 you commented on. Some tools in Rhino don’t understand the new limited context of objects that Block Edit presents to the user. Some tools still operate as if all objects are available for editing when they’re not. And as I mentioned, sometimes unisolate does too!

Annoyance 831:

  1. Copy an object from a layer
  2. Isolate a block on a different layer
  3. Edit the block (and perhaps nested instance within that block too)
  4. Paste the previous object

Result: ALL objects from the layer the copied object resides on are now shown as dark grey (which currently interferes with editing of the block), INCLUDING a duplicate of the pasted object, even if you move or otherwise change it!
Expected: Only the pasted object should appear, and nothing else. Ideally, pasted objects should end up on the selected layer (but perhaps there is a setting for this somewhere).

Annoyance 93:

  1. Edit a block instance
  2. Find a nested block in the list and edit it
  3. Close the block edit
  4. Edit the same instance and try to find the same nested block

Result: The nested block has now moved in the list (to the top).
Expected: A hierarchy should always be fixed unless the user changes it. Ideally, it should be in alphanumerical order, unless a custom order has been set.

Annoyance 1356:

  1. Edit a block instance
  2. Rotate a nested block using the gizmo

Result: That nested block simply disappears from the list (until you edit the block again).
Expected: Well… call me crazy, but I don’t think it should disappear…

Annoyance 1747:

  1. Edit a block instance
  2. Observe the list order
  3. Stop editing the instance
  4. Edit the block instance again
  5. Observe the list order

Result: Some blocks move around in the list every other time you open it!
Expected: Again, see annoyance 93. A list should not change on its own accord!

1 Like

Thanks, that’s logged as https://mcneel.myjetbrains.com/youtrack/issue/RH-57339

Annoyance 2136:

  1. Edit a block that only has a single instance
  2. Explode all blocks inside that instance
  3. Purge all BlockDefinitions
  4. Make a new block of something inside the instance

bild

Result: BlockEdit doesn’t recognize that another BlockDefinition has changed, just as it’s very unreliable to update the actual hierarchy tree in real-time while editing nested blocks.
Expected: Everything you see should be live. You shouldn’t have to quit out of the BlockEdit to have it update other blocks.

Fun side effect: If you, between step 2 and step 3 instead exit out of the BlockEdit and enter again after step 3, you can create a new block named exactly the same as many times as you want and Rhino will never complain, and I have no idea what the results of that are… (memory leaks?)

Annoyance 3567:

  1. Have a lot of nested blocks in a file
  2. Open the BlockManager
  3. Selected a block definition that’s nested only
  4. Select “used by instances”

Result: Nothing gets selected. Ok, sure you can use the “used by” button instead, but the resulting list in that additional window doesn’t allow anything to be selected.
Expected: The lowest bar is to at least select all blocks that have it nested inside it, and the preferred thing would be to actually select all instances of it, nested or not.

Annoyance 4377:

This popup doesn’t tell the whole truth, because you can access nested instances via BlockEdit as well… only, not through the obvious double-clicking, but rather solely by single-clicking in the list… and that may occasionally also fail… and it can also be difficult to see

bild

2 Likes

Hello - it would be helpful, if you find a bug, or something you consider to be incorrect, to simply start a new topic explaining the bug and how to reproduce it, with an example file if that applies. It is hard to impossible to interpret and chase down the behavior from vague descriptions of how annoyed you are.

-Pascal

1 Like

Ok, fair enough, I removed the Annoyance that wasn’t generalized.

All others in this thread have reproduction steps that can be made in any file, and that’s evident by the fact that apparently at least one has been fixed in a WIP build.

1 Like

Got it, thanks - it looks like ‘used by instances’ is actually simply selecting top-level instances of that block.
https://mcneel.myjetbrains.com/youtrack/issue/RH-57486

-Pascal

I don’t know if this “annoyance” has been listed yet, but I’m trying to write a script that will extend SelColor command to nested blocks - unfortunately it seems like it’s not possible to select them unless in BlockEdit mode (and only one level deep). Is this something that could be changed (that is allow for nested sub-object selections)?

I thought that this thread will be a good place to mention it, but please correct me if it’s off-topic.

1 Like

Since someone bumped this thread… it’s still not any better… this is me just today…

Annoyance 6751:

Trying to find where a block is in amongst 300+ other blocks is utter madness, especially since it’s not in alphanumerical order, and the other can change between dialog opens…

No highlight of currently select block in list, no collapsing children, and no search in the list either.

EDIT: Oh, and forgot to add, since this is an imported file… see all of those “Block XXX” blocks? We didn’t create those, Rhino did on its own, and it’s really, really problematic when you import large files.

Annoyance 7123:

You can’t easily delete a block that you have absolutely no interest in from the Blockmanager, because you get this…

image

2 Likes

rhino 8 is last chance to fix blocks for once and for good.

3 Likes