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:
Isolate block instance
Edit block instance
Select object within block instance
Isolate that object
Exit block editing
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.
(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.
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:
Edit block instance with several hundreds of nested blocks
Try to find a nested block far down the list
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.
Great! Wow, 2 years old bug, eh? It just really goes to show that nobody edits blocks in Rhino.
(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…)
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!
Edit the block (and perhaps nested instance within that block too)
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:
Edit a block instance
Find a nested block in the list and edit it
Close the block edit
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:
Edit a block instance
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…
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!
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?)
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.
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…
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.
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.
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.
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…
