The information in this article applies to:
SYMPTOMSIf an executable supports different languages through the use of compiled resources, FindResource() might return a handle to the wrong resource if it is called from a service while there is no interactive user. CAUSEFindResource() determines which code page to use based on a cache created when the interactive user logs on to the workstation. An interactive user is any user who logs on by pressing CTRL+ALT+DEL to access the WinLogon dialog box. Because a service can run while there is no interactive user, this cache may not exist. In this event, LoadResource() looks in Locale.nls, the default National Language Support (NLS) file. This file always indicates "English (United States)" as the current language, causing the API to return a handle to the wrong resource. RESOLUTION
Use FindResourceEx() and pass the default system language identifier as the
wLanguage parameter. This identifier can be retrieved using
GetSystemDefaultLangID(). This API should work correctly from within a
service, even if there is no interactive user.
STATUSMicrosoft has confirmed this to be a problem in the Microsoft products listed at the beginning of this article. MORE INFORMATIONOther APIs that retrieve resources such as LoadString() may also fail to retrieve the correct localized resource. In this case, you must use FindResourceEx(), as explained above, and LoadResource() to retrieve the resource. You can then format it as necessary. Additional query words: kbDSupport
Keywords : kbKernBase kbNTOS400 kbResource kbService kbDSupport kbGrpKernBase |
Last Reviewed: December 29, 1999 © 2000 Microsoft Corporation. All rights reserved. Terms of Use. |