How long do bugs take to be resolved? Well, sadly in some cases the answer is “more than 5 years”. At least 6, possibly even more. Here’s proof.
This tool is not widely known, possibly due to discoverability. It’s not a button that is always there, but one that appears when you select a datum, such as a grid or a level. The idea is that when you change the extents from 3D to 2D, you can then propagate these custom 2D extents to other views. But there’s a catch: for some reason this functionality is broken when it comes to views that have a crop region enabled and when the datum’s 3D extents go beyond this crop region. Let’s say you have grids or levels close to each other and the text overlaps. In this case you add an elbow by clicking the little in-canvas symbol and make necessary adjustments to your view, perhaps even shifting the datum’s end point. Since this is a view-specific edit, the use of the Propagate Extents tool will then help you push these changes to all the other views you pick.
There is a workaround for this problem and it’s annoying if you have a lot of views to work with:
- Disable the Crop Region in the view that contains the 2D extents you want to propagate, and also in the views you want to propagate to;
- Select the datums, click the Propagate Extents button on the Ribbon, pick your views and finish the command;
- Re-enable the crop regions in the affected views.
To me this seemingly trivial tool is so good that it’s a shame it doesn’t work properly. I think it’s time to dedicate some manpower to get it fixed.
Posts
8 comments:
You say bug, I say paradox...
A view that is cropped will likely have different, possible exclusive needs compared with other views. It was probably a lot more work to examine every other view to see if a crop boundary was active and within a size range to "match" the view you are using as a gaugue so that the extents could be propagated successfully.
I suspect they reasoned that it was more "exception" than the "rule" and moved on to other "problems".
Just me guessing...
Hmmm never thought of it that way. In my limited experience, I've always found that most plan views are cropped, even overall plans. So if programmers assumed that using this tool on cropped views would be an exception, it really should be more of a rule I think. Say you have a building and you split in in 4 areas. Now you'll have a set of plans for each area (dimension plans, furniture & equipment, etc.) and you want to keep gridline extents coordinated between each area. Wouldn't this be a typical use case for this tool? I think I understand what you're saying in terms of knowing which crop regions match. I see it differently: the user knows which views they want to propagate to, so there should be no issue: let the user pick. Currently the tool looks like it's been disabled, yet we still have a clickable button that does nothing.
I've had a lot of questions about this tool sprouting from the fact that it doesn't seem to work. I filed a SR on this and it wasn't denied as a "bug", but was added/linked to other grid line extents issues to be resolved in the future.
Anyway, perhaps as you say, this was a logical decision with an illogical (for us users) outcome :)
Great fix/workaround! I was stuck and had no idea why. Not sure it's a bug, but I think it's implemented wrong either by design or accident. Thanks again.
what about grids in 2013 and scope boxes.... now we cant uncrop if scope box constrains (were able to in 2011 and 12)... seems like the work around no longer works....around...
Andy, temporarily remove the scope box, then uncrop and do the propagate operation. Then re-assign the scope box. Yes, it has become a bit more laborious unfortuntely and still doesn't work as most users expect it to (just got a question about it this week in fact).
Dave I just tried that and thank you for the reply. It seems that it works for the views it propagates to (and by the way I didn’t unfold the views receiving propagation). But when I re-constrain, it does not retain 2d mods within the view I applied the temp 'unfold' routine to... mud? Basically view A1 fixed B1, C1, and D1. But A1 returned to its formed state when re-constrained. Orientation is a factor.
So the solution I have come up with is to create a primary/dependent set of "master grid" views that are never actually constrained to scope boxes, nor are they ever cropped. Basically, I can see the whole overall plan of grids and scope boxes the whole time. I set the VG to only show scope boxes and grids. I then use the dependent view to do the 2d mod to grids and propagate from said dependent view.
But here is where it is still tricky. So multi segment grids still do not work or grids whose 3D (not2d) extents still span several other scope boxes, or in other words is not wholly contained within the scope box…
Any other thoughts? I appreciate it
Andy, the only thing I can think of that would reset your grid edits is if the extents were not actually switched to 2D extents. However if you jog the grid bubble, that edit should always stick, although if the length of the gridline is still governed by 3D extents (the unfilled circle), it would move along with the crop region of the view. The jog in the grid bubble should not get re-set though.
A better way or thinking is like this: Grid lines should remain a category, the bubbles should simply be an annotation tag family. Where the tags intersect with an annotation crop region the grid bubble annotation tag should become visible. The programmers at Autodesk have to learn to think outside of the box (no pun intended).
Post a Comment