oder hilft dir dieser laengere beitrag etwas?
auszuege aus ms- knowledgebase.
du kannst diese auch nett formatiert abrufen
von der cd mit den ‚article ids‘.
PRB: AppWizard Cannot Generate Resources in Sublanguages
Article ID: Q148436
Creation Date: 13-MAR-1996
Revision Date: 15-MAR-1996
The information in this article applies to:
The MFC AppWizard included with: Microsoft Visual C++, 32-bit Edition, versions 4.0 and 4.1
SYMPTOMS
AppWizard does not generate resources in sublanguages if the language setting of the operating system is set to a sublanguage instead of one of the five standard languages supported by Visual C++ 4.0.
CAUSE
AppWizard does not allow selection of sublanguage during application creation. If the language setting of the operating system is set to a sublanguage instead of a standard dialect, AppWizard does not use that information.
RESOLUTION
Change the „Language Settings“ property for the resource to match the exact language setting for the operating system.
To do this for a dialog resource:
Right-click the dialog’s name in Resource View, and then click Properties.
In Dialog properties window, change Language Settings to match the current setting for the operating system.
As an alternative, you can create a new copy of the resource in some other language by following these steps:
Right-click the dialog’s name in Resource View, and then click Insert Copy.
In the Insert Resource Copy window, select the Language that exactly matches the language setting of the operating system.
STATUS
This behavior is by design.
MORE INFORMATION
Steps to Reproduce Behavior
There are several ways to reproduce this behavior in Windows NT and Windows 95. In Windows 95, change Regional Settings from the Control Panel; select French (Swiss) as the language. Then restart your computer, and start Visual C++ version 4.0. Perform the following steps:
Create a dialog-based application by using MFC AppWizard. AppWizard allows five choices of languages for resources. Sublanguages are not listed and cannot be specified. Select French (Standard) for the resource language.
Generate the application.
Change to Resource View.
Open the main window dialog. It shows the label „French (French)“ with the dialog’s name.
Because the language setting for the resource does not match the language setting of the operating system, you may see another behavior where ClassWizard does not show Control IDs under the Member Variables Tab. For more information about this behavior, please see the following article in the Microsoft Knowledge Base:
ARTICLE-ID: Q145997
TITLE : PRB: Resource Language Must Match Current System Language
PRB: Resource Language Must Match the Current System Language
Article ID: Q145997
Creation Date: 12-FEB-1996
Revision Date: 13-FEB-1996
The information in this article applies to:
The ClassWizard included with: Microsoft Visual C++, 32-bit Edition, version 4.0
SYMPTOMS
Under some circumstances, ClassWizard does not show the control IDs for a dialog resource in the Control IDs listbox under Member Variable Tab.
CAUSE
This is by design. If the language settings of the resource are not the same as the language settings of the operating system, you will see this behavior. For example, if you are using US English settings for the operating system and the dialog resource is in some other language, you will see this problem.
RESOLUTION
By design, the language setting for the resources must be identical to the language setting for the operating system. There are two ways to synchronize your resources language:
Method One: Reset the Language for an Existing Resource
From the Resource View, highlight the resource in question, and then right-click it.
Select Properties.
Choose the language that matches that of your operating system.
Method Two: Copy an Existing Resource to One that Matches Your Language
Right-click the dialog’s name in Resource View, and then click Insert Copy.
In Insert Resource Copy window, select the language that exactly matches the language setting of the operating system.
STATUS
This behavior is by design.
MORE INFORMATION
Steps to Reproduce Behavior
Generate a dialog-based application by using MFC AppWizard.
Change to Resource View.
Open the main window dialog.
Add an edit control.
Right-click the dialog’s name in Resource View, and click Properties. In the Dialog properties window, change Language Settings to some language other than the current system language.
Start ClassWizard.
Click the Member Variables tab. The ID for the edit control does not show up in the Control IDs list.
Change the Language Settings property to match the current system language. Now, ClassWizard will show the IDs in Member Variables tab.
For more information about using the resource editor and localizing your application please see:
„Using the Resource Editors“ in the Help file’s „Visual C++ User’s Guide,“ in the „Working with Resources“ section.
Tech note 57 (TN057), „Localization of MFC Components.“
How to Localize Application Resources with Foundation Classes
Article ID: Q147149
Creation Date: 20-FEB-1996
Revision Date: 10-MAR-1997
WINDOWS | WINDOWS NT
1.00 1.50 1.51 1.52 | 1.00 2.00 2.10 2.20 kbprg kbhowto kbcode
The information in this article applies to:
The Microsoft Foundation Classes (MFC) included with:
- Microsoft Visual C++ for Windows, versions 1.0, 1.5, 1.51, 1.52
- Microsoft Visual C++, 32-bit Edition, versions 1.0, 2.0, 2.1, 2.2
SUMMARY
Microsoft Foundation Class Library Technical Note 23 explains how to customize standard framework resources, such as the buttons on a print preview dialog bar. However, this technical note does not provide a good solution for developers who are producing an application localized into more than one language, and there is a problem with the method described.
When localizing an application for several languages, it is most convenient to place all of the application’s resources into a dynamic link library (DLL). To localize the application into a new language, clone the DLL and translate the resources into the appropriate language. After testing, you can ship the application code with the appropriate language-specific DLL to address each market.
The remainder of this article outlines the general steps required to localize an application by moving the resources into a DLL.
MORE INFORMATION
To place all application resources into a DLL project, open the .rc file in App Studio. Choose Save As from the File menu to store the resources into another directory (created for this purpose). Then open the original .rc file, and remove all resources visible in the App Studio Resource Browser. Finally, choose Set Includes from the App Studio File menu. Delete the
#include statements for Afxprint.rc and for Afxres.rc from the Compile-Time
Directives list and choose OK.
Use the Visual Workbench to create a new Windows DLL project for the resources. Set the project type to Windows dynamic-link library, and clear the „Use Microsoft Foundation Classes“ check box. Add the .rc file to the project. Then create the following files in your DLL directory, and add them to the project.
Mylocal.cpp
#include
int CALLBACK LibMain(HINSTANCE hinst, WORD wDataSeg, WORD cbHeap,
LPSTR lpszCmdLine )
{
return 1;
}
Mylocal.def
LIBRARY MYLOCAL
DESCRIPTION ‚Localized resources for MFC application‘
EXETYPE WINDOWS
CODE PRELOAD MOVEABLE DISCARDABLE
DATA PRELOAD MOVEABLE SINGLE
SEGMENTS
WEP_TEXT FIXED PRELOAD
EXPORTS
WEP @1 RESIDENTNAME ; required WEP entry point
; (uses library WEP routine)
Copy the standard framework resources into the .rc file for your DLL so you can modify them. Technical Note 23 outlines a procedure to do this. To copy all resources from Afxprint.rc and Afxres.rc into the .rc file for your DLL, select the resources in each source file. Then press and hold the CTRL key and drag the resources into the new .rc file. Edit the Compile- Time Directives list box in App Studio to remove the #include files.
There are two problems with this procedure. Perform the following two steps to work around these problems before compiling your DLL:
NOTE: In MFC version 2.5 and later, step 1 is no longer necessary.
The AFX_IDC_MAGNIFY cursor, used by print preview, is loaded using the AfxGetInstanceHandle() function rather than the AfxGetResourceHandle() function. This error occurs on line 904 of the Viewprev.cpp file in the Microsoft Foundation Class Library source directory (by default, C:\Msvc\Mfc\Src). If you wish, you can modify the source code and recompile the libraries. However, a reasonable method to work around this problem involves copying the AFX_IDC_MAGNIFY resource into your application’s .rc file. Only this resource would be common to all languages.
The Afxprint.rc file (located by default in the C:\Msvc\Mfc\Include directory) declares AFX_IDD_PREVIEW_TOOLBAR, the standard framework resource for the print preview CDialogBar, with the following resource style:
STYLE WS_CHILD | CBRS_TOP
The problem is that the CBRS_TOP style is specific to the Microsoft Foundation Class Library; App Studio does not copy this style when you follow the procedure in Technical Note 23. Use a text editor to open the .rc file as a text file. (Note that you may need to change an option in the Editor Options dialog box in Visual Workbench.) Add the vertical bar (the OR symbol) and CBRS_TOP to the STYLE statement. Otherwise, the print preview dialog bar does not appear.
AppWizard creates the .rc2 file in the DLL Res directory to contain version information for the application. Edit this information as appropriate for your DLL.
Build the DLL project and copy it into your application’s directory.
To use the localized resources in the DLL from your application, add the following code to your application and rebuild it:
Modify the main application class (for example, CMyApp) to add an HINSTANCE member variable to contain the DLL instance handle, as follows:
HINSTANCE m_hInstDLL;
In CMyApp::InitInstance(), insert the following code before the first line of code generated by ClassWizard:
if ((m_hInstDLL = ::LoadLibrary(„mylocal.dll“)) > 10)
Writing Code that Works with Different International Formats
Article ID: Q130056
Creation Date: 10-MAY-1995
Revision Date: 16-MAY-1995
The information in this article applies to:
Microsoft Windows Software Development Kit (SDK) for Windows version 3.1
Microsoft Win32 Software Development Kit (SDK) version 3.5
Microsoft Win32s version 1.2
SUMMARY
Some European coutries like Germany use a different floating point format that doesn’t include the decimal point (.). This has caused problems whtn the actual numbers use the decimal point format (xxx.xx) and the German version of Microsoft Excel is expecting a comma (xxx,xx).
Some developers have made the mistake of hard-coding formats or searching for all periods and replacing them with commas. This is not good programming practice.
Microsoft Excel uses the Control Panel Number Format for its separators. So, regardless of what language version of Windows it runs on, it always uses the correct separators. Microsoft recommends that you use the same approach. Always use the separators defined in the number format of control panel.
MORE INFORMATION
All the international information is stored in the WIN.INI file under the [intl] heading. The application should look for the value of „sDecimal.“ It can query this value using the GetProfileString API. If the application uses this approach, it will have the correct separator for all countries.
To avoid potential problems, never make assumptions about number formats, currency formats (that is, don’t hard-code the dollar symbol), date formats, or time formats. These are different for different countries. Use the settings from the Control Panel.
If an application does any text processing, such as sorting or upper/lowercase conversions, it should use the Windows APIs and not supply its own conversion tables and functions. For example, if an application use APIs such as AnsiLower, it will work regardless of language because it obtains the data from the language DLL.
To output floating point numbers in Windows, Microsoft recommends that you use wsprintf. The concept of an „international format string“ only has meaning when the string is output to the user. Internal to the computer, for all calculations and manipulations, the concept does not apply. Thus the application can keep its floats in the native format and only convert to strings before calling the wsprintf function.
There is no need to load conversions from float to string, and vice versa. In other words, there is no need to write any functions such as InterStringToFloat(), InterFloatToString(), and so on.
Here’s a simple algorithm you could use.
Convert your float to a string by using the _fcvt or _gcvt standard C functions.
Get the sThousand and sDecimal separators from the WIN.INI file by using the GetProfileString API.
Call wsprintf to output the converted string, using sThousand and sDecimal in the formatting string.
The following is an example of a mistake made by a developer who was not thinking internationally:.
if language=English
Output_English_Float ()
else
Output_International_Float ()
This is not correct. Think of English as just another language and write a single Output_Float() function that covers all languages.
Also, for ease of localization, a developer should place all strings in the resource file. This avoids having to search through all the C files looking for strings to translate.
-------------end======================================================
