Anders Melander

Useless, yes. That was kinda the point.

Are you projecting or did you mean that your behavior is out of my reach? If the former: [facepalm] If the latter: It wasn't critique but thanks for asking anyway. It was a request made in the hope of minimizing the amount of endless, pointless noise.

Instead of just continuing why don't you take a moment to reflect on why one would consider answering your questions a waste of time.

If one didn't know any better one might get the impression that DLLs and COM are inherently insecure, unstable and "dangerous". Yet all of Windows and every single application running on it are based on these technologies... Anyway. One alternative I forgot to mention is to implement custom functionality using a scripting system. I've successfully applied this approach in one of the applications I've worked on to replace a DLL-based plugin system.

From your description this looks like you need some kind of plug-in system. My personal preferences would be (in this order): In process COM server A run-time package DLL But if an external EXE can solve the problem for you, without any compromises, then that's clearly the easiest solution.

Would it be possible for you to restrict your comments to the technical details of the problem? You know nothing about the circumstances that caused this problem and it's not like it's a showstopper.

I liked it. Right up the point where they rewrote the client completely - in Java

I've not tried Fork but based on the screenshots it's an almost identical clone of SourceTree...

On Windows: Yes. Everywhere else: No. On Windows it works the exact same way as with VCL; Forms are stored in the EXE resources in DFM format and resourcestrings are stored as string resources. AFAIK for cross platform FMX you were supposed to use the TLang component for localization and invent your own system for managing and applying translations, but that system has been deprecated as well. Yes, you can load resource modules dynamically (they are just DLLs) but forms that have already been instantiated will not be affected by this. This means that if you create a form and switch to another language, then the form will stay in the original language. The post just above yours points to an example:

It seems that the Delphi SOAP framework is unable to handle SOAP responses that contain cookies with Expired=Fri, 31-dec-9999 23:59 GMT. Is this a known problem? The web service that sends this response in my case is the Microsoft Terminology Service. While there seem to be some disagreement about whether the year 9999 is out of range (some say 2038 is the maximum allowed value), the value so common that Delphi should be able to handle it. Under any circumstance the reason that Delphi fails to handle to value is clearly not by design - i.e. it's a bug. Here's what happens: The client (the Delphi application) sends a request to the SOAP server. The SOAP server responds. The response contains a cookie with an expiration time of "Fri, 31-dec-9999 23:59 GMT". The Delphi SOAP framework converts the expiration date to the local timezone (CET in my case). The result is 31-dec-10000 01:59. The value 31-dec-10000 is passed to SysUtils.EncodeDate but because the year value is outside the allowed TDateTime range (1-9999) this fails with an EConvertError exception: Invalid argument to date encode. I have not been able to find a way to work around the problem.

Done: https://quality.embarcadero.com/browse/RSP-30282

"Works As Expected" - What The Hell? Stupidity like that is high among the reasons why I no longer bother reporting bugs.

It isn't the tool that determines the result. It's the one wielding the tool.

Indeed. Here's the Delphi 1 version: destructor TComponent.Destroy; begin Destroying; DestroyComponents; if FOwner <> nil then FOwner.RemoveComponent(Self); DisposeStr(FName); end; It's been a while since I looked through the Delphi 1 sources. Classes.pas is only 3916 lines long. It's just sooo cute

I don't understand why you would get a compiler warning on that. I'm not getting it with Delphi 10.3.3 and since you are compiling from the source on bitbucket we should be using the exact same compiler options. This is really strange. You are getting an error when the project default source language is set. The origin of the default value is the GetUserDefaultLCID Win32 API function... but $2000 isn't a valid LCID value. My guess is that you are using a custom locale (see: Locale Names without LCIDs). I had hoped I wouldn't have to deal with those but I guess I weren't that lucky. You can probably work around the problem by modifying the default locale settings in the registry: HKEY_CURRENT_USER\Software\Melander\TranslationManager\System DefaultSourceLanguage=1033 DefaultTargetLanguage=1033 The above values sets them to "English (United States)". I will have to see if I can reproduce the problem here and then figure out how to deal with it. Stay tuned... There are several ways you can control what language to use at run time. Start by reading the Delphi help topic "Deploying Localized Applications". This explains how you can override the default language choice using the registry. BTM itself can be used as an example of how to load a specific resource module based on a user choice. Look in amTranslationManager.dpr in the function named LoadResourceModule and in amLocale.pas in the function named LoadNewResourceModule. There used to be a Delphi example project (RichEdit or something like it) that demonstrated how to localize an application and how to switch resource modules at run time but I don't think it's been included for a while.

