FactoryTalk View SE Display Name on Screen

According to Rockwell, there is no way to dynamically show the name of a display (from the designer display tree) on a screen. I have a feeling that there is.

What I want to do is show a Displays name on the corresponding screen. There are hundreds of screens in this application and the naming convention the original programmer used makes no since (i.e. "GLEOX1"). I could go to each screen and statically display the name of the screen, however that is too much work. I would like to use a global object, which would just be a string display, that I can drop on any screen and in turn it will show that displays name. I could not find a function that would do this, however.

Does anyone have any thoughts, ideas or suggestions?

Where are you going to store the new "non-confusing" name, unless you're going to rename all the .gfx files? You can do it in VBA, but that's going to give you the .gfx name of the screen. And the VBA code would need to be in each screen that you want to show the name.

John (jkerekes), thanks for the response. I don't want to rename the .gfx files, I want the "confusing" name displayed on its screen. I did not want to get to involved in making this happen, but if it were to be a bunch of copy pasting it may be worth it. The idea is to be able to navigate to a screen in runtime and be able to see the "confusing" name on it. This way I can go into development and easily find that screen. Hopefully that all makes sense.

-Ryan

In VBA, something like this:

Private Sub Display_AnimationStart()

Text1.Caption = Replace(Me.FullName, "/::", "")

End Sub

Text1 is text on the display with its properties exposed to VBA. Its a fully qualified name, so I'm deleting the "/::" that would normally show up in front of the screen name.

John,

That did exactly what I wanted. It's a little more work than I wanted, but justifiable.

Thanks again!

-Ryan

Glad it worked. Maybe just add error trapping so that the VBA doesn't get hung up. Probably not so important with a short routine as this.

jkerekes said:

Glad it worked. Maybe just add error trapping so that the VBA doesn't get hung up. Probably not so important with a short routine as this.

Click to expand...

It is ALWAYS important when using VBA, since it is single threaded. Untrapped errors can completely halt the execution of all VBA modules, not just break one routine. It won't always, but just a simple "On Error Resume Next" eliminates potential problems.

I always use at least that, but usually put:

On Error Goto Errhandler

Errhandler:
LogDiagnosticsMessage Err.Number & " " & Err.Description & " Sub: function_call_name() ", ftDiagSeverityInfo

rdrast said:

It is ALWAYS important when using VBA, since it is single threaded. Untrapped errors can completely halt the execution of all VBA modules, not just break one routine. It won't always, but just a simple "On Error Resume Next" eliminates potential problems.

I always use at least that, but usually put:

On Error Goto Errhandler

Errhandler:
LogDiagnosticsMessage Err.Number & " " & Err.Description & " Sub: function_call_name() ", ftDiagSeverityInfo

Click to expand...

What I meant by a simple routine as this is the function being used here has little chance of causing VBA to halt. But you never know. Error trapping is a good idea.