Loading...
 
Multi-Language Add-In for Visual Studio

Multi-Language Add-In for Visual Studio

Forum List Topic List

 
Thread actions
Print this page
  • Print all pages

    • targetver and targetdir

    Posted by tazer on Tue 17 of Aug, 2010 09:41 GMT

    Hello every body,
    I use the Add-in for .net 2008, version 4.71.0031
    I create an example MFC MDI project with the appwizard with default options.
    My original language is frensh.
    With the Addin I add the english language respecting the "quick tour (Unmanaged C++ and MFC)", 2 subprojects en and fr-FR are created.
    When I compile the project I have a lot of errors :
    1 : TestMultiLangue_fr-FR : error PRJ0007 : Impossible de créer le répertoire de sortie 'C:\Program Files\Microsoft Visual Studio 9.0\Common7\I:\Dev\TestMultiLangue\Debug\fr-FR'.
    I remark that in the fr-FR project properties the TargetDir and targetPath link to the VS9 directory.

    2 : i:\dev\testmultilangue\testmultilangue\mainfrm.cpp(71) : error C2653: 'LMultiLang' : n'est pas un nom de classe ni d'espace de noms
    I have a lot of errors like this.

    3 : i:\dev\testmultilangue\testmultilangue\mainfrm.cpp(71) : error C3861: 'ml_string' : identificateur introuvable
    I have a lot of errors like this.

    4 : i:\dev\testmultilangue\testmultilangue\propertieswnd.cpp(215) : error C2440: 'initialisation' : impossible de convertir de 'const CString' en 'TCHAR []'

    5 : Other problem : The file targetver.h is not copied in the "en or fr-FR" directory.

    Where is my error ?
    think for replay

    Reads: 33812
    Link
    Posted by Phil on Fri 03 of Sep, 2010 21:55 GMT Germany

    Hi,

    I will try to look at this over the weekend.

    Phil

    Link
    Posted by Phil on Sun 05 of Sep, 2010 12:07 GMT Germany

    Hi

    I tried out your example and found some problems which you can workaround. I can fix some of them, but maybe not all.

    Output directory

    The Add-In creates additional projects to generate satellite DLLs. It sets the output directory so that the satellite DLL is created in a subdirectory of the output directory for the main project.

    The output directory of your main project is $(SolutionDir)$(ConfigurationName). The Add-In sets the output directory for the satellite DLL to ..\$(SolutionDir)$(ConfigurationName)\fr-FR\.

    Fairly obviously, this is stupid!

    Image

    If you remove the ..\ from the start of the output directory this will be fixed.

    This is an error in the Add-In. It tries to determine whether the output directory is a relative path or an absolute path. If it is a relative path, it adds the prefix ..\, because the satellite project is in a subdirectory of the main project. In this case, it does not recognize it as an absolute path. I guess that I can fix it.

    Unknown identifier LMultiLang

    This is a subtle problem with C macros.

    You are using the macro TRACE0. If you replace it with TRACE, it will fix the problem.

    TRACE0 is defined as follows:

    Some macro definitions
    // Definition of TRACE0 macro (from afx.h)
#define TRACE0(sz)              TRACE(_T("%s"), _T(sz))

// Definition of _T (from tchar.h)
#define __T(x)      L ## x
#define _T(x)       __T(x)

    Since your project uses unicode, the _T macro will prefix the string with the letter L (to generate a unicode string literal).

    Suppose you use
    TRACE0("Impossible de créer toolbar\n")
    this will be converted to
    TRACE(L"%s",L"Impossible de créer toolbar\n")

    The Add-In replaces the string
    "Impossible de créer toolbar\n"
    with
    ML_STRING(372, "Impossible de créer toolbar\n")

    ML_STRING is also a macro

    ML_STRING macro definition
    #define ML_STRING(id,text) MultiLang::ml_string(id)

    so this is converted to
    MultiLang::ml_string(372)

    If we put these two together,
    TRACE0(ML_STRING(372, "Impossible de créer toolbar\n"))
    is converted to
    TRACE(L"%s",LMultiLang::ml_string(372))

    Instead of prefixing a string literal with L, it has prefixed the name MultiLang with L, which leads to a compilation error.

    As I mentioned, if you replace TRACE0 with TRACE, it fixes this error.

    I am not going to fix this problem in the Add-In, because:

    • I can't see any easy way to fix it
    • I think it is a lousy macro anyway
    • There is not much reason to localize this text anyway


    I presume that you are only localizing this text for a test. There is not really much point in localizing trace output!

    targetver.h

    You are right. This file is not copied. I suggest that you copy it by hand.

    I might be able to fix this. If I can fix it by extending the include path in the satellite DLL project, then that would be quite easy.

    On the other hand, there might be a much better way to work with the .rc files anyway. The Add-In currently generates a .rc file with a single language for each satellite DLL. If you look at the code which Microsoft generates in the .rc files, it is clear that they expect you to use the same .rc file in all satellite DLLs, and to use conditional compilation to select the correct language.

    For example, by defining the macros AFX_RESOURCE_DLL and AFX_TARG_FRA, it would compile only the french resources. If each satellite DLL project had a reference to the same .rc file in the main project directory, then there would be no problem with include files.

    I am still thinking about whether to go down this road. It would be more difficult for me. My functions which read the .rc file would have to analyze the conditional compilation statements, and generate this code correctly.

    Language switching dialog

    After fixing the problems described above, I was able to compile the main project and the satellite DLL project.

    I then tried to add the dialog to select the language when the program starts. Unfortunately, this did not work, because the template files are old (and don't work with satellite DLLs). It looks like I made a new version of the language selection dialog, but only included the template files in the version for Visual Studio 2010.

    I will try to get this fixed very soon.

    By the way, the support for MFC with satellite DLLs is very new. I am pleased to have somebody using it and giving me feedback.

    Best regards
    Phil

    Link