How to SHSetLocalizedName with a hard coded string? - windows

I want to localize a shortcut and have come across this API SHSetLocalizedName() which takes a path to an executable and a resource ID. However, I want to use a string instead. It looks like it just writes to desktop.ini:
[LocalizedFileNames]
Test.lnk=#program.exe,-101
I played with it manually and I can just do this:
[LocalizedFileNames]
Test.lnk=Localized Name of Test Shortcut
Does anyone know a programmatic way of doing this? I really don't want to write to desktop.ini myself.
Thanks.

A hard coded string is the opposite of localization!
The point of SHSetLocalizedName is to have various parts of the start menu and some special folders (My documents etc.) display in a language that matches the users current UI language. To do this the string has to be a resource in a PE file so that the magic of multiple versions of a resource in different languages can work.
If you always want a specific name you can just rename the file. If you can't do that (you don't have write access or you are trying to trick the user) then perhaps this is not something you should programmatically be doing?
SHGetSetFolderCustomSettings knows how to change some values in desktop.ini but this string is not one of them. I believe using WritePrivateProfileString is the only solution...

Related

Rules for file extensions?

Are there any rules for file extensions? For example, I wrote some code which reads and writes a byte pattern that is only understood by that specific programm. I'm assuming my anti virus programm won't be too happy if I give it the name "pleasetrustme.exe"... Is it gerally allowed to use those extensions? And what about the lesser known ones, like ".arw"?
You can use any file extension you want (or none at all). Using standard extensions that reflect the actual type of the file just makes things more convenient. On Windows, file extensions control stuff like how the files are displayed in Windows Explorer and what happens when you double click on it.
I wrote some code which reads and writes a byte pattern that is only
understood by that specific programm.
A file extension is only an indication of what type of data will be inside, never a guarantee that certain data formatted in a specific way will be inside the file.
For your own specific data structure it is of course always best to choose an extension that is not already in use for other file formats (or use a general extension like .dat or .bin maybe). This also has the advantage of being able to use an own icon without it being overwritten by other software using the same extension - or the other way around.
But maybe even more important when creating a custom (binary?) file format, is to provide a magic number as the first bytes of that file, maybe followed by a file header structure containing a version number etc. That way your own software can first check the header data to make sure it's the right type and version (for example: anyone could rename any file type to your extension, so your program needs to have a way to do some checks inside the file before reading the remaining data).

How to refactor localizable.strings?

I'm rather new to Objective C (I'm using Xcode, if it's relevant). I tried to find an answer to this, but couldn't find anywhere...
My question is: Is there a possible way to change a variable name in the Localizable.strings file, so that it would change in the entire app?
I do not want to use the "search and replace" option, since if there are more instances of that string which are not this variable's name, they would change too (which is something I'm interested to avoid).
Basically I'm interested in finding the parallel function to java's "refactor", while using eclipse. Thanks to all helpers!
No, not possible to do it automatically. At least not in XCode - maybe AppCode can offer something, but I doubt it. Localizable.strings is not code - it's a text file which contains key-value pairs. Thus there are no real references to keys in your code, just same string values in your code and in the file.

Where to keep long string to bind into textblock?

This is so stupid that I cannot find it anywhere!
Until now I used texblock with few words of text, so I just declared it as a property in text="my_short_text". Now I have several lines of text that I find really weird to put in the xaml.. I've tried to create a new text.txt resource file and tried to bind to the texblock with Path or Source but it didn't work! Where I have to keep my resourcese?
I know this is a noob question but I'm pretty new with WP7 and C#!
The use of an application resource file is where you'd want to store strings, ints, etc...
For WP7, there is an article on MSDN: How to: Build a Localized Application for Windows Phone. Scroll down to the section titled Replacing hard-coded strings with strings in a resource file.
There are examples of using resources all through the MSDN article; even though it's for localization, you can use the same concepts.

Insert a hyperlink to another file (Word) into Visual Studio code file

