Thread.CurrentCulture change event



  • Hallo,
    gibt es ein event oder ähnliches, das ausleöst wird, wenn die Thread.CurrentCulture Eigenschaft eines Threads geändert wird? So in der Form:

    Thread.CurrentThread.CurrentCultureChanged += new EventHandler ...
    

    Müsste halt mitbekommen, wann sich die CultureInfo ändert.
    Vielen dank im voraus.



  • Wenn es kein event gibt dann mach doch einfach nen eigenes Event, so zu sagen in einem Thread .... so ungefähr

    Thread th1 = new ....
    th1.Start()

    static PreviousState = Thread.CurrentCulture.ToString();
    void Thread_Event()
    {
    while(true)
    {
    if(Thread.CurrentCultureState != PreivousState)
    {
    CurrentCultureChanged(Thread.CurrentCultureState)
    PreviousState = Thread.CurrentCultureState
    }
    }
    }

    void CurrentCultureChanged(string state)
    {
    MessageBox.Show("Neuer CurrentCulture_ding: " + state);
    }

    Oder so... so ähnlich .... 😋



  • blub - und weg ist ein Kern ... da fehlt noch ein Sleep



  • Ich würde mich nicht darauf verlassen.
    Ich denk da zum Beispiel an den BackgroundWorker, der erbt die Culture _nicht_ vom generierenden Thread.
    D.H. ein generierter Thread muss nicht unbedingt die selbe Culture haben wie die Haupt Applikation.

    Ich empfehle das setzen der Culture in eine Methode auslagern (oder ein Property) welches dann immer ein event Absetzt.

    public CultureInfo CurrentCulture
    {
        get { return Thread.CurrentThread.CurrentCulture; }
        set
        {
            Thread.CurrentThread.CurrentCulture = value;
            Thread.CurrentThread.CurrentUICulture = value;
            OnCurrentCultureChanged();
        }
    }
    


  • Danke,
    ist im Prinzip beides möglich, hat aber auch beides seine Haken:
    Zur Lösung von looser:
    In "Thread_Event()" müsste natürlich der richtige Thread übwewacht werden. "Thread.CurrentThread" ist in diesem Kontext ja schon wieder ein anderer, nämlich der "Überwachungs-Thread" selber. Wäre aber einfach machbar, allerdings gibt es auch immer eine Zeitspanne, die von der Tatsächlichen Änderung bis zum Event vergeht. Außerdem wird das event in einem eigenen Thread ausgelöst, was ebenfalls zu Problemen führen kann (Stichwort Controls manipulieren, neu Zeichnen...). Trotzdem kann ich mit dieser Lösung evtl. etwas anfangen.
    Zur Lösung von CSL:
    Klar, funktioniert natürlich, solange ich eine Anwendung programmiere, und die CurrentCulture immer über dieses Property setzte. In diesem Fall habe ich ja sowieso selber die Finger drauf, die CurrentCulture ändert sich ja nicht einfach so, sondern wird vom Entwickler gesetzt. Problematisch wird es, wenn ich eine Bibliothek entwickle, welche von Dritten benutzt wird. Dann habe ich absolut keine Garantie, dass der Benutzer meiner Bibliothek das Property wirklich verwendet...

    Also nochmals vielen Dank, habt mir beide ein Stückchen weiter geholfen!



  • Bei Bibliotheken sollte man sowieso immer so vor gehen das jegliche Culture möglich ist, auch inkonsistent untereinander 😉



  • Klar, möglich ist ja auch immer jede Culture, kann man ja schlecht (und will man ja auch nicht) verbieten.
    Aber als einfaches Beispiel:
    Wenn ich zum Beispiel ein Control erstelle, das ja nach eingestellter Culture im GUI Thread eine Landesflagge anzeigen soll. Dann wäre es doch hilfreich wenn ich mitbekomme dass sich die Culture geändert hat und ich eine andere Flagge anzeigen muss. Natürlich geht die Welt nicht unter, wenn ich es an einer solchen Stelle nicht mitbekomme, und es ist ja trotzdem jede andere Culture erlaubt.
    Mein Problem ist (bzw. war, hat sich fast komplett selbst gelöst):
    Ich greife über Platform Invokes auf C++ klassen zu, die eine eigene Lokalisierung mitbrignen. Wenn ich jetzt beispielsweise einen "Double-String" von der C++ Klasse bekomme, die gerade eine Englische Kultur verwendet, und ich würde im managed Code mit Deutscher Kultur daraus wieder ein Double machen, hätte das ziemlich fatale Folgen...
    Da die Lokalisierung der C++ Klasse aber über Umwege (gut versteckt) doch überschrieben werden kann, habe ich sie einfach über Callbacks auf die Thread.CurrentCulture.XXX (z.B DecimalPoint) umgeleitet. So wird jetzt automatisch immer, egal in welchem Thread, die gleiche Kultur wie im Managed Code verwendet.


Log in to reply