Extra Character Before Special Character

Devin_Golberg · January 12, 2024, 5:10pm

So I've found an issue with certain special characters in Text Areas. The extra character only seems to appear when the special character is added to the Text Area via scripting, and not when entering it with the keyboard using Alt + Numpad codes. One such character is the "±" and another I know of is "º" (minus the "" of course). The character I get is "Â". So for example, the code below activated by a button:

event.source.parent.getComponent('Text Area').text = "This has extra character: ±"

gives the result in the Text Area of:

"This has extra character: Â±"

If you type this into the text area directly in the designer or at runtime using the keyboard alt-codes, the extra character doesn't appear, only when it's put in via script.

We're currently on version 7.9. Is this still present in later versions? I didn't see any topics about this in a quick search, but I would think someone has to have seen this before and I just didn't search the right keywords...

Any work-arounds? I have a lot of data to import via CSV that contains these special characters.

JordanCClark · January 12, 2024, 5:27pm

Try as unicode. If your'e working with CSV, the unicode() function should work:

event.source.parent.getComponent('Text Area').text = unicode("This has extra character: ±")

PGriffith · January 12, 2024, 5:33pm

Probably just prefix the string with the u, e.g. u"some non ASCII string"

Devin_Golberg · January 12, 2024, 5:46pm

That solved the issue. I'm too used to Java which I believe works in Unicode by default, so never had this show up before I started with Ignition. That said, is this an ASCII issue, Python issue, or Ignition issue?

PGriffith · January 12, 2024, 5:47pm

Python/Jython 2 issue.

Devin_Golberg · January 12, 2024, 5:54pm

Makes sense. If it were an ASCII issue, I would think I'd only see the extra character in place of the special char, not it and the special char. If it were an Ignition issue, I'd think I'd see it when input via the designer or alt-codes at runtime, too.

Devin_Golberg · January 12, 2024, 6:05pm

Think I'm going to set JordanCClark as the proper solution, as the "u" prefix isn't ideal for strings stored in variables where as "unicode()" works on both.