Suppose I call System::Diagnostics::FileVersionInfo::GetVersionInfo("foo") on file foo.exe, except that foo.exe has multiple version infos, one that is Japanese, one that is English (US), and another that is Neutral.
How do I know which version info my program will retrieve? Is there a specific behavior that .NET uses to choose the version info that has the right locale? Is this behavior dependent on the system locale or the locale of the program the method is being called from?
I've pinpointed it to a Windows API function called GetFileVersionInfo:
Currently, it is querying fixed version from language neutral file
(exe/dll) and the non-fixed part from mui file, merges them and
returns to the user. If the given binary does not have a mui file then
behavior is as in previous version.
I'm not sure what the "previous version" is referring to, but I am assuming that the file description and such are also taken from the neutral version info.
Related
I'm writing my first KDE plasmoid using QML. The hello world example uses a metadata.desktop file, while this KDE Plasmoid tutorial talks about a metadata.json instead and says that the metadata.desktop is 'discouraged' now and a desktop file should be converted to json using desktoptojson.
However, when I browse the globally installed plasmoids under /usr/share/plasma/plasmoids/ they all have both the metadata.desktop and metadata.json.
First question: So, what is really recommended? Just the metadata.json? Or both?
And, I wasn't able to find the desktoptojson tool. I'm using Linux Mint and the ./kdesrc-build --initial-setup for debian based systems says that it's "This is woefully incomplete and not very useful" ... I read that "most users of this [i.e. desktoptojson] utility will use the CMake macro kservice_desktop_to_json as part of the process of building a plugin.". However, I haven't found the documentation yet how to use this.
Second question: In case one should maintain both files (for whatever reason), should I use desktoptojson to keep them in sync? And if yes, how?
Thanks!
First question: So, what is really recommended? Just the metadata.json? Or both?
In the current source code, most stock KDE applets such as the task manager use metadata.json's and have dropped the metadata.desktop's. It may be that the desktop files you have locally are left over from old versions, the new format was installed but the old one was never deleted.
Second question: In case one should maintain both files (for whatever reason), should I use desktoptojson to keep them in sync? And if yes, how?
The man page on Arch you linked to has all the information. The tool is part of the package kservice. Find the equivalent in the repository for your distribution. Then, to use it
as part of a CMake macro:
add_library(myplugin MODULE ${myplugin_SRCS})
kservice_desktop_to_json(myplugin myplugin.desktop)
directly on the command-line:
desktoptojson -i myplugin.desktop -o myplugin.json
When I register a .NET assembly enabled for COM interop using the REGASM tool, the tool creates a separate registry key for each component version. For example, I get:
HKEY_CLASSES_ROOT\CLSID\{myCLSID}\InprocServer32\1.0.0.0
HKEY_CLASSES_ROOT\CLSID\{myCLSID}\InprocServer32\1.1.0.0
etc.
Each of these registry contains roughly the same structure values as it is under HKEY_CLASSES_ROOT\CLSID{}\InprocServer32, except that the entries point to different locations, depending on the component version. The HKEY_CLASSES_ROOT\CLSID{myCLSID}\InprocServer32 apparently contains the latest registered version, and that's what COM consumers will normally use, of course, and they ignore the rest.
This structure apparently allows different versions of the component coexist on the same computer (I know it is against the originally specified COM rules). I would like to use it, but I could not find any documentation about it anywhere in the Microsoft documentation or Googling for it. Does anybody know? I am looking for something like CoCreateInstance/CoCreateInstanceEx with the version specifier.
Thanks
I am automating a process and I use GPG2.exe for it.
Because I need to parse console output - potentially from different systems I need to set the languge to a controlled value.
I am following the Instructions from the manual which states that
LANGUAGE
Apart from its use by GNU, it is used in the W32 version to override the
language selection done through the Registry. If used and set to a valid and
available language name (langid), the file with the translation is loaded from
gpgdir/gnupg.nls/langid.mo. Here gpgdir is the directory out of which the
gpg binary has been loaded. If it can’t be loaded the Registry is tried and as
last resort the native Windows locale system is used.
I found a thread from 2011 that goes into a bit more detail regarding this problem, but this may actaully concern a different version.
I created a batch file for manual testing.
#echo off
REM C is meant to display untranslated messages according to one internet source
set LANGUAGE="C"
call "C:\Program Files (x86)\GNU\GnuPG\gpg2.exe" --version
pause
I ecpext the output to be english but it is still german.
The manual states something about there beegin a "gnupg.nls" folder somewhere.
I was not able to locate this folder, which makes me wonder where german is loaded from.
Is there an error in the man page?
The pdf Version of the man page shows the same content as the man page that came with the installation.
Can someone shed some light on this?
I had the same problem that the output was in Swedish though I wanted it in English. The Windows display language was set to English, and I also tried setting environment variables but what solved it for me was to remove the Swedish translation for gnupg file found here:
C:\Program Files (x86)\gnupg\share\locale
After having removed the "sv" directory all output was in English.
The language directory can be pulled from the registry or I suppose it can also have a fixed path since I can not find the information in my registry.
On my testsysten the path is 'C:\Program Files (x86)\GNU\GnuPG\share\locale'.
This path contains folders for each language - not all of them contain translation files for gpg2 as far as I can tell.
The environment variable for language is not LANGUAGE but LANG. Setting it to C causes gpg2 to default to english.
I successfully tested the following call.
#echo off
set LANG=C
call "C:\Program Files (x86)\GNU\GnuPG\gpg2.exe" --version
User bignose is still correct when he states that I should use the API instead but within my current restrictions I do not see a straight forward way to do so.
This isn't a programming question, as noted in the votes to close.
To answer a different question that could be asked from a programming perspective: Don't parse inherently-changeable console output, when there is a well-defined library API for the same functionality.
Some valid IDL files, build as IDL Projects and install but some or all of their contents do not appear in the SCA Explorer/Target SDR/IDL Repository. I believe that the IDL parser used to build the tree in the IDL Repository is different from that used by the omniORB idl2cpp (omniidl) during building and it rejects some valid IDL. The cases I have found all use a value of a const previously defined. e.g.,
const Algorithm ALG_NONE = 0
const Algorithm ALG_LPC = ALG_NONE + 3
The second line can occur in the same file or in a file that includes the file containing the first line.
The file containing the first line is accepted if the second line is not in the same file, but the file containing the second line is rejected and none of its contents appear in the IDL Repository tree. It appears that it rejects a const appearing as a value on the right side of an assignment statement. These files however are valid and are accepted as valid by omniidl. But they cannot be used in RedHawk because they cannot be selected for a component interface.
I am not very familiar with RedHawk IDE sources or Eclipse plugins and so have not been able to find where the syntax for the parser is specified. I see "eclipsecorba" appearing in plugin lists so I assume that RedHawk is using the Eclipse CORBA Plugin (aka ECP) and that its parser is the one being used to build the tree. So I suspect that the parser error is in that package rather than in code added by RedHawk.
Can anyone confirm this and suggest where I might look in the ECP code for this? Should I report this as a ECP bug to the ECP group on SourceForge? I am not sure how active it is since it appears that the latest version is from 2008.
This seems to be a bug in the IDL editor, the IDL you have is legal. Would recommend you to report this to ECP but given the long inactivity of that project probably it will not fixed soon. I do know that one of our Remedy IT engineers has created a more modern IDL editor for Eclipse but due to lack of funding this work is not available publicly.
My Cocoa project is localized in Italian (my language) and English language.
If I run it, i see everything in Italian (of course, my OS is italian!).
How can I run it to test the English localization without changing the OS language?
In the old times, Leopard and before, the get info window in Finder would let
you choose the available languages. So it was a matter of deselecting the
language that you don't want to use and it would "default" to the other.
These days you can use an utility like this one. I'd love to know what it
does behind the scenes though.
I finally found a nice solution in the cocoa-dev mailing list archives.
Apparently, you can change the default domain within the arguments passed to
your executable, and this causes the global preference to be overwritten. It
can be achieved with the -AppleLanguages flag, pass a list of the languages
in the preferred order:
~/apath/AppName.app/Contents/MacOS/AppName -AppleLanguages "(Italian, English)"
Run this from your terminal and it should give a different precedence for the
language. Notice you can also specify a single element list "(Italian)"
—makes more sense for testing purposes.
To do it within Xcode and avoid the terminal, go to the menu Product > Edit
Scheme… . Then, in your run configuration switch to the Arguments tab and
create a new one to be passed on launch. Add -AppleLanguages "(Japanese)"
text to it. Something similar to this:
Assuming you have a file that holds all the strings, swap the names of the files. Or, if you've got a it.lproj and en.lproj group in your project, just move your InfoPlist.strings (or whatever you named it) into the other group and vice versa.