Problem:

After upgrading from EurekaLog 7.12.0.5 to EurekaLog 7.14.0.0, localized resourcestrings are no longer correctly loaded when compiling VCL application with EurekaLog. Localized forms are loaded correctly, but resourcestrings remain in their original values or simply empty. When compiling without EurekaLog, everything works as expected.

Reason:

1. When you add/remove EurekaLog from your project: list of resourcestrings in your project changes, because EurekaLog also has resourcestrings. The same thing may happen when you change EurekaLog version, as the different EurekaLog's versions may have different resourcestrings.

Changing list of resourcestrings can cause changing IDs of resourcestrings.

For example, a particular resourcestring rsCaption may have the ID of 1 in your project. When you add, remove or change EurekaLog in your project, the rsCaption may get ID of 99. However, your localization project still contain localization for the ID 1 (not 99). Which means your application will fail to load translation for the ID 99 from your localization project, as your localization project does not have translation for ID 99; it has translation for ID 1. This will cause the rsCaption to become empty, remain unchanged, or receive an incorrect value.

2. Alternative reason could be you are not using ITE to auto-load the resource DLL to match the UI language. Rather you wrote a code to manually force-loading a specific resource DLL by altering the .ResInstance property of a module. However, the .ResInstance property is not used directly to load resourcestrings. Rather it is stored (on demand) into internal hashed list of resource modules. 

Solution:

1. You have to update your localization projects. Use the "Project" / "Languages" / "Update Localized Projects" IDE's menu item, then do "Project" / "Build All Projects". This should sync your resourcestrings IDs.

Just make sure you deploy new versions of your localization binaries.

2. If you are dynamically changing resource DLL's, the SysUtils module provides the ResStringCleanupCache function to purge the internal cache of loaded resource strings. Which will cause the new (updated) .ResInstance property to be stored into the hashed list. EurekaLog also has a similar cache for resource strings, which also has to be purged. There is a similar ResStringCleanupCache function in the EResourceStrings unit. In other words, your code should look something like this:

uses
  ...
  SysUtils,
  {$IFDEF EUREKALOG}EResourceStrings,{$ENDIF}
  ...


begin
  ...
  
  // Load new resource module:
  CurModule.ResInstance := LoadLibraryEx(PChar(ResModuleName), 0, LOAD_LIBRARY_AS_DATAFILE);


  // Cleanup internal cache of loaded resource strings:
  ResStringCleanupCache; // will call the EResourceStrings.ResStringCleanupCache or SysUtils.ResStringCleanupCache 
  
  ...