2010-09-13 6 views

Respuesta

8

Esto no es posible. Los subprocesos obtienen su referencia predeterminada cuando Windows crea el subproceso, inicializado desde la configuración regional predeterminada del sistema tal como se configuró en el Panel de control + Región e idioma. Las funciones pertinentes de la API de Win32 son Get/SetThreadLocale().

No hay ningún mecanismo en el CLR para imbuir un hilo con otro valor predeterminado. Un escenario común para un hilo es comenzar la vida creada por un código no administrado y ejecutar gran cantidad de ese código no administrado, haciendo ocasionalmente una devolución de llamada en el código administrado. Ese código administrado se ejecutará con Thread.CurrentCulture establecido en la cultura seleccionada por el código no administrado. O el valor predeterminado de Windows si el código no administrado no llamó a SetThreadLocale(). Tener el CLR modificado causaría una falla no diagnosticable en el código no administrado.

Por supuesto, puede anularlo explícitamente pero es difícil hacerlo bien. Los sutiles errores de formato son fáciles de ver, se vuelve difícil cuando se usan, por ejemplo, las estructuras de datos que implícitamente dependen de los órdenes de clasificación de la cadena. Una SortedList de repente no puede encontrar un elemento en la lista que está realmente presente. También es difícil controlarlo, muchas devoluciones de subprocesos de subprocesos de subprocesos en todo el marco de .NET.

No pierda el tiempo con esto para evitar caer en trampas como estas, ya sea que confíe en el sistema predeterminado o aplique CultureInfo explícitamente.


ACTUALIZACIÓN: como se ha señalado por Thomas, una solución estará disponible en .NET 4.5, tiene una nueva propiedad de la clase CultureInfo para establecer la cultura por defecto del dominio de aplicación. MSDN docs are here. La interacción exacta con subprocesos no administrados que ingresan código administrado no está muy clara en la documentación, asegúrese de verificar esto si alguna vez permite que el código nativo realice devoluciones de llamada, como a través de pinvoke, Marshal.GetFunctionPointerForDelegate() o el evento de un objeto COM.


Update2: esto se cambió de nuevo en .NET 4.6, la cultura ahora fluye de un hilo a otro de modo que los modos de fallo peores son atendidos. Lea los detalles al respecto en el artículo de MSDN para CultureInfo.CurrentCulture. Debes dirigirte explícitamente a 4.6 para obtener el beneficio.

+1

Según [esta página] (http://msdn.microsoft.com/en-us/library/ms171868%28v=vs.110%29.aspx), será posible en .NET 4.5: "Capacidad de definir la cultura para un dominio de aplicación". Sin embargo, no encontré cómo hacerlo ... No puedo ver ninguna propiedad relevante en AppDomain o AppDomainSetup –

+0

@Thomas: ver Valdis '[respuesta] (http://stackoverflow.com/a/8030336/107604) abajo. –

3

Usted podría tener un método personalizado que va a disparar las discusiones y la cultura ajustar automáticamente:

static bool StartThread(WaitCallback callback, object state) 
{ 
    return ThreadPool.QueueUserWorkItem(s => 
    { 
     // Set the culture 
     Thread.CurrentThread.CurrentCulture = new CultureInfo("es-ES"); 
     // invoke the callback 
     callback(s); 
    }, state); 
} 

Y cuando se necesita para iniciar un nuevo hilo simplemente utilizar este método:

StartThread(state => { /** Do some processing on a new thread **/ }, null); 
+0

solución bonito ... pero no alcanzará la meta - Necesito algo que va a establecer la cultura, incluso cuando me olvido de configurarlo. Lo mismo puede suceder aquí si olvido iniciar el hilo a través del método 'StartThread'. Quiero que todos los hilos hereden su cultura automáticamente – Nissim

+0

Exactamente. ¿Puedes mostrarme el fragmento para hacer esto? – Nissim

Cuestiones relacionadas