Live-Control Tag vs Multilanguage String

Datalinks in GEMS just show DATADATA when in Graphic Studio. I wanted to be able to see the actual module tag. I ended up not using Control Tag type in my GEM... still using Gem.Tag but Tag is a multi language string. All expressions and scripts work the same. The problem i ran into later was when adding a Gem within a Gem. So, I have a faceplate GEM that contains a MODE GEM... the MODE gem uses Control Tag. So, it won't let me select Gem.Tag of the parent Gem since it is multi language string. I can get around this by making that embedded MODE gem also a multilanguage string. But, I'm going to have to do this for all gems that i would embed in others. "SG_" types, if you will. 

I'm weighing the pros and cons and aside from the INFO pane listing top level tags and having to do a lot of rework... i don't see any other negatives. The pros of course is seeing a dozen valve modules on my graphic configuration that actually shows the Module Name.... 

TreyB

• 18 Feb 2026 9:35 PM
• Cancel

2 Replies

• Andre Dicaire

  

  • 19 Feb 2026 12:46 AM

  I had the same realization. The Friendly Name string I think was supposed to provide a contextual name offline in graphic configuration. At some point, our library decided to treat the Friendly Name as an operator option rather than an offline configuration feature. As a result, it became important that it be consistent on all displays and instead of having to configure this on every GEM every time, they created the Module level Friendly Name. To select from the GEM Friendly Name or the Module Friendly Name, you either enter a Friendly Name or you enter "FROM_MODULE". That leaves you with "FROM_MODULE" viewing the display offline. The reason for that is the Display Settings dialog only gave the option to show Tag, Description or Friendly Name (based on value of ShowTag variable in the Layout).
  
  I ended up restoring the Friendly Name as a string that is on top of the GEM that displays the name. I also added an option in the Display settings to show from Module and from Gem. At runtime, the value of Lyt.Showtag determines which name to show. The user can select from Tag, Description, Gem name, module name. IF Gem Name is selected and the Frienly name was left at default DATADATADATADATA, then I show the Tag. If Module name was selected but is null (""), ir show the tag. If you take away the GEM Name as an option in Display settings, the operator gets the Module Name or Module Tag if left blank.
  
  But now, all my GEMS can show me the GEM friendly name offline and my Gems have context for easier identification.
  
  Other option:
  Before this, I tried to rename all my GEMs in a display so I could find them in the palette view more easily. That means setting a Fiendly name and the GEM palette name for each GEM. The default palette name is the GEM name from the library with an appended number. But with a friendly name in the display itself, I can click on the GEM in the display to highlight it in the palette and I don't so much care about the renaming the palette Gem name.
  
  PS: We don't use the OOB GEMs because they are not resizable and they have external artifacts that interfere with selection of near by GEM's, There are "hidden" frames that can cover another GEM and you have to play around with what is forward/backward. Plus they don't leverage Live features. We have a separate Frame GEM and a NAME GEM which allows each instance to be resizable and adjust where the Name is positioned. So we can modify the NAME portion of all the GEMs. The Frame GEM handles the hotspot and alarm colors. I use one box for abnormal/alarm color, one box for highlight color and one box for Alarm text color. I animate the box line size between abnormal and alarm. I decided to make the boxes concentric and show them with line thickness. This makes the frame resizeable by click and drag. No preset frame sizes in a Custom Selection. We also moved the Abnormal Icons outside the frame so it isn't resized by animation based on the presence of Abnormal conditions. The Selection box is always the same size on a GEM. The highlight box goes to a thin dark line so that selection area is always visible. Three boxes, a color function and some line thickness animation giving flexibility in sizing. Way less scripting that OOB so I expect less CPU loading too.
  
  Maybe I should do a blog on "how to Build your Gems". BOL and the OOB GEMs are not what I would call best practice.

  Andre Dicaire

  • Cancel
• TreyB

  

  • 19 Feb 2026 1:21 AM

  In reply to Andre Dicaire:

  yeah, we don't use the OOB at all. Took an idea or two, but definitely didn't incorporate the Layout options regarding friendly names, etc. I can certainly make this work using a second configuration entry. But, that was the thing i wanted to avoid. In our case it would likely just be an offline label only, which is simply the module tag entered for the configuration Gem.Tag. So, basically just entering it twice. I'm still not clear what we gain from using Control Tag parameter type, which is ultimately going to determine the course we take. If we don't need to use it... then multi language string accomplishes everything.

  • Cancel