behavior of (ascii) function in AutoLISP

[alex_b]

Hi

Please consider the expression (ascii char) where char is a one-character string.

If char is in the extended ASCII set, I get different results depending on the OS:

On Acad 12 running under WinXP the result is the ASCII code of char.

OTH, on Acad12 running under Win 7, the result is a string consisting of the Unicode code for the character (\U+nnnn)

Any ideas?

Thanks

alex

[martti.halminen]

AutoCAD R 12 is ancient history, and even AutoCAD 2012 is now an unsupported product.

Likewise Windows XP, and probably even Windows 7 to some extent.

So the only thing you can do is to write whatever is using the result to check the type and change its behaviour accordingly.

-- 

[alex_b]

Thank you, although your answer doesn't help much.

The question was not so much to look for a solution, but to explain the inconsistent behavior of the same Lisp function, in the same Autocad version, on two different systems.

Is there a document giving exact specifications of AutoLisp functions?

alex

[ActivistInvestor]

---

@alex_b wrote:

Thank you, although your answer doesn't help much.

The question was not so much to look for a solution, but to explain the inconsistent behavior of the same Lisp function, in the same Autocad version, on two different systems.

Is there a document giving exact specifications of AutoLisp functions?

alex

---

Is this for any character or specific ones?  If it is any character, I don't see that on AutoCAD 2012/Windows 7 or AutoCAD 2017/Windows 10.  If it's not for all characters, then indicate which characters it happens with.

[rkmcswain]

alex_b wrote:

Is there a document giving exact specifications of AutoLisp functions?

Do you mean the Developer's Guide?

There may be more details available to ADN Members, but I'm not sure.

[alex_b]

For ASCII characters (0-127) it works OK on both platforms.

The problem occurs with extended ASCII (128-255), specifically Hebrew;

I did a bit of debugging and the problem is not with (ascii). Instead:

 (strlen (setq txt "א")) outputs 7.on Win 7 and 1 on WinXP.

Parsing the string gives \\U+05D0 which is, of course, the Unicode code of א,

but why should it be different in Win7 than in XP? 

Any ideas?

[ActivistInvestor]

---

@alex_b wrote:

For ASCII characters (0-127) it works OK on both platforms.

The problem occurs with extended ASCII (128-255), specifically Hebrew;

I did a bit of debugging and the problem is not with (ascii). Instead:

 (strlen (setq txt "א")) outputs 7.on Win 7 and 1 on WinXP.

Parsing the string gives \\U+05D0 which is, of course, the Unicode code of א,

but why should it be different in Win7 than in XP? 

Any ideas?

---

I suppose that could be a bug. I don't have a copy of XP with AutoCAD installed to test with, and don't think Windows XP has ever fully-supported UNICODE. It ma also have something to do with regional settings on the system.

[alex_b]

There is no need for XP. In XP it works fine.

THe problem is under Win7.

And the regional settings are the same on both machines.