View reference labels as instance parameters

[richardsachs4475]

View reference labels for callouts need to be instance parameters that can be changes as needed.

Having to make different view types for OPP, TYP, etc makes no sense.

We usually end up clearing out the label and use text instead, which is not ideal. 

[lionel.kai]

It doesn't just "make no sense" - no workaround is possible. Making multiple types doesn't actually help, since each view can only be one type. This is one of those features that was shown to us in the very first demo of Revit that we saw (and the presenter was SO excited about it, too - and disappointed when we told him it's just not useable).

BTW, if it's ever fixed, this other idea would be helpful also:

https://forums.autodesk.com/t5/revit-ideas/moveable-viewnamep-label-in-section-heads/idc-p/6953146

[kgatzke]

The Reference Label has a serious flaw.  Some genius made it a type parameter.

By making it a type parameter ALL references have to have the same label, never mind if some of them are opposite or not.  They're all OPP or they're all SIM.  You can't choose, which makes absolutely no sense for annotation.

Even dumber than that is the fact that the family type applies to ALL instances of the view, so that even the originating view is the SIM/OPP.

Bottom right is the original callout.  Top is the first applied referencing view which was changed to type SIM/OPP.  A second referencing view was then added to the right.  It is also SIM/OPP because the original view is SIM/OPP. 

Brilliant!

[kgatzke]

Correction:  Bottom left is the original callout.

[dplumb_BWBR]

I swear it used to be that way long, long ago.

Like, maybe Revit 7.0 or 8.0?

[johnfielden]

I commonly have details that repeat throughout a project, needing a similar label in some locations, an opposite hand label in other locations, and no label at all in other locations because the condition is identical.

As others do, I workaround the issue by leaving the Reference Label type parameter empty and use dumb text for my labels, which is problematic and undesirable.

The Reference Label should be an instance parameter, as shown in this photoshopped image.

[_andyman]

Omg the photoshopped version got me really excited for a second.

I echo everyones thoughts here. This is just silly.

[_andyman]

Would be great to control reference text via instance parameters. If you want to reference a view with a 'SIM' tag in one view, then reference the same view with a different type as 'OH' in another view this is not possible. what happens is it changes your first reference label from 'SIM' to 'OH' because it is actually switching the type of the original reference view.

[Anonymous]

I don`t understand how this is a problem since you can apply any tags and link it to any section, allowing to freely mix and match.

[_andyman]

This is totally a problem. You may try this to prove it: First create any section, now create 2 new sections which BOTH reference the original one. Now try to label one reference "SIM" and the other one "OPP or OH". It can't be done.

---

---

[Anonymous]

Ah I see. Could you not just create a shared parameter and get this over with fairly quickly?

[_andyman]

Unfortunately no because the referenced sections are built in families which are linked to the original section's family type. You can add a global/shared parameter to all views but these referenced sections are their own thing. 😞

[Anonymous]

I 100% wish this was an instance parameter OOTB.

But, there actually is a hack that works for forcing shared parameters into the Callout Head Family. 

In the callout head family, get rid of the original 'sim' text.  Change the family category to something else that allows shared parameters... like wall tags.  Insert your shared parameter (instance)  into the family and make a label text that uses this parameter.

Select the new label text and use the 'cut' tool. Change the family type back to Callouts before pasting your text back in.  Revit remembers the shared parameter this way. (if you don't cut/paste, revit drops the parameter).   It's rough.  It's a hack.  But it does work as expected.

Note: In the project,  if you click the new callout head and don't see your parameter in the instance properties, you'll need to add it to the project's parameters and assign it to the 'views' category.

[_andyman]

This hack still does not work for referenced views. The shared parameter does not get applied to a referenced view. This can still not be done. In the attached photo i added the shared parameters using the hack and labeled the original view as '333'. I then referenced that same view as a new callout (highlighted in red). You'll notice that the shared parameter isn't there.

[richardsachs4475]

I've tried the above and its true - doesn't work with referenced views. After having submitted this I still find the current workflow fatally flawed. I was just working on a project where we needed details that could were often TYP, but not always. It's all or nothing. I kept finding that one team member needed that same detail to be SIM and they kept changing it to SIM.  And guess what happened - all the TYP's changed to SIM. And when we needed it to not have TYP at all, there's no choice in the matter. Having already placed all of them I now had to hunt down all the details and use text to show TYP just to have this one location not show TYP. And then because all of these are by type we get a unmanageable  and unnecessary proliferation of detail types when this should just be a simple text parameter we can change as needed.

[_andyman]

I feel ya man. It is annoying. We use dumb text on all of our details because that's the only way to make sure revit isn't placing 'SIM' or 'OPP' somewhere where it shouldn't.

[pieter1]

Huge +1 for making the reference label instance based.

[tj6TCQ5]

I'm confused as to why this is still an issue in 2020 Revit.

[jwhitmer1]

This needs to be fixed for Revit as in all projects there will be multiple views for a detail that need to be modified.

[pieter1]

I think it should be an instance parameter on the reference. So that when we reference a view we can decide for each reference we make whether that particular reference should have a label and what it should be. 

We don't want the same label EVERY time we reference a view. Sometimes it needs a label, sometimes it doesn't. And even if it needs a label, the label varies.

[Anonymous]

This tread is from 2016, and yet there's no solution or even a work around added for this issue in 2020. We have to still use Text to accompany the callouts that are either SIM or SIM/OPP...