Civil 3D Label Style Expressions

No serious, in-depth discussion about Civil 3D Label Styles can dodge the serious matter of Expressions in Label Styles. In the Framework for Civil 3D products, we intentionally try and keep the risk of Label Style Expression use in the Framework’s Core Style library to a minimum. This has to do with practical Civil 3D Style maintenance problems inherent in the use of Civil 3D Label Style Expressions. That does not mean we do not take seriously the potential power and usefulness that Label Style Expressions add to more complex Label Styles.

Risky Business and Civil 3D Label Style Expressions

[Que Bob Seager’s Old Time Rock n Roll bumper music]

Many of our new Framework for Civil 3D customers initially don't tend want to risk the day-to-day, production issues or confusions that Label Styles that employ Expressions may cause with their Civil 3D users.
If you'll pardon the expression, we do take the gloves off in the Jump Kit products which include many powerful Label Style Expressions.

More Expression is Possible

In our Framework Jump Kit products, we do employ some nifty Label Style Expressions to do some very useful stuff. For example - Arrange Assembly labels in Section Views based on standardized scaling/spread parameters. Yes. You can do that.

Label Style Expression-based, Civil 3D Label Style tools can save you a lot of production project man-hours when they are well-designed and constructed. Integrated Civil 3D Style functionality and consistent behaviors can generate big-time, man-hour savings. Label Style Expressions can help get that done.

Soon to be released Jump Kit AddOns for Civil 3D 2021 and Civil 3D 2020 will include a host of new Label Style Expression based improvements based on popular customer requests.
In-depth and consistent Elevation truncation support for multiple Civil 3D Features and types of Label Styles is worth doing and maintaining. It requires a lot of care and work.
More on those AddOns in an upcoming post.

Civil 3D Label Style Expressions

The current Label Style Expression functionalities and behaviors have been around in Civil 3D for ages. The stock Autodesk example Civil 3D templates even ship with a few classic examples. Flat Grades and Grade Check come to mind.

Expressions help address the historical Autodesk Make It Your Way mantra.
Expressions exist so Autodesk doesn’t have to support a bunch of specialized Label Style components and formatting capabilities that Civil 3D Users practically need, want, or prefer.

Expressions allow you to convert the object {Civil 3D Feature] information using a formula, then insert the result into the Label Style text or Reference Text component and/or modify any other math Property in a Label Style component.

What does that clarified Civil 3D help speak mean?
We can change the displayed values in a Label and/or change a Label Style Property like Text Height, Rotation, or even Color. Simple put - We can truncate the Elevation digits displayed in a Surface Spot label; truncate an Alignment Station value; and make a Slope Direction Arrow always point downhill.

Express the Rules

We do have to pay attention to rules that govern the creation and maintenance of Named Label Style Expressions. Yes. Once again, The Power of Names in Civil 3D matters.

Expression is a rather wicked and sneaky term in Civil 3D.
The Expression word is used elsewhere in the AutoCAD Map 3D Toolset and even in raw AutoCAD (see CAL, QUICKCALC, and PARAMETERS commands for example).
Expression in the other AutoCAD core applications means something different from Label Style Expressions in Civil 3D.
This can be downright confusing for the unwary.

Expressions Names and their Descriptions cannot be edited after creation.
That’s annoying.
And yet -the Label Style Expression code or value can be edited. Huh?

The naming conventions of any Label Style Expressions you want to employ are mission critical. They typically require careful planning and thoughtful external maintenance of names, descriptions, and default values.

Purging an old or DOA Expression may require the drawing that contains those Expressions to be closed and reopened to purge a now unused Expression.
Why?

A Label Style Expression adds custom user values and/or calculations to the Civil 3D Feature’s available data behind.

It is a Risky Business to add to the Civil 3D Object Model.

What Label Style Expressions Do

Technically, a Label Style Expression performs a mathematical modification of some existing Civil 3D data behind Property value or may provide an independent user Default Setting value to manipulate the same.

Label Style Expressions are programmatic tools that allow us to manipulate numeric Label Style Properties. Label Style Expressions only support a set of Autodesk specific math, some general .Net-like math functions, and basic IF, AND, OR, and NOT Boolean logic.

Beyond Simple Label Style Expressions

Notably, no typical string manipulation and/or string conversion tools are supported in Label Style Expressions for reasons unknown. You could Civil 3D Wish List for Expression string tools and/or deeper .Net math functionality I suppose. Don’t hold your breath.

If and when, you expect and or require complex logic, the rudimentary IF Boolean logic supported by Label Style Expressions can be annoying.
Maybe you have a I Cannot Express Myself t-shirt.

The Multiplicity of Label Style Expressions

There appear to be limits to the number of logic resolutions (or perhaps an undocumented character limit) allowed in Label Style Expressions.

To achieve more complex Label Style Expression logic it is usually practical to chain Expressions.
Solve and test for A, then employ A to test for B etc.

This increased number of required logic Expressions adds a bit more confusion to the available data behind stack available in the Label Style Text Component Editor (TCE).
Don’t ask me to explain why data the behind stack sorts the way it does.
Like you, I just live with it.

