I'm working on a Xamarin Forms app, using a .NET Standard library. I've used the TranslateExtension as mentioned in the docs. I've added three resource files:
AppResources.resx (with matching code-behind file, auto-generated)
AppResources.nl.resx (Dutch translations)
AppResources.fr.resx (English tranlations)
When debugging the (UWP) app, I can't get the default culture (English) to be displayed. The following line returns null:
ResMgr.Value.GetString(Text, ci);
I've add some lines for debugging, and the other two languages do return the translated value:
ResMgr.Value.GetString(Text, new CultureInfo("nl")); // OK
ResMgr.Value.GetString(Text, new CultureInfo("fr")); // OK
ResMgr.Value.GetString(Text, new CultureInfo("en")); // returns null
What could possibly be the cause of this?
Things I've tried:
I've copy-pasted the key across all resource files, so I've ruled out misspelling the resource key.
I've tested "en-GB", "en-US", CultureInfo.InvariantCulture.
I've changed the default lanuage in the appxmanifest from en-US to en.
On UWP, watch that your resource name does not have a period in it..
You also likely need to tell the UWP project what its default language is. This can be done in the .csproj in the top <PropertyGroup> element (the one with no conditions) by adding <DefaultLanguage>en-US</DefaultLanguage> (using the proper culture for your scenario).
Don't forget to set the [assembly: NeutralResourcesLanguage("en-US")] as well for the assembly containing the resources - this is required for .NET Standard 2.0 and likely PCL.
Well it seems like you've got resx files for "nl" and "fr" (which you've said works fine) but you don't have one for "en". If you're trying to get the English value like that, I would think you need an "en" file the same way you do for "nl" and "fr"
I noticed that you told about NET Standard library
ResourceManager.GetString started giving null for new entries after moving from PCL to .NET Standard
I also observed that the file AppResources.Designer.cs disapeared from the Solution Explorer (but I don't know how, was still considered) and, in the VS res editon of AppResources.resx, Access Modifier was No Code Generation.
Here is what I did to fix that:
I double-clicked on AppResources.resx and set Access Modifier to Internal or Public
In .NET Standard you may no longer be able to see "View Code" from resx files; so, I righ-clicked on AppResources.resx-> Open With -> Source Code Editor and copy the new created entries to all the others *.fr (also *.nl in your case) ...
NOTE
In the context menu you should see Run Custom Tool. You may need to delete the old AppResources.Designer.cs and do "Run Custom Tool"
Don't forget to clear the solution (or olny UWP and the standard library), close VS, delete all .\bin and .\obj and restart VS. This to ensure your issue is fixed or not using the very very new generated true code :)
Related
This is a repeat of a question asked by someone else way back in 2008
, but it appears there was no real answer back then and this is still a problem.
I am writing a Visual Studio extension for files which look like XML but are not, and do not end in an xml extension. (I am using .csp) However Visual Studio continues to parse and highlight the file as if it was XML. This makes it difficult to get my own parsing and error processing to work.
Is there any way to programmatically tell visual studio that the file is not XML?
See also similar issue on MS forum
Since you have your own file extension, yes there is! It's simply a matter of editor priority. The XML-sniffer editor is only given a chance to claim the file if nobody else with higher priority does so first. It does so by registering the special * file extension as editable, then grabbing the file if it looks like XML -- but that * extension registration only has a priority of 33.
All you need to do is make sure your editor is registered properly with a higher priority. On your package, make sure you have the ProvideEditorExtension attribute. I suggest a priority of 50 to start with (higher numbers have higher priority).
[ProvideEditorExtension(typeof(CspEditorFactory), ".csp", 50)]
If you don't already have an editor factory, there's a good walkthrough on MSDN about how to create one.
Users of my application keep running into issues related to other applications declaring a different UTI for the same file extension as my application. I think I can best describe this with an example:
My application supports importing and exporting OPML files. For this to work I import the org.opm.opml UTI in my info.plist. This mostly works fine, but fails if an other application declares a different UTI for the opml file extension. For example com.redlex.opml or com.xwavesoft.cloudoutliner.opml.
Is there something I can do to work around this problem? Can I somehow tell launch services that my application accepts all files with an .opml extension?
I solved this issue with the following work around:
I removed the entire LSItemContentTypes entry from the list of CFBundleDocumentTypes
In my NSDocument subclass I use NSString's rangeOfString:: method to look for the #"opml" keyword in the typeName parameter.
This work around was confirmed by a user.
Cloud Outliner updated on the MAS today, and looking at the UTI for .opml files now, the com.xwavesoft.cloudoutliner.opml is now gone and com.redlex.opml is now in its place. Which would be uninteresting, except for the fact that OPML files now open in MindNode without a problem.
I can't find any release notes for Cloud Outliner other than "various fixes and improvements." but it would seem that something changed for the better. So: in my case - the simple answer was "update Cloud Outliner" but I'm not sure this solves the larger problem. I also have Mellel on my system (obviously, right?!) but this doesn't seem to be causing the same issue.
For those watching this thread - the issue presented as MindNode showing greyed-out icons for OPML files in its open dialog. Dragging OPML to the MindNode icon in the dock also produced no results.
Rob
On one computer 'A' (win vista 32 bit) if I run my program in debug mode all the richtextbox controls throw 'property cannot be set' errors.
I can go on to build the exe (without error ) and the full application OK
But when I then install and run the application on this computer or on computer 'B' (win xp) the same problems occur on both.
However if I run the exact same code in debug mode on computer 'B' there are no errors.
If I build and install the application on computer 'B' it works fine. If I then install this application on computer 'A' it also works fine.
When putting together the application for distribution, both computers use identical copies of richtx32.ocx (it, like the code, is checked out from the same repository).
If I check out previous copies of the code on computer'A' (that used to previously behave OK) they also now exhibit the same problems as the latest version of the code.
I don't have a clue what's going on, please help!
I'm seeing multiple references to the Property cannot be set message being resolved in the version of the Rich Text Control that is distributed in Visual Studio 6.0 Service Pack 4, and another Property cannot be set message fixed in SP5.
First and foremost, make sure that a minimum of SP5 is installed; I'd just go with SP6.
For reference, my Microsoft Rich Textbox Control 6.0 (SP6) is at C:\Windows\System32\RICHTX32.OCX, and is version 6.1.97.82.
I know you said that both machines have the same copy of the control installed; for the sake of completeness, you may want to double-check that the new control was registered after installation.
EDIT:
I exported the HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402} reg key:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}]
#="Microsoft Rich Textbox Control 6.0 (SP6)"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Control]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories\{0DE86A52-2BAA-11CF-A229-00AA003D7352}]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories\{0DE86A53-2BAA-11CF-A229-00AA003D7352}]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories\{0DE86A57-2BAA-11CF-A229-00AA003D7352}]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories\{40FC6ED4-2438-11CF-A3DB-080036F12502}]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories\{40FC6ED5-2438-11CF-A3DB-080036F12502}]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories\{7DD95802-9882-11CF-9FA9-00AA006C42C4}]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\InprocServer32]
#="C:\\Windows\\system32\\RICHTX32.OCX"
"ThreadingModel"="Apartment"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\MiscStatus]
#="0"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\MiscStatus\1]
#="131473"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\ProgID]
#="RICHTEXT.RichtextCtrl.1"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Programmable]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\ToolboxBitmap32]
#="C:\\Windows\\system32\\RICHTX32.OCX, 1"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\TypeLib]
#="{3B7C8863-D78F-101B-B9B5-04021C009402}"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Version]
#="1.2"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\VersionIndependentProgID]
#="RICHTEXT.RichtextCtrl"
A bad richtx32.oca file in the system32 directory seems to have been the cause of this.
Here's what an .oca file does:
Some of the properties of the control are provided by the framework
and some by the control itself. Programmatically, the properties from
the framework and the control all appear as properties of the control.
In order for these properties to appear, Visual Basic creates an
extended type library when the control is loaded into the toolbox.
Because the process of reading the control's type library and creating
the extended type library is time consuming, Visual Basic caches the
extended type library information into an OCA file.
If you delete the OCA file for a control Visual Basic recognized,
Visual Basic will recreate the .OCA file when you load a project
requiring the control. This recreation process comes with a time
penalty.
So it seems that having a bad .oca file in existence can mean that the properties of the control both in the IDE and in the compiled .exe will be affected.
The solution is to delete the .oca file in the system32 folder and then load the project again.
I'm in VS2010, in a new Word Add-In project. This is my first attempt at Word development using VSTO. The example I'm trying has this line:
Document vstoDoc = Globals.Factory.GetVstoObject(this.Application.ActiveDocument);
But when I add this line Visual Studio says it can't find "Factory". Indeed, it's not in Intellisense.
I've got references to:
Accessibility
Microsoft.Office.Interop.Word
Microsoft.Office.Tools.Common.v9.0
Microsoft.Office.Tools.v9.0
Microsoft.Office.Tools.Word.v9.0
Microsoft.VisualStudio.Tools.Applications.Runtime.v9.0
Office
and all the usual System references.
Where am I going wrong and why can't I get to "Factory"?
stdole
That example looks a bit weird to me. Never seen that sort of reference before.
Generally, with Vsto, you hook into EVENTS on, say, the main Word App object.
Then, from within the event, you usually are passed a reference to the particular DOC object that the event is occurring for (say, being opened or saved, etc). In that way, there shouldn't be any need for using the "globals" object or the "factory" object, whereever they might be.
What method is that code in? A little more context might help.
I think the recommended way of doing this is:
Globals.ThisAddin.Application.ActiveDocument
I've come across a strange behaviour in Visual Studio 2010.
When using embedded resources (files which are added to my C# project and for which the Build Action property is set to Embedded Resource), the files are included in the output assembly as binary data. Listing the resources is straightforward:
class Program
{
static void Main(string[] args)
{
string[] names = typeof (Program).Assembly.GetManifestResourceNames ();
foreach (var name in names)
{
System.Console.Out.WriteLine (name);
}
}
}
However, if the embedded resource file name ends with No.xxx (the extension is irrelevant), the file does not show up in the list. I cannot figure out any reason why Visual Studio 2010 would not include such a file. What did I miss?
Note: if I rename the embedded resource file in the solution explorer to something else, then everything works as expected.
Dan from the Microsoft Connect team has finally provided a valid explanation for this behaviour:
Hello, thanks for the report, this is actually working normally. The reason is that any resx files whose names match the pattern .VALIDCULTURE.resx are assumed to be specific to that culture. (This is how it has worked since VS2002, for better or worse)
In your case "no" is a valid culture (Norwegian, I guess) so the build process builds it into a satellite assembly. Here's what I got when I tried this. Note the "no" subfolder. If in your app you change your current culture to Norwegian, the resource load will load this set of resources.
So the problem has nothing to do with the word No itself, but rather with the fact that it is a valid, two-letter, culture name (in my case Norwegian). I checked, and indeed, there was a sub-folder in bin\Debug named No, containing a satellite assembly named Project.resources.dll in it.
Renaming the resource to end with .EN.xxx or .FR.xxx does, of course, exhibit the same behaviour.
As of MSBuild 16.9 you can include files like these by setting the WithCulture property to "false", as pointed out by #reduckted :-)
<EmbeddedResource Include="Resources.en.xml" WithCulture="false" />