Is there a reliable way to identify the filetype of a file across Windows platforms?
I've inherited a program which queries filetypes using the Shell32 GetDetailsOf function, which returns localized strings and causes an error if a non-english system is used (for example, on a german system GetDetailsOf(item,9) returns "Bild" instead of "Image").
Using the textual description of a filetype is not a reliable way of identifying particular types of file. As you've noticed the description strings change from language to language, but they can also change within the one language depending on the software the user has installed (as a made up example, a .jpg file might have the description "JPEG image" on one system, and "Adobe Photoshop Image" on another system if the user has installed software that claims the filetypes and changes the description).
Instead, your best way of identifying the filetype is to look at the file's extension (.jpg in our example). What you do with it then is up to you and depends on your application. You might just have a hard-coded list of extensions that you work with, or to be more generic you could look in the registry for the filetype's "perceived type":
HKEY_CLASSES_ROOT\.jpg\PerceivedType
To see if that value is set to "image", "audio", etc.
Related
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).
OK, the goal of this question is not strictly programming related but it is a question programmers can answer using programming tools, and programmers may find useful answers here. Bear with me.
I find changing the system language in Mac OS X a useful way to augment my learning of natural languages, eg French. However sometimes I find a menu item or dialog box in French that I can't understand and it's a bore to google the translation or change the system language back to English. But I know that the English translation is hidden away somewhere in the localisation file and maps somehow to the French phrase. So what I want to do is extract all the text from all the localisation files to develop a mapping of this phrase in English = that phrase in French so I can look it up easily.
I know that the localisation files are stored in something like Localizable.strings, lproj files and nib files but I can't make head or tail of how they are stored or how to work with them. I can program but I've never written anything in Xcode. All the information I can find is for Mac OS / iOS programmers to localise their software, not for hackers to extract already made localisation information.
How can I extract the foreign language information as plain text from Mac OS X system and 3rd party software localisation files? Thanks!
Strings files are easy. They're simply dictionaries serialized as property lists. The dictionary keys are used by the program to look up the given string for a particular localization. You can build a mapping from English to another language by loading both dictionaries, iterating over the keys, and using the value from the English dictionary as the key in your output and the value from the other language dictionary as the value in your output.
NIBs are harder. The build process "compiles" NIB files in to a form that's not conduicive to editing or parsing. If you have access to uncompiled NIB files then you can use ibtool --export-strings-file to dump a strings file, which you could then process as per above. If you don't then I think you may have a hard time.
Products like Picasa build databases that include metadata about files. Captions, keywords locations and the like.
Files have a number of attributes that is dependant on the file type and / or the application that produced the file.
My question is can I programmatically add a tag to a file and then use this tag to search for content.
Eg. Text files include Name, Type, Folder Path, Size, Date Created, Date Modified, Attributes, Owner, Computer. How can I add a "Keywords" attribute?
I am interested in a solution in C# but am primarily asking for help in understanding how this functionality could be implemented in Windows operating systems.
Thank you
You can try to use Extended Attributes, but they don't have a good API in Windows and in general are not widely used. There also exist Alternate Data Streams, but these are ,as the name suggests, data streams, and not attributes.
I use real basic for programming and I want to export some data to a word file that can be opened with "Open Office" or any other word processing software that can work on MAC OSX, any advise?
You didn't indicate what sort of data you're dealing with so I'll just assume text. Take a look at the StyledText class since it can read/write RTF which can be read by most word processors. http://docs.realsoftware.com/index.php/StyledText The drawback is that they only support a subset of RTF and don't support images.
If you have images and want a little more control I would recommend the Formatted Text Control from True North Software. http://www.truenorthsoftware.com/formattedtextcontrol/ It's a little pricey, but it's well worth it. True RTF support as well as a lot of XML options. You can create a very nice looking export via code.
You can always just create a plain old text file using the TextOutputStream which any word processor can open and read. http://docs.realsoftware.com/index.php/TextOutputStream
If you're on Windows, you can export directly to Word using the WordApplication class. http://docs.realsoftware.com/index.php/WordApplication That's not a cross-platform solution though.
TextOutputStream in itself only outputs characters, but if the text is rtfdata and you give it a fileending of .rtf it is interpreted as an RTF-file.
You can actually give the file a .doc, and it will be opended in Word as default (assuming word is default for .doc files)
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.