Asc() is ignoring RuntimeState.Ansi

[TOchse]

Describe the bug The behavior of Asc() in not considering the current runtime setting. This leads to unexpected results when setANSI(false) is used. While Chr() chooses the encoding (WinEncoding or DosEncoding) based on RuntimeState.Ansi, Asc() does not.

To Reproduce Steps to reproduce the behavior: I included some testcode (VO-Dialect) that shows the different behavior. Testcode.txt (its .txt because .prg isn't allowed)

Expected behavior I expect the result of Asc() to be the same number, that I entered into the Chr() (while using the same RuntimeState).

Screenshots Here is a screenshot of the testcode: This is the result of this testcode:

Additional context There are 3 versions of Chr():

1. Chr(): depends on RuntimeState.Ansi
2. ChrA(): Always uses Ansi codepage
3. ChrW(): Always uses Unicode

Asc() only has 2 versions:

1. Asc(): Always uses Ansi codepage
2. AscW(): Always uses Unicode

In my opinion the current version of Asc() is actually AscA().

[RobertvanderHulst]

Can you include the test code as attachment?

[TOchse]

Here's a complete solution with the test code: Testcode.zip

[TOchse]

Is there anything else I can provide to you?

Here's a picture of the Chr() and Asc() next to each other (from XSharp.Core/Functions/String.prg) As you can see, the Chr() uses the encoding according to RuntimeSate.Ansi. Asc() on the other side always uses WinEncoding. Currently the Asc() actually looks like a (currently not available) AscA() as counterpart for ChrA().

In my opinion, the highlighted part on the right side should be replaced with the highlighted part of the left side.

It looks like you fixed it in 2019 for Chr() in this Commit.

[RobertvanderHulst]

This information is enough to solve it. We'll look into this asap.

[RobertvanderHulst]

If you're in a hurry, then you can include the code for Asc() in your own app. That function will then replace our function, until the fix has been made.

[cpyrgas]

Confirmed fixed