I am evaluating gnugettext for Delphi XE2. All seems to be OK except that it seems that we don't have translation directory(ies) choice : it is always "\locale\Lc_MESSAGES\".
As I need to share translation for some exe in the same application it's not very convenient. I looked in the sources and see :
BaseDirectory:=ExtractFilePath(ExecutableFilename);
OK, I may change the source but I don't like it.
Any elegant idea ?
You can use the provided bindtextdomain function to change the directory where your application looks for the dictionary files. The first parameter will normally be the string 'default', and the second parameter is the directory to go to. The actual dictionary files will still need to be in a subfolder of the specified directory (using the same \locale\LC_MESSAGES\ pattern), but this at least gives a convenient way of sharing translations across multiple programs.
Related
I have a question, I am using FSharp.Configuration (https://fsprojects.github.io/FSharp.Configuration/YamlConfigProvider.html) library to read configuration file in my project using Yaml provider. Well it all works well and good but I started to wonder how to detect if there is no configuration file, if some no good user deleted this file.
I could replace it with some default hard coded config. But documentarian says none about it.
Anyone maybe solved this problem?
All values from the config file passed to the TP at compile time are stored as default values (right in the generated code), except lists of compound types, which will always be empty due to the TP restriction. So, when you instantiate a TP at runtime, it's "filled" with the default values already. If you need to fill it with different values, you can load a file, a string, or set individual properties in code. Maybe it would be a good idea to add an ability to load config from resources, but I'm not sure it's an idiomatic way in .NET world (in contrast with, say, Scala).
Normally, when you read about localization resources (RESW) for a universal application you are asked to create a single resource file for each language with Resource.resw name or in a most advanced scenario they advice to create two or three like Errors.resw, Messages.resw and that's about it. We have completely different approach (let's don't argue upon this, for us it proved to be good). We have a separate RESW file matching a CS file where we have resources which needs to be localized. We mimic the same folder structure in the Resource(language)\ folders as we have in the source code. The whole pattern came from Windows Phone Silverlight application and worked perfect with RESX. I have concerns regarding this in universal app. The problem is that even though a RESW file is located deep in the directory structure like
Res\it\Controls\Browser\MusicDetails.resw
it is referred as if it is located in the language root at Res\it. For example to get this resource in the code the code would look like this
resourceLoader = ResourceLoader.GetForCurrentView(currentAssemblyName + "/MusicDetails");
resourceLoader.GetString("Title");
Getting back to windows phone silverlight app the path in a similar case looks like "\Controls\Browser\MusicDetails.resw" and it is definitely not an issue for the RESX resources.
Is there something we are missing or it is a hard RESW limitation and all RESW files no matter where they are located in the directory structure are treated as if they are at the root of the language directory? I foresee a problem if in the future we have exactly the same RESW name in different directory branches. How to work around this?
I think is not possible to do that, I tried to do something like you before with Windows 8.1 and it was not possible now with UWP is the same we need follow the guidelines here
https://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh965328.aspx
I did this steps and it works like a charm.
UWP apps have restrictions they are not like traditional apps (Win32 apps)
If we want to store critical information, like passwords and server addresses, inside the executable file generated by the Delphi compiler, how can we do that, without knowing the final executable size and binary structure, like at the end of the file for example?
Side note:
The text to be stored is already encrypted; and in some computers the windows don't give access to write in the registry, specially when the user is not administrator, and there are hacks to monitor registry changes and the smart user can find the new windows registry entry.
Comment
Why this question was down voted? This is achievable! Doesn't meter if not interesting for most people.
I think about the bios and other firmware upgradeable, like satelite tv signal decoders that update themselves. How is that possible?
You can use an .rc file to put your data into a custom resource inside the final .exe file. You can then access that resource at run-time, such as with a TResourceStream, and decrypt and use its content as needed. However, you cannot write new data into the resource while the .exe is running, as the file is locked by the OS. If you need to write new settings, and do not have write access to the Registry, you will have to use a separate file instead. Windows has special folders set aside that users have write access to within their user profiles.
Create a string table resource is one way.
Create a text file. say secretstuff.rc (has to have .rc extension)
with something like this in it.
STRINGTABLE
{
1,"This is my encrypted password in say Base64"
}
Compile it to a .res file with BRCC32.
Include it in the relevant code with a compiler directive
{$R secretstuff.res}
After that you access with TResourceStream.
If you want to manage it a bit better might be wise to stuff them in a dll instead of an exe, then you can update things by delivering a new version of the dll.
There's an example with a it more detail, another purpose but same principle here
For years I've put my application data files in c:\MyCompany\MyDataFileFolder\App where 'App' is my application name. I made this choice in the early days of Wild-West-Windows when Microsoft seemed to keep changing its own mind (My Documents, Documents, Program Data etc). As I've learnt more about how to do things correctly, and as Windows has now 'settled down' and is more picky about permissions I'd like to move my files. Users have got used to where they are though, and what I'd really like to do is to implement something like Windows does with 'special folders' where there are several synonymous names, thus in my legacy folder I'd like to put something in (or change a folder to) an alias for the real location which will now be something descended from Program Data. This way, the files are in a good place with the correct permissions and if we run a utility expecting or modifying files in the 'old' place this gets changed transparently to the 'new' place (thus a simple shortcut wont work).
Is this possible? Is there are recognised technique for this? I'm using Delphi XE2.
What you are looking for is either a Symbolic Link or a Reparse Point.
I have written several applications in Delphi which use Word automation. The programs all use templates which are stored in a directory. In pre-2010 versions of Word, one would define the location of the templates in tools|options|file locations; the programs would pass the name of the template and Word would know where to find it.
My client has now moved to Office 2010, and as a result, Word cannot find the template when started by my programs. I haven't been able to find a similar dialog box in Word in which I can define the default directory for templates. How does one define such a directory?
Click File | Options | Advanced | File Locations and you get the same dialog as in older verions
Instead of forcing your user to configure Word to define the location of templates, you might prefer to invoke word using /t switch.
/ttemplatename starts Word with a new document based on a template other than the Normal template.
>"%programfiles%\Microsoft Office\Office14\winword.exe" /t"c:\MYTEMPLATES\mytemplate.dotx"
Can't you just specify the full path when creating a new document? Why rely on a settings that possibly can even be changed by the user? Put your templates in your own folder and specify the full path.
Word's paths configuration are stored
You can get the USER template folder via
Word.Application.Options.DefaultFilePath(WdDefaultFilePath.wdUserTemplatesPath)
(there are others options for that property too).
As far as I can tell, the template loading rules haven't changed from 2007 to 2010.
Generally speaking, if your add in needs to load a template, you should specify the FULL path and file name to the template, but you can get the typical user path via the above.
On the other hand, if you install the template into WORD\STARTUP, word will automatically load it. that may not be what you need/want, though.
Finally, if your template doesn't/shouldn't change, it might be better to leave it in your PROGRAM FILES\appname folder and load it from there.
Generally speaking, +requiring+ users to change the FILE LOCATIONS in word (or changing it programmatically) is a bad idea, just because so many people wouldn't have a clue, and those that do definitely DO NOT want addins changing those settings automatically!