Wish / Bug with CurrentUICulture?Wish / Bug with CurrentUICulture?
Old forum URL: forums.lhotka.net/forums/t/7782.aspx
rfcdejong posted on Wednesday, October 14, 2009
The CheckRules() on the ObjectFactory is executed in the background worker from the dataportal, the .NET ResourceManager looks at the CurrentThread CurrentUICulture to find the correct resource.
We have the need to force the culture to dutch in every situation, however a backgroundworker process does create a new thread and the CheckRules in the ObjectFactory does the checking in the default system language instead of the language which is set at application startup:
// globalization forceren op nederlands
CultureInfo culture = CultureInfo.CreateSpecificCulture("nl-NL");
System.Threading.Thread.CurrentThread.CurrentCulture = culture;
System.Threading.Thread.CurrentThread.CurrentUICulture = culture;
I've found someone else with the same problem, but he has access to the backgroundworker and could solve it himself.
http://stackoverflow.com/questions/1460023/how-can-i-change-the-currentculture-of-the-entire-process-not-just-current-threaHereby my request to set the culture in the DataPortal and DataPortalT classes like above
Fintanv replied on Wednesday, October 14, 2009
Does putting the following in your App static constructor help?
public partial class App : Application
{
static App()
{
// Ensure the current culture passed into bindings is the OS culture.
// By default, WPF uses en-US as the culture, regardless of the system settings.
//
FrameworkElement.LanguageProperty.OverrideMetadata(
typeof(FrameworkElement),
new FrameworkPropertyMetadata(XmlLanguage.GetLanguage(CultureInfo.CurrentCulture.IetfLanguageTag)));
}
RockfordLhotka replied on Wednesday, October 14, 2009
The data portal (client-side, .NET only) raises some static events you can use for pre- and post-processing.
- DataPortalInitInvoke
- DataPortalInvoke
- DataPortalInvokeComplete
You should be able to use DataPortalInitInvoke to set up your thread's context before the data portal copies the context into the message that is sent to the server.
JonnyBee replied on Wednesday, October 14, 2009
Hi,
Are you using the BackgroundWorker component or the async DataPortal<T>
If you are using the DataPortal<T> then your request may be about extending the DataPortalAsyncRequest to include the CurrentCulture and CurrentUICulture. This seems perfectly reasonable to me as the DataPortal does transfer the culture info to the server DataPortal and the DataPortal<T> should (imo) not be locked down to system default culture on the client.
And I strongly recommend to use the async DataPortal<T> rather than BackgroundWorker. DataPortal<T> today sets the following values on the background thread:
Csla.ApplicationContext.User = request.Principal;
Csla.ApplicationContext.SetContext(request.ClientContext, request.GlobalContext);
If you use the BackgroundWorker you will loose theClientContext and GlobalContext (when accesed will create new ones) and the background thread will run on WindowsPrincipal. LocalContext is always Thread specific and will not be transferred to another Thread.
I'd vote for this extension/change as well - we will probably be using another culture than system default in our applications in the future.
An alternative workaround/fix may be to:
- set the culture name in ClientContext variable (when you set custom culture on UI thread)
- make sure to use the DataPortal<T> for async DataPortal calls
- use your own intermediate baseclasses
- set the tread culture in Invoke method in your ObjectFactory base class (gets the DataPortalContext as parameter)
This will allow you to transfer the client custom UI culture to ObjectFactory base clas and set the culture on the "logical serverside" before the actual Factory method is called. No change required in your Factory classes other than make sure to inherit from your intermediate base class.
Although more complex than Rockys suggestion I expect this would work for Silverlight too.
rfcdejong replied on Thursday, October 15, 2009
Thanks for adding this to the wishlist, we have a workaround to put this in our own layer and use the application context or something which is being read in our U4AObjectFactory.
@
JonnyBee About the dataportal, we use it always ASync except when calling business factory methods from the server. When calling from the client it's like this:
public static void GetVoorwaarde(int prdVoorwaardeID, EventHandler<DataPortalResult<Voorwaarde>> completed)
{
DataPortal<Voorwaarde> dp = new DataPortal<Voorwaarde>();
dp.FetchCompleted += completed;
dp.BeginFetch(new VoorwaardeCriteria(prdVoorwaardeID, NaarVoorwaarde.Bestaand));
}The BeginFetch starts a backgroundworker in csla code under DataPortalT.cs BeginFetch.
/// <summary>
/// Called by a factory method in a business class or
/// by the UI to retrieve an existing object, which is loaded
/// with values from the database.
/// </summary>
/// <param name="criteria">Object-specific criteria.</param>
/// <param name="userState">User state data.</param>
public void BeginFetch(object criteria, object userState)
{
var bw = new System.ComponentModel.BackgroundWorker();
bw.RunWorkerCompleted += Fetch_RunWorkerCompleted;
bw.DoWork += Fetch_DoWork;
bw.RunWorkerAsync(new DataPortalAsyncRequest(criteria, userState));
}rfcdejong replied on Tuesday, April 13, 2010
issue not found?
RockfordLhotka replied on Tuesday, April 13, 2010
I think it was a duplicate and was merged into another issue - Jonny changed the data portal to pass culture through on async requests for CSLA 4, so I expect that this issue has been resolved.
Hossain replied on Tuesday, October 15, 2013
Hi,
Is this problem solved. I was doing diffrent aproach but no progress. I there a way to set the culture from client side and taking corrent Resources?
JonnyBee replied on Tuesday, October 15, 2013
Hi,.
Can you provide us with a code sample that reproduce the issue?
Copyright (c) Marimer LLC
