Library looks very cool but is not working with VS 2012 beta.

Design time support finally works when restarting VS. 

But at run time: Resources are always taken from default culture and ignoring Thread.CurrentThread.CurrentUICulture. When setting content from code behind it works without problems. So there might be a problem with your library?

Tested with 2.0.0 and 2.1.0 beta nuget packages.

Best regards from sunny Bremen

Björn

Hi Björn,

I've tested design time and runtime in my Win8/VS2012 RC (Release preview) sandbox and it worked. Did you experience this behaviour only once or repeatedly?

The other question is rather philosophical - we decided not to set the culture on our own due to several reasons. We recommend binding the culture to your viewmodel and handling an unset culture there.

Best regards from boiling hot Jena,

Uwe

Hi Uwe,

perhaps I misunderstood the concept. Evertything works fine when setting

WPFLocalizeExtension.Engine.LocalizeDictionary.Instance.Culture

to the supposed culture. 

Best regards

Björn

I was just testing WPFLocalizeExtension with the official release of Visual Studio 2012, and changing localization at design time does not appear to work. Changing localization during run time is just fine though.

Any thoughts, or has anyone else had issues with design time?

Up to now, I do not have the VS2012 release here.

I can confirm it not working in VS2012.

It doesn't show up in the Designer until you completely restart VS. Changing the DesignCulture doesn't seem to work at all.

I have no clue how I could help debugging that. Maybe you can point me to the right direction, MrCircuit? :-)

I'll switch to VS2012 soon and then I'll have a look at it.

Sorry for the delay.

I tried it again today... after restarting VS, it works O.ô

As it seems, the .resx files don't get reloaded after editing and/or building them, so adding strings or editing them has no effect until I close and re-open the solution or restart VS.

Also, when I edit the XAML and modify the key of a working Loc extension, the new string only shows up after changing the DesignCulture or re-opening the XAML.

I haven't tested it thoroughly, so there might be more problems or maybe I misinterpreted some observations. I hope you can find the problems and fix them. I could try and debug the extension's code, but I currently have no idea how to debug the code while it's run by the designer. Any help with that?

Hi,

In general, the project that contains the resx files has to be rebuilt after changing the files. The second issue may be a problem with the internal PropertyChanged notification of the LocExtension - I'll see if I can reproduce this in my current version of VS.

Debugging during design time is only possible using Logging (e.g. writing to a text file or engines like NLog) or step-by-step exception-throwing supplying the state information to the exception message :-).

Best regards,

Uwe

MrCircuit wrote:

Debugging during design time is only possible using Logging (e.g. writing to a text file or engines like NLog) or step-by-step exception-throwing supplying the state information to the exception message :-).

Hi Uwe, thats not completly true. In VS2010 it was possible to start a second instance of VS2010 and attach to the process of the first VS2010 while debugging. The second instance got the wpf localize extension source open with breakpoints enabled.

Its a crazy setup but was working fine. Please have a look if this is still true for VS2012.

Best regards
Bernhard

Hi,

Here comes an update:

I've digged into the key change issue that occurs in all versions of VS. Up to now, I found the following facts:

* If the key is supplied using the constructor syntax (e.g. "{lex:Loc SomeKey}"), no update of the property is fired internally or in other words, the object is not created again. This needs the particular XAML to be reloaded (close and open again, rebuild project...).

* If the key is supplied via the Key property (e.g. "{lex:Loc Key=SomeKey}"), an update is propagated to the internal property but it does not trigger an update of the value, although it *should*. Again, a reload of the XAML makes the changes to take effect.

* When changing a key, that is supplied using one of the previous two ways, and *then* changing the design culture, the value is updated correctly. I'll try to find out more on this.

Best regards,

Uwe

tried both way with Key no no key and it will not flip language at design time