TM1 C API (.NET) - element names with trailing spaces

[Harvey]

Hi all,

I know this is a bit fringe, but I'm hoping someone who has worked with the TM1 C API from .NET has come across this and found a resolution.

The Dimension Editor in Perspectives allows you to create an element name such as "aaa ", if you paste the value as text into the dimension list instead of using "Insert Element" or its variants. This in itself is probably a bug, but it works in 10.1.

In code, when I retrieve an element created as "aaa ", I get "aaa?" returned. However, when I call TM1ObjectListHandleByNameGet with a TM1ValString containing "aaa?", I get "Object Property Not List". Thinking I might be able to translate "aaa?" to a name that would work, I tried "aaa" and "aaa ", but surprisingly, both of these resulted in "Object Property Not List" also.

So I get a name back from the API that fails when I try to retrieve it, and can't find a variation of that name that I can retrieve!

Has anyone come up against this before, and did you find a resolution?

Thanks in advance,
Harvey.

[Alan Kirk]

In code, when I retrieve an element created as "aaa ", I get "aaa?" returned. However, when I call TM1ObjectListHandleByNameGet with a TM1ValString containing "aaa?", I get "Object Property Not List". Thinking I might be able to translate "aaa?" to a name that would work, I tried "aaa" and "aaa ", but surprisingly, both of these resulted in "Object Property Not List" also.

My first thought is that the ? is not in fact a "?" but some sort of non-visible character such as a control code that somehow gets sucked into the element name when you do the paste. I'd be inclined to take the string returned by the code and split it out character by character, and test to see what the ASCII value of each one is. I'll be both surprised and puzzled if the code of the last character turns out to be either (Dec) 32 or 63.

[Harvey]

You're correct, Alan. I switched all my API string calls to the UTF8 equivalent in the API and it resolves my bug, so it's an absolutely a unicode encoding issue.

The characters show as extended ASCII characters in my program, so making it readable in whatever language it was originally intended will be the another challenge, but at least it works now.

I guess the good news is that the Flow Model Packager will support unicode properly once I'm done with these changes.

PS: Thanks to Ricky for helping me out with this bug.