I am currently developing some functionality that implements some complex calculations. The calculations themselves are explained and defined in Word documents.
What I would like to do is create a hyperlink in each code file that references the assocciated Word document - just as you can in Word itself. Ideally this link would be placed in or near the XML comments for each class.
The files reside on a network share and there are no permissions to worry about.
So far I have the following but it always comes up with a file not found error.
file:///\\165.195.209.3\engdisk1\My Tool\Calculations\111-07 MyToolCalcOne.docx
I've worked out the problem is due to the spaces in the folder and filenames.
My Tool
111-07 MyToolCalcOne.docx
I tried replacing the spaces with %20, thus:
file:///\\165.195.209.3\engdisk1\My%20Tool\Calculations\111-07%20MyToolCalcOne.docx
but with no success.
So the question is; what can I use in place of the spaces?
Or, is there a better way?
One way that works beautifully is to write your own URL handler. It's absolutely trivial to do, but so very powerful and useful.
A registry key can be set to make the OS execute a program of your choice when the registered URL is launched, with the URL text being passed in as a command-line argument. It just takes a few trivial lines of code to will parse the URL in any way you see fit in order to locate and launch the documentation.
The advantages of this:
You can use a much more compact and readable form, e.g. mydocs://MyToolCalcOne.docx
A simplified format means no trouble trying to encode tricky file paths
Your program can search anywhere you like for the file, making the document storage totally portable and relocatable (e.g. you could move your docs into source control or onto a website and just tweak your URL handler to locate the files)
Your URL is unique, so you can differentiate files, web URLs, and documentation URLs
You can register many URLs, so can use different ones for specs, designs, API documentation, etc.
You have complete control over how the document is presented (does it launch Word, an Internet Explorer, or a custom viewer to display the docs, for example?)
I would advise against using spaces in filenames and URLs - spaces have never worked properly under Windows, and always cause problems (or require ugliness like %20) sooner or later. The easiest and cleanest solution is simply to remove the spaces or replace them with something like underscores, dashes or periods.

What are the best practices for building multi-lingual applications on win32?

I have to build a GUI application on Windows Mobile, and would like it to be able user to choose the language she wants, or application to choose the language automatically. I consider using multiple dlls containing just required resources.
1) What is the preferred (default?) way to get the application choose the proper resource language automatically, without user intervention? Any samples?
2) What are my options to allow user / application control what language should it display?
3) If possible, how do I create a dll that would contain multiple language resources and then dynamically choose the language?
For #1, you can use the GetSystemDefaultLangID function to get the language identifier for the machine.
For #2, you could list languages you support and when the user selects one, write the selection into a text file or registry (is there a registry on Windows Mobile?). On startup, use the function in #1 only if there is no selection in the file or registry.
For #3, the way we do it is to have one resource DLL per language, each of which contains the same resource IDs. Once you figure out the language, load the DLL for that language and the rest just works.
Re 1: The previous GetSystemDefuaultLangID suggestion is a good one.
Re 2: You can ask as a first step in your installation. Or you can package different installers for each language.
Re 3:
In theory the DLL method mentioned above sounds great, however in practice it didn't work very well at all for me personally.
A better method is to surround all of the strings in your program with either: Localize or NoLocalize.
MessageBox(Localize("Hello"), Localize("Title"), MB_OK);
RegOpenKey(NoLocalize("\\SOFTWARE\\RegKey"), ...);
Localize is just a function that converts your english text to a the selected language. NoLocalize does nothing.
You want to surround your strings with these values though because you can build a couple of useful scripts in your scripting language of choice.
1) A script that searches for all the Localize(" prefixes and outputs a .ini file with english=otherlangauge name value pairs. If the output .ini file already contains a mapping you don't add it again. You never re-create the ini file completely, your script just adds the missing ones each time you run your script.
2) A script that searches all the strings and makes sure they are surrounded by either Localize(" or NoLocalize(". If not it tells you which strings you still need to localize.
The reason #2 is important is because you need to make sure all of your strings are actually consciously marked as needing localization or not. Otherwise it is absolutely impossible to make sure you have proper localization.
The reason for #1 instead of loading from a DLL is because it takes no work to maintain this solution and you can add new strings that need to be translated on the fly.
You ship the ini files that are output with your program. You also give these ini files to your translators so they can convert the english=otherlanguage pairs. When they send it back to you, you simply replace your checked in .ini file with the one given by your translator. Running your script as mentioned in #1 will re-add any missing translations if any were done while the translator was translating.

Resources