Professional UI Solutions
Site Map   /  Register
 
 

Forum

Please Log In to post a new message or reply to an existing one. If you are not registered, please register.

NOTE: Some forums may be read-only if you are not currently subscribed to our technical support services.

Forums » Prof-UIS Tech Support » Language localization problem, Menu titles and tooltips not traslated! Collapse All
Subject Author Date
Francesco Toscano May 10, 2007 - 2:50 AM

I am new to Prof-Uis lib and I found a problem regarding localization resource. I am developing an application that have the user interface in two languages (English - Italian). The default language used by the application is italian, then optionally, there is a resource only DLL for the English interface. Because I do not handle the language swicth on the fly, in the InitInstance() of the App Class, I load if required, the resource DLL. When I don’t use the resouce DLL for English UI everything is ok. When I load the english resource DLL, the menu Titles as (File, edit, View etc..) are not translated to english but are displayed in Italian, then the menu items are correctly translated to the language based on DLL.

The same occurs for the strings resource used by the apllication for Tooltips, are still displayed in in italian. Of course all the resources, in the resource dll, are traslated to English and the language Id for each resource is English US.

this is the code I am using:

BOOL CBeutyPlannerApp::InitInstance()
{
// InitCommonControls() is required on Windows XP if an application
// manifest specifies use of ComCtl32.dll version 6 or later to enable
// visual styles. Otherwise, any window creation will fail.
    
InitCommonControls();

    CWinApp::InitInstance();

    if(m_bEngres)
        {
        g_ResourceManager->AllowCustomLang(TRUE);
        g_ResourceManager->SetLangIdDesired(__EXT_MFC_LANG_ID_ENGLISH_US);
        
        //else
        if(!g_ResourceManager->RscInst_Insert("EngRes.dll"))
            {
            CString strErrorMessage;
            strErrorMessage.Format(_T("Failed to load resource DLL (%s)"),
                    "EngRes.dll");
                ::AfxMessageBox( LPCTSTR(strErrorMessage), MB_OK|MB_ICONERROR );
                return FALSE;
            }
        }
    
    //
    // Prof-UIS advanced options
//
    SetupUiAdvancedOptions();

...............continue............

}

What is Wrong????
Finally the function "CExtResourceManager::RscInst_Insert" is not documented????

Please someone can help me.

Francesco

Technical Support May 10, 2007 - 11:26 AM

First of all the CExtResourceManager::RscInst_***() APIs are experimental and may be changed. That is why they are not documented. You don’t need these APIs if your resource DLLs are MFC extension DLLs loaded with the ::AfxLoadLibrary() function.

As for the menu items: their text strings are loaded by MFC when the frame window is created. You can set main frame’s menu to NULL and invoke the CExtMenuControlBar::LoadMenuBar() method to initialize the menu line.

The problem with non-localized tooltip is not clear. Would you send us a stripped version of your project with UI code only or any other test project so we can figure out what’s wrong?

Francesco Toscano May 10, 2007 - 4:05 PM

First thanks for the reply,


First Question:
As you suggested with the use of CExtMenuControlBar::LoadMenuBar(), it solves the problem I reported regarding the titles on the menu line.
Probably I miss some points, but regarding this there is something that I don’t understand What is the reason of calling the CExtMenuControlBar::LoadMenuBar() method to initialize it during the CMainFrame::OnCreate() if the resouce Dll has been called during CWinApp::InitInstance()? So if the resource DLL has been called and Initialized before any menus creation, why to call after CExtMenuControlBar::LoadMenuBar()? Is this should be done been by the framework itself after the execution CWinApp::InitInstance()?

Second Question:
Generally I used to store resource languages within DLLs build with the flag Resource only DLL (noentry point). Anyway I can easy change to MFC Extension DLL, but why if I use the following code to load a non extension dll the app doesn’t work?

HMODULE hModule = ::LoadLibrary("bplangeng.dll");
if(!hModule)
::AfxSetResourceHandle(hModule);

Third Question:
Regarding the matter of non-localized tooltip I will try to be more clear. I am talking about those that are displayed on the left of the status bar, only those that are displayed when the user move the mouse over the menu bar titles are still displayed in Italian (if the English menu is loaded). Then The tooltips for the MAXIMIZE - MINIMIZE and CLOSE buttons on the right corner of the app window are displayed always in English.

Finally if you still want a test project, please tell me where I can send it.
please apoligise for my written english.

Many thanks, Francesco.

Francesco Toscano May 14, 2007 - 3:28 AM

Please this message replace my reply dated May 10, 2007 - 4:05 PM due some errors that I made at time was posted

First Question:
I used to store resource languages within DLLs build with the flag Resource only DLL (noentry point), this because my project it is statically linked with MFC and I can’t change the project settings because all my libraries are static.
In all my MFC project I always used the code reported below, but if I use this code with my project linked with Prof-UIs lib statically fails.

HMODULE hModule = ::LoadLibrary("lang.dll");
if(hModule)
::AfxSetResourceHandle(hModule);

For this reason How can I load a resource only library non MFC Extension DLL but regular DLL at application startup, if AfxSetResourceHandle() do not work?????

