Set Thread.CurrentUICulture to the desired CultureInfo. If you have controls that have already been initialized, you'll have to re-initialize them (note, not necessarily reinstantiate them) with a ResourceManager to have the new culture's information read from the satellite assemblies. If Windows's regional settings specifies a different culture for the UI, this all happens by default using the selected language, if available. Otherwise, the ResourceManager resorts to the neutral resources language (the localized resources in the assembly that contains your code). You should use the assembly attribute, NeutralResourcesLanguageAttribute, to keep the ResourceManager from making unnecessary look-ups for satellite assemblies for the culture that is already included in your primary assembly.
Thanks heath but... I already know all this. Again, I need this application to change the system's locale. I know this will not change the locale of running processes, but will determine the locale of new ones. This is what I need - this little applet is for performing a repetitive testing operation we need to do in several locales. About which locale this applet runs in... I don't care! It is not even localized. The app I am using to test of course is.
I am currently calling a C++ DLL which does the correct calls kludgy! (SystemParametersInfo with SPI_SETDEFAULTINPUTLANG)... kinda works but I want to know if there is something in the FCL to do this.
So, basically, same as so often, use API's because FCL does not offer everything you need...
I know the concept goes way beyond this, but sometimes the FCL just seems like another wrapper around the API's which, to do some things, you need to call directly. Good old API's, glad I learnt them. Same story as VB programmers wanting to do things, having to call API's and getting all confused because they have no idea what an API, handle, etc, is....
Sure the framework/clr offers a ton of interesting things and makes things much easier, but why only offer a subset of the functionability of the API, not all? (like in this case). To make it portable to other platforms???!?
It's supposed to be a wrapper. The ability to P/Invoke makes framework extensible, although not portable as you mentioned. I haven't checked yet, but I'm betting Mono does support P/Invoked calls, albeit in a different library. I'm not defending this design, just mentioning that Microsoft has been very clear about this. It's not another Java - similar concept, different implementation. The JVM takes care of all the OS-specific operations, but the CLR is meant only to manage the objects and provide interoperability services. It sure beats JNI! (Trust me, I know). I guess you could say that they really differ most on how they handle native calls and both have advantages and disadvantages in the way they handle them.
Also, sorry I didn't notice that you said "system locale" in your first post. I read the thread before I posted originally and guess it just completely slipped my mind.
Do you need a ListView or a ListBox? The samples that are available are vastly different, and owner-draw ListBox examples are far more plentiful because they provide managed support for owner drawing, where a ListView requires that you override a hell of a lot of Windows messages and handle many different notification messages.
At this time, there isn't many articles on CodeProject about this. There was one, but the guy used CodeProject as a testing front for what he later turned commercial.
To know what you need to do, research the Windows Common Control ListView. There are messages and notifications that you must be familiar with. After this, you override WndProc in your ListView derivitive class and handle those notification messages. You'll probably also have to P/Invoke several methods (especially SendMessage) and create constants that represent message ID, and several structs.
I would like to write a series of articles on WinFX --or Avalon, or whatever the name for new technology for writing Windows Application in Longhorn will be.
Probably, when Longhorn gets into beta and things get more well defined I will start posting some of my findings here. The new batch of technologies making a debut in Longhorn will surely keep us busy for years to come and I am certainly looking forward to sink my teeth on all the information related with the new UI model.