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

Multi-Language Add-In for Visual Studio


Resource Compiler Mismatch

Hi,

After scanning my project, some items on the source code tab have a mismatch between resource and compiler on the tooltip (hover the cursor over an item in the name column) eg...

Component: MDIForms.h
Property: BarManager.Items0.Text
Resource: cmdOpen.Text
Compiler: cmdExport.Text

This results in the wrong text displaying in the app at run-time but I can't see any issues in the resx etc. Please help!

Thanks,
Paul

Germany

Hi Paul,

initially, I am baffled by this one!

Am I right in thinking you are working with managed C++ and that this is a Windows Forms project in C++?

Which version of Visual Studio are you using? Under Visual Studio 2010, the Add-In takes way too long to scan a windows forms project in managed C++. I will have to find some way to speed it up, because it is almost unusable. For this reason, I guess that you are using Visual Studio 2008.

Can you send me part (or all) of your project? Maybe the MDIForms component?

I will try to do some more testing in the next day or two.

Phil


Hi Phil,

I responded to you via email on the 10th and 19th Jan but didn't hear back... Please could you confirm receipt to rule out any email issues, or an update if you have made any headway with this?

Thanks,
Paul

Germany

Hi Paul,

sorry that I did not reply.

I have just been looking at this issue. It looks to me as if the Add-In recognizes your project as unmanaged C++, and wants to analyze the resources by reading the .rc file. If it recognized it as a managed C++ project, it would try to handle it more or less as a Windows Forms application.

I don't know much about C++/CLI applications. In fact, I am rather surprised that you have both a .rc file and .resx files in the same project.

Correct me if I am wrong, but my understanding is that C++/CLI is managed code, compiled for the .NET framework, and not native Win32 code.

Internally, the Add-In fetches the "ManagedExtensions" property, which has values described by the compileAsManagedOptions enumeration (as suggested by Carlos Quintero).

This is basically equivalent to the project setting Configuration Properties/General/Common Language Runtime Support.

How is this property set in your project?

By the way, I interpret the setting "Common Language Runtime Support (/clr)" as unmanaged code, which I believe is correct, but I could be wrong.

It might help me if you could send me a copy of your project file (.vcproj or .vcxproj).

Phil


Hi Phil

The project is a mix of managed and native C++ code... the /clr switch compiles managed code whenever possible, so an application compiled using /clr may or may not contain managed code.

The project propery 'Common Language Runtime Support' is set to /clr, and the ManagedExtensions property in the project file is set to true. A cut down copy of the project file is attached.

Thanks,
Paul

Germany

Hi Paul,

so you are using the /clr switch, which means that program is compiled as native code, but can access .NET classes (which is what C++/CLI is all about).

If I understand correctly, when you work with resources you have a choice whether to use a .rc file, or .resx files.

This has some consequences for the Add-In:

  1. It should scan .resx files as Additional resources. This should be pretty easy.
  2. The Add-In also has a choice, where it stores resources, and what code it should include in the module MlString.cpp

At present, it think that I am going to have to add a project-option to select where to store the resources. For an unmanaged C++ project, the default would still be the .rc file, but optionally the resource strings could be stored in MultiLang.resx.

Do you have any idea how this would work with satellite DLLs?

Will the .NET part of the program handle this automatically? Or will we need some special code to load the correct language DLL?

Your original mail (6-Jan-2011) reported that the source code scan was OK, but the controls tab was empty.

It the Add-In scans the .resx files, I would show any strings from these files in the tab "Additional Resources". Do you actually expect anything to appear in the controls tab?

I know that your .rc file does not contain any resources (dialogs or menus). Since it is unmanaged code, it can't contain any Windows Forms (or can it?). Does your program have a user interface?

Phil


Hi Phil,

The /clr switch compiles the code to CIL then machine code, it allows a mix of managed and unmanaged code. Apologies if my terminology caused confusion, by native I meant unmanaged C++/CLI code compiled using the CLR.

A .resx file is automatically created when you set a forms localizable property to true, and satellite .resx files are created when you change the language property to something other than default.

MultiLang2005 V4.51 scanned the .resx files fine and added the resources to the controls tab?

My program is a mix of managed and umanaged code and includes a UI with many Windows Forms which are implemented as managed classes.

Thanks,
Paul

Germany

Hi Paul,

this is actually very interesting. I have never paid any attention to C++/CLI before, but it looks like a clever way of using .NET features in existing C++ Win32 applications.

It looks to me as if C++/CLI projects can handle localization in a .NET way (which is what you want) or in an C++/MFC way.

I have added an option to the Add-In, to select how the localization should be handled. You can select this option in the project properties dialog as shown here:
Image

When you scan a C++/CLI project for the first time, the Add-In will show a different dialog asking how you want to handle localization.
Image
I hope that this dialog is understandable.

Since you have already worked with the Add-In with your project, this dialog will not appear. You will have to open the project properties dialog (5th button on the toolbar).

As indicated in the dialog (above) the selection affects two things:

  • how resources are stored (.rc or .resx)
  • which controls are scanned (.rc DIALOG and MENU resources or Windows Forms)


Theoretically, you might want to handle both. I'm not sure anyone will actually want to do this, and I'm not really sure how it would work either. I don't much like the idea of having one set of satellite DLLs for .NET and another for MFC. For the present, I have decided not to support this.

Selecting .NET support should get you back to the behaviour of the older version.

I have not checked the exact version, but I presume your old version either did not handle unmanaged C++ at all, or that it considered the C++/CLI projects as managed code.

By the way, I know that there are some performance problems with Windows Forms projects in C++. Because not may people are using this support, I haven't worried about it too much. If the scan is intolerably slow, let me know.

Phil


Hi Phil,

Thanks for the new option, the Add-In now scans the .resx as additional resources.

Many of my forms are inherited from Syncfusion RibbonForm, these scanned fine but standard forms were added to the controls tab as empty folders and this seems to cause the 'Setting Localizable Property for Forms and Controls' dialog to pop up for these forms when selecting strings for translation... I had to do this for all Syncfusion controls, the scan didn't do this automatically? I excluded the standard forms, selected all my translations, then added the standard forms back in to work round this.

Regards,
Paul

Germany

Hi Paul,

I don't entirely understand that, but I will download a trial version of the Syncfusion controls and try to reproduce it.

Phil


Hi Phil,

I managed to work round the problem so I wouldn't worry too much about it... I doubt that there are many other C++/CLI projects using Syncfusion and MultiLang2005 Add-In out there!

Thanks,
Paul