As is known, OST and PST files correspond to a single specification of binary Personal Folder File format. Some tools (in particular, PST.NET) allows to read OST file, just as if it were a PST file.
Can I use Redemption to work with the OST to a similar style?
No, Redemption is a wrapper around Extended MAPI, which does not expose anything to open an OST file outside of the profile used to create it.
Related
What are the best practices for where a cross-platform FireMonkey program should put INI files? Are INI files even the right approach?
For Android: in "shared storage"
For MacOS: in INI file
https://delphihaven.wordpress.com/2015/06/11/ccr-prefsinifile-on-github/
CCR.PrefsIniFile on GitHub by Chris Rolliston (he is on stackoverflow also: https://stackoverflow.com/users/2778930/chris-rolliston)
Just a small post to say the the native Preferences API wrappers for Android, iOS and OS X I published to Google Code a while back are now on GitHib:
https://github.com/chrisrolliston/CCR.PrefsIniFile
Both the Android and Apple versions should also now compile in XE8.
If you are searching for one location that will fit all platforms then I'm afraid you won't find it.
You see each platforms has its own preference on where the settings files are stored.
So you should read each platforms guidelines and make sure your program uses those locations.
Failing to do so and trying to save the settings in some different folder might fail completely as many platforms limit of which folders can your application access at all.
Now as for which format should you use? Should this be INI files or something else?
On windows it is completely up to you which format you use. You can use system registry, INI files (pretty common), XML files (becoming quite common lately) or even some custom formats like Typed files (binary files) that Delphi is capable of working with.
But this does not apply to all platforms. Some platforms might even limit you in which format you store your settings.
So again you should read the platform preferences on this matter and adapt.
In windows INI files became ubiquitous as a fast, easy to use method. But as they became larger they became much slower and it was difficult to implement structured storage. Hence the move away from INI files towards Registry/Registries. But that is not an option for cross platform, so there has been some drive back towards INI file structures, but depending on size this could still be slow. One of the more interesting approaches I have seen is in this skill sprint which (mis)uses JSON to create files equivalent to old INI files (and allows structure too). See here JSON - the new INI file. As to where, I think you need to read the recommendations for each target as the recommended location could be different for each.
Lazarus generates 3 file types for projects - *.lpr, *.lpi and *.lps. The first 2 files are necessary.
Should I keep *.lps files in version control system or should I include *.lps files in global ignore list?
IMO, no if you are not sharing the projects. Due to the FAQ, the lps files are "Lazarus Program Session - Personal data like cursor positions, source editor files, personal build modes. stored in XML".
This old, but as I am starting with use hg, I had the same question.
It seems best to NOT store .lps file in version control systems.
References:
http://wiki.freepascal.org/File_extensions
https://github.com/github/gitignore/blob/master/Global/Lazarus.gitignore
(Also wiki.freepascal.org/file_types and forum.lazarus.freepascal.org/index.php?topic=9298.0)
I have an old help file project, but the original project was lost in a hard drive crash. The original was created using HelpScribble, but now I've decompiled it into WinCHM. I have recreated the help file after decompiling the original compiled CHM file. However, to my knowledge, there is no way to identify the mappings to direct an application to certain Context ID's.
What I'm wondering is if there's a way to read the compiled CHM file and extract the Context ID of each topic in the help file? I would hate to have to iterate through individual numbers from 0 to 5,000 from what I've seen in the original software source. This is a large system, and has a corresponding large help file for every possible scenario in the software.
You can use the chmls tool from the FreePascal project. Invoke it like this:
chmls extractalias MyHelpFile.chm
The output are files named MyHelpFile.ali and MyHelpFile.h containing the IDs and targets of your aliases.
Is there any way to convert odt documents to doc or rtf on linux without openoffice or any library that relies on having openoffice installed ?
OpenOffice.org and its derivatives (LibreOffice, Symphony, etc) currently have one of the best converters between ODF and the Microsoft formats (besides the ODF support built into MS Office).
If those converters are not an option for you, you can choose between some alternatives: Foremost you might want to check out the KOffice project which also offers command line tools for file conversion:
KOffice - File Filters
Then there is another open source project with a free BSD license available on SourceForge:
OpenXML/ODF Translator
This project offers not only add-ins for Microsoft Office, but also a stand-alone command line version which also runs on Linux.
Then there would also be a different approach: You can automate Google Docs using command line tools:
googlecl: Command line tools for the Google Data APIs
Google Docs file conversion have internally been based on the OpenOffice.org file filters, but as far as I know they have been replaced by Aspose, a library for document formats.
Aspose is available in several versions, and as you have a Linux dependency you might want to check out their Java version.
Aspose.Words for Java
The library has its price, but you won't find another library that is not a full office suite with that quality.
If you don't want to use OpenOffice, Google Docs is your best bet. Cross-platform, web-based, and free, it takes about 2 minutes. You would upload the file, and check convert, then redownload as a doc or pdf (depends on what you want).
http://docs.google.com/
You could try this freeware (Docx2Rtf) and run it under WINE.
Checkout unoconv. It relies on OpenOffice.org its core, but it doesn't rely on any GUI packages. I assume this is what you want?
Use http://zamzar.com/ It has great support for all those formats. And is not reliant on any other installed program.
And of course, being a web page, it will work on any OS.
When developing in .Net, the framwork provides resx files as the standard way of storing localised resources (e.g. tranlsations of UI text).
I would like to know if there is a standard format for this in other development platforms (e.g. Java, RoR, etc.) and what that format is.
Thank you!
Please limit each answer to one development technology (e.g Java/C++/PHP etc.)
Java uses Properties, which are key-value pairs.
They can be serialized to the following two formats:
.properties
foo=bar
.XML
<entry key="foo">bar</entry>
Like Java, Adobe Flex also uses ResourceBundles that are serialized to .properties files
See http://www.freebsd.org/doc/en/books/developers-handbook/posix-nls.html
There is a standard, called POSIX, that applies to just about every other non-Windows operating system.
See http://www.php.net/manual/en/book.intl.php for the PHP-specific implementation of internationalization.
Large translation vendors accept the TMX file format for interchange of translation strings. Because they only have to deal with a standard xml file rather than strings embedded in controls, the amount of work these vendors have to do is reduced and so are their fees.
The standard way to do this on Linux is to use the gettext library, which stores its translations in .po files.
Cocoa applications (Mac/iPhone) are distributed as bundles (essentially: folders but with a known file-ish type). Inside a bundle, you can provide copies of strings files or other localized resources in a locale-specific subfolder. The Xcode provides IDE support for this, and the Cocoa frameworks provide many methods to conveniently fetch these resources.
See http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPInternational/Articles/InternatAndLocaliz.html for details.