Label Style Expressions are unique to both a Civil Feature and the Label Type. The number of Label Style Expressions needed to produce the same functionality across multiple Civil Features and their multiple Label Types with similar data behind (e.g. all the many forms of Elevation data), can become an issue worth serious consideration, planning, and execution.

If you have employed, managed, and customized Civil 3D for a while, the odds are you already learned that…painfully.

Label Style Expression Sets

All of this complexity, multiplicity, and the required Feature and Type adaptability means that we tend to end up with similar Sets of Label Style Expressions to help our daily Civil 3D users employ our custom Expressions successfully.
A Managed Set approach is probably mandatory to keep us out of the Civil 3D maintenance Looney Bin.

You will probably want to develop and then document your more complex Label Style Expressions Sets in collections and in separate external ASCII text files. We are hard at work to add more of that level of Civil 3D resource support into the Framework for Civil 3D.

The Problem of Style Movement and Reference in Label Style Expressions

Civil 3D can be unforgiving about keeping your Label Style Expressions together and working when Styles are dragged and dropped by users from drawing A to another drawing B.

A Label Style Expression that works like Superman in drawing A appears to eat Kryptonite and die as it enters drawing B. This happens because another named Label Style Expression or symbol used in your Expression exists in drawing A but does yet exist in drawing B when the new Style enters the drawing.
Civil 3D cannot create a reference to what is not in there already.
The unknown Expression reference issue will convert your Expression's name into a GUID reference string. That results in a broken Expression and your sexy Labels that reference the Label Style Expression also die a cruel and untimely death. No fun, Son.

Autodesk Civil 3D is also nasty about not copying Expressions that do not appear to be used in any of the Label Styles you are currently coping over. Civil 3D does not always look into the Styles you are copying for references to indirectly referenced Label Style Expressions. This is Not Good.

Classic Style Import

The Civil 3D Import Styles tool isn't any better about preserving Label Style Expression integrity. In fact, you should note that Expressions are expressly not listed in the Style Import tree or well-supported by all release versions of the tool.

The symbol in the Expression – (which is your Expression name) can be all too easily corrupted by this unknown named reference fact of life.

The trick I explain below can help you systematically get around this long-standing Civil 3D limitation.

Please note:
Label Style Expression destruction does not happen for Civil 3D's internally defined and named symbols – the data behind. Those are self-contained in each Civil 3D Feature's actual code.
The formal data behind names of these may change from Civil 3D Release to Civil 3D Update however.
That can create an occasional upgrade issue with Label Styles that reference those changed names.
Generally, you usually have to skip releases with a drawing or template upgrade to run into that sort of weirdness.

The Expression conversion to GUID may happen to your own created named Label Style Expressions unless you are careful and take some relatively simple steps to protect your Label Style Expressions.

The Self-Reference Label Style

If you want to use Label Style Expressions, and particularly Expressions the refer to other named Expressions, make sure that you always define one special Label Style that employs references to all your custom Label Style Expressions in an actual and single Label Style text component.

This is a simple process. Create a Label style that has a Text component. Make sure that every Label Style Expression you want to preserve is a part of that Text component's text value. In the Text Component Editor (TCE) , add every Expression you create to the text value of that special Label Style.

An Ugly Duck Becomes a Swan

Yes. You will get an ugly label, but this ugly duckling label value will beautifully force Civil 3D to move all your Label Style Expressions around with it.
Since all the Expressions are always in there, Civil 3D will not overwrite potentially missing symbol values (your custom named expressions) to GUID values in your other Label Styles that use them.
This list of Expressions in the Text value in effect creates a Self-Referencing label.

Always Import Expression Style

In the Framework for Civil 3D, we call this Style something like +ALWAYS IMPORT to provide product users a decent chance at not blowing it if they employ the manual drag and drop Style copy method or the Style Import tool to copy new Civil 3D Styles into drawings or templates.

Label Style Expression Set Maintenance

If you create and maintain complex Expression Sets, it is good idea to create separate Style resource drawings to independently contain the Label Style Expression Sets separately from the Style collections that depend on them.

When in doubt, these separate Expression Set resource drawings allow you to Purge, clean, and more easily replace Label Style Expressions as Sets in both your Civil 3D templates, Civil 3D Style collections, and even your project production drawings.

The Style drawing classic Insert/Explode method makes that import simple. The newer 2020+ Insert Palette Tool now does that straight from the Civil 3D interface. Right click on the attached drawing resource and pick Insert Explode. Just sayin’

Recent versions of Civil 3D that support Reference Templates (TREF) honor successfully the practical import of these +ALWAYS IMPORT LabelStyles. Hoorah.

Sorry, that doesn’t always mean your Label Style Expression survived the latest Civil 3D Release upgrade or Civil 3D Update themselves.
The Civil 3D Diva uses toys where the batteries are not included.

You can fix that…

The Liberty to Work in Civil 3D
Get the Framework for Civil 3D

 

Civil 3D Label Style Management posts