At the moment my project only works if I use the "g_ResourceManager->RscInst_Insert("lang.dll"))", that you told me that use is experimental.
If I continue to use "g_ResourceManager->RscInst_Insert("lang.dll"))" (to load the resource language DLL) and, as you suggested, I Use of CExtMenuControlBar::LoadMenuBar(), it solves the problem I reported regarding the titles on the menu line. But, probably because "g_ResourceManager->RscInst_Insert" is experimental, some tooltips are not switched to the language of the resource DLL loaded. I am talking about those that are displayed on the left of the status bar, only those that are displayed when the user move the mouse over the menu bar titles. This are still displayed in Italian (if the English resources are loaded with dll). Then The tooltips for the MAXIMIZE - MINIMIZE and CLOSE buttons on the top right corner of the app window, are displayed always in English (Also when the only resource available for the application isin Italian and the resource DLL (in english) is not loaded).

About the of CExtMenuControlBar::LoadMenuBar(), probably I miss some points, but regarding this there is something that I don not understand. What is the reason of calling the CExtMenuControlBar::LoadMenuBar() method to initialize it during the CMainFrame::OnCreate(), if the resouce Dll has been called during CWinApp::InitInstance()? So if the resource DLL has been called and Initialized before any menus creation, why to call after CExtMenuControlBar::LoadMenuBar()? Is this should be done been by the framework itself after the execution CWinApp::InitInstance()?



if you still want a test project, please tell me where I can send it.
please apoligise for my written english.

Many thanks, Francesco.

Technical Support May 14, 2007 - 8:43 AM

We are sorry for the delay. Prof-UIS uses its own resource manager component for loading resources of any type. The CExtResourceManager::RscInst_***() methods are experimental but they are stable and you can use them. So to load the resources of any preferred language from any known module is absolutely not a problem. The MFC uses resource DLL substitution based on the ::AfxSetResourceHandle() function, but MFC searches all the available modules (EXE and MFC extension DLLs) for resources of the language which corresponds to the current system locale. So, if you want to use the pure MFC based resource localization, then your EXE should not contain neither English nor Italian nor any other resources. They should be moved into stand alone DLLs (one DLL per language). Only in this case the MFC will have change to load only the Italian resources on a Windows OS where current locale is English. This problem is absent in Prof-UIS where the resource manager implements its own resource searching and loading algorithm. In Prof-UIS based application you even can include both English and Italian resources into your EXE and set up the language preference in the resource manager. The preferred language resources will be loaded correctly, but this is related to Prof-UIS components only. This explains the menu localization problem in your application:

1) If your code invokes the CExtMenuControlBar::LoadMenuBar() method, then it re-loads the menu data of desired language and everything is OK.

2) If your code does not invoke this method, then the menu bar gets menu tree from the HMENU handle of the main frame window. This menu was loaded by MFC code during creation of the main frame window and the MFC resource loading algorithm was used. Nobody can guarantee the menu of desired language will be loaded by MFC until you will move all the resources into stand alone DLLs (one DLL for each language).

The tooltips over the minimize/maximize-restore/close buttons are displayed by Windows OS if you are using non-skinned window non client area. If the non client area is skinned by the currently installed paint manager, then the tooltip texts are taken from the window’s system menu. In both cases, Prof-UIS gets the tooltip texts for the window buttons not from its own localized resources - it gets its from Windows. This should not be a problem to see these tooltips displayed using the same language as they displayed for all the windows on the same desktop.

The status tips and all the strings displayed in the status bar’s panes are taken from the string table resource and should appear localized correctly independently on which localization way you will choose (of course, in case of MFC you should implement all resources in standalone DLLs).

Francesco Toscano May 15, 2007 - 5:11 AM

Many Thanks, your explanation has been very clear. Now I understand.

Anyway I am also considering the opputunity to use Language switch on fly. But I encuntered some problems adapting your sample to my needs. I found problem using the capability in SDI project without using the CExtCustomizeSite class. I know that It is my problem because I am new to Prof-uis and at the moment, I have not exactly understood how the CExtCustomizeSite class works. This because adapting your example project LanguageSwitcher removing the CExtCustomizeSite class capabilities, in my application SDI do not work. But, I repeat, I know it is my problem, of course I have not developed the code in the right way. If you have the possibility to send me my an example that works in SDI context without the CExtCustomizeSite, thi will be well accepted.

Again thank for you professional support.
Francesco.

Technical Support May 15, 2007 - 9:09 AM

The CExtCustomizeSite controls both toolbars and menus in customizable applications. It implements customize mode and shows customize dialog in it. It handles drag-n-drop events from toolbars and menus. It synchronizes content of multiple copies of built-in combo fields and text fields. It does other tasks specific for customizable toolbars and menus only. You can read the Prof-UIS Customization Subsystem articl and decide whether you need customizable tool bars and menus in your projects.

It is possible to localize the non-customizable application in the same way like demonstrated in the LanguageSwitcher sample application. Unfortunately we have no ready test project, but we already assisted our customers on this question. The on-the-fly localization should be implemented as complete re-update of the command descriptions in the command manager. This means you should re-register the command profile and update it from all the toolbar and menu resources like you did at startup. The CExtCmdManager::ProfileDestroy() method should be used to remove the command profile. The further invocations are similar to typical command profile registration and updating it from resources.