Thanks. My guess is that the DRC-file was out of sync with the EXE file at the time you created the project. You should compile the application again and make sure you generate the drc file (see below). Then you can Update the translation project and the resourcestring names and values should now match. Unfortunately the existing resourcestring translations will be marked obsolete since the source name/value pairs have all changed. The only way to recover the resourcestrings you have already translated is to add the translated resourcestring values to the Translation Memory before the update and then use the Translation Memory to apply the translations again after the update. The DRC-file contains the mapping between resourcestring names and string resource IDs. It is created by the Delphi compiler if the "Output resourcestring .drc file" linker option is enabled. Since this isn't obvious I have just updated the DRC-file prompt to state this fact: I have also added a check to display a warning if the timestamp of the EXE and DRC-files are too far apart (>10 seconds), indicating that they are probably out of sync:

Works fine for me on Window 10.

The revision you used should be Okay. I'm curious about where you got that warning. There should be no hints or warnings when compiling and no where in the source is there a #$1000. Anyhow, if you're up for it you can try downloading the precompiled application instead and see if you can reproduce the problem with that: http://melander.dk/download/amTranslationManagerInstall-1.1.7465.55536.exe I committed a change yesterday that replaces the empty DLL stub I use to generate the resource modules with a smaller file. I haven't tested the new or the previous version of the DLL stub on Windows 10 though, so I will do that right now. Windows doesn't use the file type for anything. It's the file header (the PE header) that identifies the file as a DLL. The "DLL" file type is just a convention - and the default file type for DLLs. You can call them anything. For example Control Panel applets (*.cpl) and Screen Savers (*.scr) are also just DLLs. The resource modules are loaded by the Delphi RTL using the LoadLibraryEx API function. See LoadResourceModule() in the system.pas unit. When your application starts the RTL by default looks for a file with the same name as the application and an extension that matches the current locale. If that file is found it is loaded with LoadResourceModule. See GetResourceModuleName() for the (broken) algorithm that calculates the name of the resource module file. It's pretty obfuscated due to all the conditional defines.

You can create that from within the IDE: Component | Import Component | Import a Type Library

The /regserver should register the type library embedded in the application (via TComServer.UpdateRegistry). Didn't it do that?

...and you can juggle chainsaws.

Yes, the registration is stored in different places in the registry but that's really a Windows implementation detail. For out-of-process COM servers a 32-bit client have no problems connecting to a 64-bit server and vice versa. Here's a nice summary: https://mariusbancila.ro/blog/2010/11/04/32-bit-and-64-bit-com-servers/ For in-process servers (i.e. basically just a DLL) the bitness must match. https://en.wikipedia.org/wiki/Law_of_the_instrument

Don't use regsvr32 - that's for in-process servers. You can't use task manager to verify that you server is being executed (it terminates as soon as it finishes registering) but you should be able to verify if your server has been registered by looking in the registry. If you don't know where to look then you need to read some docs on msdn. COM is a nightmare if you don't understand how it works. Anyhow, try this: Run Delphi as as administrator. Enter /regserver in Run|Parameters Place a breakpoint in TComServer.Initialize (in the System.Win.ComServ unit). Run your server in the debugger. You should now be able to trace through TComServer.UpdateRegistry and verify that it ends up registering your type library and your COM classes (probably via TComObjectFactory.UpdateRegistry).

I'm assuming you have compiled amTranslationManager.exe yourself since you seem to be running it in the debugger. What source code revision are you building from (git hash or timestamp)? What version of Delphi are you using? What version of Windows are you using? The helloworld.nld filename is correct. The file is supposed to be a DLL that only contain the translated resources (i.e. no code). The NLD file type is just the ISO 639-2 language code for Dutch (Netherlands).