|
|||
|
.NET, Delphi, ... - Sisulizer Localization Tool Support > Technical Support (You need to be registered at the forum to write) > Bugs and Quirks in Sisulizer > XAML -- where did my events go?
|
|
|||
|
.NET, Delphi, ... - Sisulizer Localization Tool Support > Technical Support (You need to be registered at the forum to write) > Bugs and Quirks in Sisulizer > XAML -- where did my events go?
|
| Moderated by: Renate.Reinartz, Markus.Kreisel, Jaakko.Salmenius, Ilkka.Salmenius | ||
| Author | Post | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
bikedude Member
|
By removing and adding my WPF assembly to the .slp file I was able to get rid of the exceptions in the SL IDE (see my other thread). But my original problem remains. We finally realized that our grid behaves as if no events have been assigned to it. We then investigated the embedded baml resource in the localized assembly, and both in the previous release of our software (with working grids) and the current build, the events are absent. (we used the baml reflector add-in to reach this conclusion) So who is responsible for adding those events? Where are they? The one significant change between the working version and now is that we created our own descendant off the WPF Toolkit datagrid. We've obviously triggered something, but _what_? |
|||||||||
|
bikedude Member
|
Our assembly contained a custom control used in various WPF dialogs in that same assembly. If we move the custom control(s) in to a separate assembly, the compiler will generate code behind code that assigns the events at runtime. However, containing everything in the same assembly, allows the generated BAML code to contain the event assignments as-is. Later, when running SLMake, I guess moving the BAML to a language specific resource DLL forces the event assignments in the BAML to be nuked, with the intention of generating the necessary code-behind code. Whatever the reason, the result is no assigned event handlers and a significant loss of functionality when using the localized resources. Ideas? Suggestions? Our workaround is to move these custom controls into separate non-localized assemblies. |
|||||||||
|
Jaakko.Salmenius Administrator 
|
Can you send me: 1) The original XAML file that contains the events 2) Your main assembly file that contains the above XAML as BAML 3) Your control assembly file. Jaakko |
|||||||||
|
bikedude Member
|
I made a small test project and did a private upload. The localized .xaml file looks OK. This looks more and more like a .Net issue, unless MSBuild needs to be invoked in a special way. |
|||||||||
|
Jaakko.Salmenius Administrator
|
Thank you for the sample. I reproduced the case. The localized XAML file contains the event but the compiled XAML inside the satellite assembly DLL does not. So the event is removed during the XAML compilation. I believe it is because the custom grid control. I try to figure out why and fix this. Jaakko |
|||||||||
|
Jaakko.Salmenius Administrator
|
I found the reason. Sisulizer added an incorrect assembly part into xml namespace part in a localized XAML file. This modification is needed only if the XAML belongs to a library assembly. If it belongs to an application assembly the modification is not needed and if it was the side effect was that events of component belonging to the modified namespace did not compile correctly. I fixed this in build 297. The new build will come out in few days. Jaakko |
|||||||||
|
bikedude Member
|
...and you even fixed my other issue as well! Goodie!  Would this be an opportune moment to ask about nameless components? We usually do not aware labels, panels and such with descriptive names (or names at all). The result is hundreds and hundreds of warnings when compiling using Sisulizer. I have also reported (albeit in the how-to forum) that running Sisulizer build seems to launch MSBuild in the debug configuration. At this point we prefer compiling using the Release configuration, but I see no way of controlling this. |
|||||||||
|
Jaakko.Salmenius Administrator
|
Sisulizer will use whatevet configure is set active in .csproj. However it makes sence to be able to choose the configure Sisulizer uses. I will implement this. Jaakko |
|||||||||
|
Jaakko.Salmenius Administrator
|
bikedude wrote: Would this be an opportune moment to ask about nameless components? We usually do not aware labels, panels and such with descriptive names (or names at all). The result is hundreds and hundreds of warnings when compiling using Sisulizer. We have noticed the same. This is why the new build only show 20 first missing names. All missing names after that are not written into the log. You can also turn off writing of unnamed controls into to log. Choose Tools | General -> Output Message. See this screenshot. Jaakko Attachment: Untitled.png (Downloaded 9 times) |
|||||||||
|
bikedude Member
|
Thanks very much Jaakko! We're looking forward to build 297. |
|||||||||
Sisulizer software localization tool - Three simple steps to localize