TipStrip Localization Bug

[Mathieu_R.]

Hi there,

I'm building some Custom Step Types. I want my button and conrols strings saved in a *.ini file (MyStepTypeStrings.ini) in Components/Languages/English. My code modules are builds in LabVIEW, and I have trouble with TipStrip localization : TS_MY_TIP_STRIP¨becomes MY_TIP_STRIP. As I'm using standard OK/Cancel/Help buttons, I first localize for Category COMMON_DLG, and then for Category MY_CATEGORY.

The VI hierarchy shows the VI TestStand - Localize Front Panel.vi (password protected) is calling TestStand - Localize String and Update TipStrip.vi (not protected). Here is the diagram TestStand - Localize String and Update TipStrip.vi

Note that the output Found of TestStand - Get Ressource String.vi is not used. As long as Default String is not connected, if the Symbol is not found, TipStrip is updated with Symbol value. In my case, TS_MY_TIP_STRIP becomes MY_TIP_STRIP.

I found a workarround : if I first localize MY_CATEGORY (befor COMMON_DLG), it works fine. But it seems to me this is a bug...

Best regards,

[Mathieu_R.]

...There is a risk the Symbol of a TipStrip is altered if a Symbol is not found in a Category. The Found output of Get Ressource String is probably checked for Captions localization (I do not see this behavior for captions). The same protection mecanism should be implemented for TipStrip:

Could someone from NI tell me if this will be taken in count?

Thanks,

[~jiggawax~]

I think people assume you are from NI because you have a blue name......  😮

[Mathieu_R.]

...That's right, indeed. I quit NI France in 2010. I've changed my e-mail (two times), but I'm still a 'blue' guy ^^

[Daniel-E · Accepted solution]

Hey Mathieu,

I filed a report on this issue with the reference number 441858. I can see how the current behavior could be a bit unexpected, and I'm glad you found a workaround for your issue. Thanks for letting us know, and post back if you have any further questions about it!