Problem with changing strings using SR.SetCustomString

Ribbon for WPF Forum

Posted 10 years ago by Vernon Larcombe
Version: 9.2.0510
Platform: .NET 3.5
Environment: Windows XP (32-bit)
Avatar
Hi,

There seems to be a problem with the SetCustomString method. Some strings do not reflect the current value after a window has been changed. If the method is called to change text before any windows have been changed the changes are reflected however any changes made after that only effect some items (even in newly created windows.

I have written an application that demonstrates the behaviour which I will send to support.

Note 1: That this has been tested with the 510 build and not the latest 512 build.

Note 2: The same problem arises with the text in the docking windows (I have not tried the other areas).

Vernon Larcombe

Comments (5)

Posted 10 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Vernon,

That is correct. Resource strings MUST be modified before any UI is loaded. If you change strings after that, then some strings may update while others will not. This is because some resource strings are used in static initializers and thus do not pick up your updates made after they are initialized. Therefore we recommend you only set custom strings in your application's startup code before any UI loads.


Actipro Software Support

Posted 10 years ago by Vernon Larcombe
Avatar
Hi,

This is a serious limitation which should be made clear in the documentation about the string customization. Your recommendation is not really a recommendation it is a requirement if the UI is going to be localized.

One design goal of our application is to support the runtime switching of the UI language (i.e. dynamically switching the localised strings). Are you saying there is no way to achieve this with your product?

Thanks,

Vernon
Posted 10 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Hi Vernon,

Actually if you read the "Customizing String Resources" topic there is a bolded "Important Note" that reads:
Quote:
"Any string resource customizations should be performed at application startup such as in Application.OnStartup, before any UI or controls have been referenced. This must be done since some string resources are used by static class initializers. Therefore your customizations may not be picked up if not set immediately upon application startup before UI classes are referenced."


Since some string resources are set in static dependency property constructors, they will not be picked up until the app is restarted.


Actipro Software Support

Posted 10 years ago by Vernon Larcombe
Avatar
Hi,

My apologies for missing the warning but for the record we did the original localization work with version 4.5 where the warning in the help (although still there and quite clear) is only a "Note" and not an "Important Note" and much less emphatic:

Quote:

Any string resource customizations should be performed at application startup, before any controls have been created.


Clearly you have revised the seriousness of the note recognizing that this is a potential problem, however, even with your new "Important Note" you still say should when in reality you mean must if the majority of string customizations are going to have any effect.

Putting all this aside, you still have not answered the more important question in my original response:

Quote:

One design goal of our application is to support the runtime switching of the UI language (i.e. dynamically switching the localised strings). Are you saying there is no way to achieve this with your product?


Do you have any suggestions as to how we might get the run time language switching or is this impossible with your current design?

Thanks,

Vernon
Posted 10 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Hi Vernon,

This question had come up in the past, which is why we added more detail to the message in more recent builds since v4.5.

Sorry I thought I answered your question at the end of my previous post. Runtime switching will not be possible because some static dependency property constructors use the string resources and those are only executed once. Some other areas that use string resources will be more dynamic and will pick up changes. But it is things like the static areas that won't. For instance, here is some code for registering a depedency property in ribbon:
DependencyProperty.Register("ApplicationButtonScreenTipHeader", typeof(object), typeof(Ribbon), new FrameworkPropertyMetadata(SR.GetString(SRName.UIApplicationButtonScreenTipHeaderText)));
Note that the custom strings are pulled into the FrameworkPropertyMetadata, which is only loaded one time. That is why string resources must be set up in your application startup code, prior to UI being loaded.

There are other places where string resources may be set in XAML Styles/Templates for controls too. And run-time changes to those string resouces (after initial app startup) wouldn't be reflected in the UI either unless the control Styles are reapplied.


Actipro Software Support

The latest build of this product (v2019.1 build 0681) was released 1 month ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.