Forum

Dear Prof-UIS support team,

I use with great interest the CExtReportGridWnd::ReportGridStateSerialize() method to store and retrieve predefined Report layouts.

This work well until I switch from one language to another (using the LanguageSwitcher).

For instance, I define predefined layout formats while the application is configured for English and save them as archives. These predefined layout formats are shipped with the application installation files, and a user, let say Italian, may switch the application to Italian. In this case, the ReportGridStateSerialize() method fails on the predefined layout formats. I think it should not (their should be an invariant to retrieve columns, and their names should be an attribute, not a key, I guess).

The problem is the same with the ReportGridStateSave() and ReportGridStateLoad() methods.

How can I get my format files independent from language ? Is this a bug ?

Best Regards,

Christophe Guibert

We can guess the problem occurs because you use localized names for report column categories and/or column names. The problem can be fixed in one of the following ways:

1) We modify the report grid’s design. It would support two names for each category and column: internal name for serialization and most of APIs and display name used for painting only. Although it is an acceptable solution, it will certainly make the report grid’s API more complex.

2) You modify your project. It would use English names at startup and at shutdown in any case. The state of the report grid control would be serialized using English strings only. On startup columns and categories are renamed to the desired language. Before shutdown the localized names are renamed to English back. We think it is an acceptable solution and it is based on one string map in your application and on two simple loops for renaming columns and categories.

Hello,

I can partly modify my project : hardcoding the default layouts for initial state, but after, the problem will remain. Worse, the user can change the column names (this is a faceted classification software : the user can use 10 different facets and rename them according to HIS classification criteria).

So I think your #1 suggestion would be the best : you would have a complete separation between the internal (and invariant) name and the external name (both language and user dependent).

Although I do not well know the internals of prof-UIS classes, it seems to me that you would not need to have a more complex grid API : the columns could have a private unique ID that would stay invariant while column name and category would remain attributes with their current API accessors. I suppose that this unique invariant ID could be used internally for column management, including save / load of layout in the registry or in an archive.

If you estimate it is usefull, I would be pleased to used this feature. But I can cope without ! The only drawback in that the user won’t know that his previouly saved layouts will become unsusable if he changes a column name.

Anyway, I thank you for your responsive and high quality support !

Best Regards,

Christophe Guibert

Of course, the easiest way for us is to use current column/category names as unique identifiers and as display names. But we can additionally add localized display names. If any localized display name is empty, the current display name will be shown. If the localized display name is specified, it will be shown in the report grid and in the field chooser. But you will have to use the original basic names when invoking report grid methods. We do not need to add any unique GUID for columns because CExtReportGridColumn * pointers are unique. If this is acceptable, we will provide you with the solution in a few days.

Hello,

Yes, I think it would be a good solution : there would be an additional method to set the localized name, wouldn’t there ?

I would be pleased to have your solution and thank you in advance.

Best Regards,

Christophe Guibert