≡ Menu

Customizing Object Names Using the DisplayName Constant

Rich Client view of datasets showing their object_type
Share the knowledge

Magritte's "The Treachery of Images" (1928-9) or "Ceci n'est pas une pipe" ("This is not a pipe").

Without the label this would just be a painting of a pipe

Have you ever found yourself talking to a user on the phone who has no idea what a BOM View Revision is, so you end up trying to describe the icon they’re looking for? It’s the one with the three colored boxes that looks a bit like a two pronged fork….

Or how about datasets? Most of them use the generic icon of a gear and the default name is the Item Revision’s ID. There’s nothing like having three objects datasets with the exact same name and icon that you know are actually different types. Oh, and those two that do have custom icons — you can’t remember what the icons mean.

Yes, A picture is worth a thousand words, as the saying goes. But sometimes a few words would be a lot more useful. So today, if you’re using Teamcenter 8.1 or higher, we’ve got a tip for you to add a few descriptive words to your Teamcenter interface to make things a bit more clear. And best of all, you don’t have to write any custom code to do it.

Display Names

In the BMIDE application if you open the editor for a business object type you’ll see a section of the first page, entitled Business Object Constants, and within that list of constants you’ll see one called DisplayName. The default value for this constant is $object_name, which means that the display name is whatever value is stored in the object_name property. However, you can override the default value and use other properties. You can also hard-code specific strings of text by enclosing them in quotation marks, and you can join different properties and strings together with the plus sign, +.

[box type=”note”]Version Information I’ve done this in Teamcenter 8.3. According to the documentation it seems that the DisplayName constant was added in 8.1, but I can’t verify if it worked the same way or at all prior to 8.3. If anyone can verify this one war or the other, please leave a comment.[/box]

A few examples of how I’ve used this will make it clear.

Datasets

First of all, let’s label datasets so that we can always tell what type of dataset they are, regardless of whether they use a custom icon or the default icon:

DisplayName=$object_name+" ("+$object_type+")"

New default DisplayName for all Datasets

object_type is the property that holds the name of the business object type of an object. By setting it on the base Dataset business object, all of the sub-types will display their own type in their display name. So AVI datasets will have Display Names that end in (AVI) and AutoCAD datasets will have AutoCAD.

UGMASTER

But maybe UGMASTER isn’t the best object_type value to display for that type; after all it’s been a few years since Unigraphics was renamed to NX. You know some new engineer out there would be wondering what an, Ugg Masteris. So let’s provide override our override with something that may make a bit more sense in today’s environment:

UGMASTER DisplayName=$object_name+" (NX Master Model)"

Overriding DisplayName for UGMASTER Datasets

Results

After deploying the data model to the database, here’s how the datasets will display:

Rich Client view of datasets showing their object_type

Nicely Labeled Datasets, as seen in the Rich Client

Now, even for the datasets that use the generic gear icon, it’s easy to tell what’s what.

Workflow Process Creation Date

Have you ever looked at the referencers for an object that had been submitted to multiple workflows, or one workflow multiple times, and wondered in which order they had been done? How about we set up the display name of the workflow task to tell us when exactly it was created? Try setting the DisplayName of EPMTask business objects to $object_name+" ("+$creation_date+")". Then when you check your referencers you’ll see something more like this:

View of revision with workflow process referencers showing creation time

$creation_date tells us when the workflows were created

Conclusion

Personally, I think it makes things a lot easier to understand and communicate by showing the users exactly what type of object something is or when something was created (or modified or released or…). Do you have any other neat ideas for a DisplayName that will be helpful to the users? Leave a comment and share your idea with everyone.

  • Suresh

    It’s an excellent information Scott

  • PB

    Useful information. Thanks.

  • Rajesh Korada

    this information is very useful  ..

  • Alexey Sedoykin

    Tnx for useful information but i like accept other icon for datasets

  • Luciano Lima Cassiano

    Very good tips!!

  • Bagyaraj S

    thanks for information

  • Menk Slot

    Hello Scott,

    Can you compare this with DATASET_saveas_pattern in TC 2007 unified?

    Regards,

    Menk Slot

    http://www.plmconsult.nl

    • http://plmdojo.com/ Scott Pigman

      Hi Menk, good to hear from you.
      DATASET_saveas_pattern controls the actual value stored in the object_name attribute of the dataset, while the DisplayName constant controls how the name is rendered and displayed to the user.

Optimization WordPress Plugins & Solutions by W3 EDGE