Anders Melander

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).

It actually does but since the installation process is a bit confusing it's easy to miss. After the patch has been downloaded patch2-readme.txt is opened in notepad. The readme states: Yeah. How difficult would it have been to create a simple InnoSetup installer that automated the process completely? Including registering the fact that the patch had been installed: [HKEY_CURRENT_USER\Software\Embarcadero\BDS\21.0\InstalledUpdates] "Patch 1"="Patch1 for RAD Studio 10.4 (build 9797)" "Patch 2"="Patch2 for RAD Studio 10.4" Not impressed

Spotted a copy/paste bug in CompilersDecl.inc : const RAD_Rio = 32; RAD_10_3 = 33; RAD_Tokyo = 32; RAD_10_2 = 32 Of course it can't detect capabilities that were introduced after it was written but if you are using those then you must be already using a newer version of Delphi and thus be aware that you need to update the file. I guess it depends on how and what you use it for. Contrary to many other similar version include files this one appears to be forward compatible if you use the capability or XXX_UP symbols; For example even though it doesn't explicitly contain defines for Delphi 10.4 it will define the RAD_10_3_UP correctly on Delphi 10.3 and later: {$IF CompilerVersion >= 33} {$DEFINE RAD_10_3_UP} {$DEFINE RAD_RIO_UP} {$IFEND} Many libraries still use the practice of testing directly against the VERXXX defines, with no fallback, and thus break when a new version of Delphi is released, for no other reason that the shortsightedness of the authors. For example the following is from a well know charting library: {$IFDEF VER330} // RAD Studio XE v12.0 Rio (Carnival) 2018 (v 20.0) 32bit / 64bit / OSX / iOS 32-64 FMX / Android & C++ / Linux 64bit {$DEFINE D3} {$DEFINE D4} {$DEFINE D5} {$DEFINE D6} {$DEFINE D7} {$DEFINE D8} {$DEFINE D9} {$DEFINE D10} {$DEFINE D105} {$DEFINE D11} {$DEFINE D12} {$DEFINE D14} {$DEFINE D15} {$DEFINE D16} {$DEFINE D17} {$DEFINE D18} {$DEFINE D19} {$DEFINE D20} {$DEFINE D21} {$DEFINE D22} {$DEFINE D23} {$DEFINE D24} {$DEFINE D25} {$DEFINE D26} {$ENDIF}

I wouldn't say the future looks good when you're on life support. Naturally Cobol will die for good some day, when the systems using it are finally retired, but I'm pretty sure it will outlive for example JavaScript. Of course this doesn't mean that we should all drop what we're doing and learn Cobol instead. What I meant was that this statement: appears to assume that it's the popularity among "young people" that decides if a language thrives. There's some truth in that, but it's not the whole story. It's ultimately "the grown ups" that decides what tools to use to get the job done. That's why we don't have to rewrite EVERYTHING every few years when a new shiny toy appears.

So I'm guessing the asm it generates uses indexed addressing rather that indirect addressing. Right?

I'm curious; Why would you need that information?

My experience is that in some cases indexed access can be much faster than incrementing a pointer, so I guess "it depends". I'm afraid I can't remember any specific cases.

There are more developers than there are developer jobs. Some will have to take what they can get and use the tools that the job require. That's just the way the world works. Otherwise we would all be astronauts or firemen.

And the only one that knows what it does left ages ago... So it's not even possible to test if the new implementation works the same as the old because nobody knows exactly what or why the old did. Yup. That's what I deal with. Every. Single. Day.

That's just nonsense. I've written plenty of applications in Delphi that applied the MVC or MVP patterns. True, there's no wizard that can, clickety-click, write your template code for you, but it's really not that hard to do yourself once you've decided how to apply the pattern. It makes no sense to insist that one tool should be good for all problems or that Delphi should support all patterns. There are patterns that work well in Delphi but which doesn't fit for example JavaScript. That doesn't mean there's something wrong with JS. It just means you need to use a different pattern.

Nothing is stopping you from doing DI. Why do you need that "in the box"? As for MVVM I'm not convinced Delphi should do it at all. Not every pattern fits every language.

The book has many (good) points. One of them is that you can't naively solve a deadline problem by throwing more manpower at it; Time=Work/Resources is a meaningless equation. I assume this is what you allude to. However it also points out that you can solve a 2000 man-hour job in less that 2000 hours by allocating more manpower if the job can be split into separate, largely independent, tasks. I think that applies here.

Sure, but how is that relevant? Are you saying that they have enough resources or that more resources will lead to more problems? I'm sure that they have plenty of problems besides resources but surely their ability to solve them isn't improved by this shortage?

I acknowledge that this is a point of personal preference and I'm not challenging yours but FWIW of all the applications that I happen to have running right now only one does not navigate in tab order: SQL Server Management Studio The remaining all navigate in tab order. Firefox Excel Adobe Acrobat SourceTree ThunderBird Windows PowerShell ISE Delphi