“Umlaute” handling issue with attribute values

I wrote a script to count some values in an attribute within a module. When I start the script directly from the menu e.g. added within the project folder to see it under the Tools bar of the DOORS explorer, it is not correctly working due the “Umlaute” issue. Today we are still using the 8.3 DOORS version.

Please reproduce the issue as follow:

1) Generate a new *.dxl file with on command => print("Umlaute äÄöÖüÜ in German!");
2) Run the script over the menu Tools\Edit DXL per Load in the DXL Interaction window.
or directly copy this single command into the DXL input area
3) Run the script or command
4) The output in DXL output is OK => Umlaute äÄöÖüÜ in German!
5) Now generate a new menu item and copy the DXL file generated under 1) into Program Files\Telelogic\DOORS_8.3\lib\dxl\project. Please adapt the *.idx files accordingly. Then restart DOORS and start the script with this single print command.
6) The output in DXL output is wrong => Umlaute in German!

It seems that the DXL script has here different languages for their string handling. The same issue happens when you are using “Umlaute” as a value within attributes. Starting the script directly from the DOORS explorer menu generates a wrong behaviour than starting the script per load in the DXL Interaction window.

Is there anybody who are able to give me some hint how to handle this language issue. I didn’t found a DXL function or command to manipulate the language base for string comparing or handling.
WildThunderGuy - Tue Mar 23 12:20:03 EDT 2010

Re: “Umlaute” handling issue with attribute values
kbmurphy - Tue Mar 23 16:16:42 EDT 2010

I just tried this out in DOORS 9.2, and can confirm that this bug exists in DOORS 9.2.

Very interesting find! My guess is that it has to do with the way DOORS reads in a file.

I did find a workaround. Save your german file as german.inc. Then in your menu DXL file, have it be

#include "/addins/user/german.inc"

This works!

I think you should open an enhancement request with IBM though.

Re: “Umlaute” handling issue with attribute values
Mathias Mamsch - Tue Mar 23 18:35:59 EDT 2010

This seems to be a codepage problem. To fix it you can try the following:
  

string s = convertFromCodepage(currentANSIcodepage(), "Umlaute äÄöÖüÜ in German!") 
print s

 


Running this from the menu works for me. Regards, Mathias

 

Re: “Umlaute” handling issue with attribute values
WildThunderGuy - Wed Mar 24 03:24:39 EDT 2010

kbmurphy - Tue Mar 23 16:16:42 EDT 2010
I just tried this out in DOORS 9.2, and can confirm that this bug exists in DOORS 9.2.

Very interesting find! My guess is that it has to do with the way DOORS reads in a file.

I did find a workaround. Save your german file as german.inc. Then in your menu DXL file, have it be

#include "/addins/user/german.inc"

This works!

I think you should open an enhancement request with IBM though.

Million thanks for your workaround. I already successfully tested your workaround by copying my whole original script into an *.inc file. Then add in the empty original *.dxl file only the include command and it works. It is really a spectacular bug?!

Re: “Umlaute” handling issue with attribute values
WildThunderGuy - Wed Mar 24 03:52:08 EDT 2010

Mathias Mamsch - Tue Mar 23 18:35:59 EDT 2010

This seems to be a codepage problem. To fix it you can try the following:
  

string s = convertFromCodepage(currentANSIcodepage(), "Umlaute äÄöÖüÜ in German!") 
print s

 


Running this from the menu works for me. Regards, Mathias

 

Hi, thanks for your reply and proposal. Actually it works with some restrictions, because my use case is to compare string values in an attribute e.g. checking the attribute value for “Überschrift”. The problem now is, that with the convertFromCodepage command the script is not any longer running in the script generation environment, thus where I am developing the script. When I start the script over the menu it works correctly, really ugly situation. Nevertheless I tried the following:

int codepage = currentANSIcodepage();
string s;

print("Umlaute äÄöÖüÜ in German!\n");
print("Codepage Name is " codepageName(codepage)"\n");

s = convertFromCodepage(currentANSIcodepage(), "Umlaute äÄöÖüÜ in German!")

print(s);

1) Result by running the script in the DXL Interaction window with Load =>
Umlaute äÄöÖüÜ in German!
Codepage Name is 1252 (ANSI - Latin I)
Umlaute äÄöÖüÜ in German!

2) Run the script over the menu =>
Umlaute in German!
Codepage Name is 1252 (ANSI - Latin I)
Umlaute äÄöÖüÜ in German!

It seems that the Codepage is in both cases the same, but the script result is still different!?

Re: “Umlaute” handling issue with attribute values
WildThunderGuy - Wed Mar 24 04:40:43 EDT 2010

I would like to post my new findings regarding this issue. Actually it seems there is an issue mainly with the string constants.

1) Doesn’t work:
const string cObjTypAttrValHeading_str = "Überschrift";

2) Works:
const string cObjTypAttrValHeading_str = convertFromCodepage(currentANSIcodepage(), "Überschrift");

Re: “Umlaute” handling issue with attribute values
kbmurphy - Wed Mar 24 14:20:01 EDT 2010

WildThunderGuy - Wed Mar 24 04:40:43 EDT 2010
I would like to post my new findings regarding this issue. Actually it seems there is an issue mainly with the string constants.

1) Doesn’t work:
const string cObjTypAttrValHeading_str = "Überschrift";

2) Works:
const string cObjTypAttrValHeading_str = convertFromCodepage(currentANSIcodepage(), "Überschrift");

Mathias,

While the underlying issue may be that of Codepages, to me the bigger concern is that DXL run from a menu does not return the same results as DXL run from the interaction window. Having different results for the same code is not good. A bug report should be issued against this item.

Re: “Umlaute” handling issue with attribute values
Mathias Mamsch - Thu Mar 25 05:35:16 EDT 2010

kbmurphy - Wed Mar 24 14:20:01 EDT 2010
Mathias,

While the underlying issue may be that of Codepages, to me the bigger concern is that DXL run from a menu does not return the same results as DXL run from the interaction window. Having different results for the same code is not good. A bug report should be issued against this item.

I agree. This is definitely a bug from my point of view.

Re: “Umlaute” handling issue with attribute values
SystemAdmin - Fri Mar 26 11:35:45 EDT 2010

Mathias Mamsch - Thu Mar 25 05:35:16 EDT 2010
I agree. This is definitely a bug from my point of view.

I seem to remember this from some Swedish text I was writing (åÅäÄöÖ). The answer was that I was saving the dxl code in the wrong encoding type. I changed to ASCII and the problem went away!

/Kristian

Re: “Umlaute” handling issue with attribute values
TCDev. - Fri Apr 30 04:38:59 EDT 2010

Hi,

I got nearly the same problem. When I output the string value to the console everything works fine. But if I use the function copyToClipboard(string s) the value which is in clipboard seems wrong. I tried convertFromCodepage(currentANSIcodepage(), string s) but the wrong character shown instead of the german "ä" got even longer.

When I output the charset to console it seems to be latin1 - but as I said everything works fine if I just use print.

Does anybody has an idea how to copy strings to the clipboard with the right charset?

Re: “Umlaute” handling issue with attribute values
Mathias Mamsch - Sat May 08 18:24:53 EDT 2010

Update:

There is a pragma to explicitly set the encoding of the file:

 

  

pragma encoding, "UTF-8"



seems to resolve the issue (store the DXL file in UTF encoding!). Regards, Mathias



 

 

 

 

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS