- Forum
- Windows Programming
- Problem with satellite DLLs and resource
Problem with satellite DLLs and resource caching
Hi All,
I am trying to use satellite DLLs to allow an MFC application to support multiple localizations. Currently the application is in English, and we would like it to support Chinese. I followed the approach suggested at
https://msdn.microsoft.com/en-us/library/8fkteez0.aspx?f=255&MSPPError=-2147217396
to create an English version of the resources. The resources were removed from the resource file used for the application and added to another resource file that was built to make the satellite DLL. Following the instructions at the above link, the DLL was named <app>ENU.dll, where <app> is the application name. This part worked perfectly. Without the DLL present there were errors related to missing resources, and when I added it, everything worked as it did when the resources were in the application itself.
Then I tried again with the resources converted to Chinese. I left the language IDs as English although the text was all Chinese, and the file itself was Unicode. (Pretend this is language learning software where people who know English are learning Chinese.) Now the menus are English and the dialogs and tips for the toolbars are Chinese. I do not know where the English information is coming from. I used the resource API to list the resources in the DLL and the application, and the text that is displayed in the menus and tips does not appear in either of these.
When I run the program as an administrator, everything is Chinese. When I run as any other user, again everything is Chinese. Finally, when I rename the application and the resource DLL (say from x.exe and xENU.dll to y.exe and yENU.dll), there is Chinese everywhere regardless of who runs the program.
It appears that somehow the menu information is being cached and associated with the application name and user name. I would appreciate some information on what exactly is going on and how to resolve the problem with mixed-language resources. Thanks for any assistance.
Jim
I am trying to use satellite DLLs to allow an MFC application to support multiple localizations. Currently the application is in English, and we would like it to support Chinese. I followed the approach suggested at
https://msdn.microsoft.com/en-us/library/8fkteez0.aspx?f=255&MSPPError=-2147217396
to create an English version of the resources. The resources were removed from the resource file used for the application and added to another resource file that was built to make the satellite DLL. Following the instructions at the above link, the DLL was named <app>ENU.dll, where <app> is the application name. This part worked perfectly. Without the DLL present there were errors related to missing resources, and when I added it, everything worked as it did when the resources were in the application itself.
Then I tried again with the resources converted to Chinese. I left the language IDs as English although the text was all Chinese, and the file itself was Unicode. (Pretend this is language learning software where people who know English are learning Chinese.) Now the menus are English and the dialogs and tips for the toolbars are Chinese. I do not know where the English information is coming from. I used the resource API to list the resources in the DLL and the application, and the text that is displayed in the menus and tips does not appear in either of these.
When I run the program as an administrator, everything is Chinese. When I run as any other user, again everything is Chinese. Finally, when I rename the application and the resource DLL (say from x.exe and xENU.dll to y.exe and yENU.dll), there is Chinese everywhere regardless of who runs the program.
It appears that somehow the menu information is being cached and associated with the application name and user name. I would appreciate some information on what exactly is going on and how to resolve the problem with mixed-language resources. Thanks for any assistance.
Jim
Topic archived. No new replies allowed.