ASCII 10 is equal ASCII 13 (0A changed into 0D)

[3d-swiss]

Code: Select all

   if (numToChar(10) = numToChar(13)) then 
      beep 
   end if

I need the Linefeed for Windows with (Hex-Code) 0A 0D. But I only get 0D 0D.
The Command numToChar(10) generates an 0D. I always get an Beep on my text button.

I got the result in the IDE as well in App for Mac and Windows. (LC 5.0.2. MacOS X 10.7.2)

What can I do?
Is there an other command for using ASCII or Hex-Code?

[3d-swiss]

the commend RETURN also generates as Code only 0D

[FourthWorld]

The "cr"/"return" constant is an anomaly in the language derived from its HyperTalk heritage. The LiveCode engine first premiered on Unix systems, where ASCII 10 (linefeed) is the common line-ending. But since the language was inspired by HyperTalk, which was Mac-only and Macs used ASCII 13 as their line-ending, the constant "cr" and its synonym "return" were mapped to the Unix line-ending.

Internally, field objects use linefeed (ASCII 10), and reading/writing for platform-specific implementations is flexibly supported:

To have line-endings automatically remapped, simply use "open file <filename> for read", and no matter which OS it was created on the data will have its line-endings converted for you.

If you want to preserve the OS-specific line-endings, you'll need to specify a binary read with "open file <filename> for binary read".

FWIW, you can get the two-character Windows line-ending with the constant "crlf". If you need to find a true CR (ASCII 13) you'll need to use "numtochar(13)". In LiveCode, the constants "cr" and "linefeed" are anomalously synonymous.

[3d-swiss]

Hi FourthWorld,

I need ASCII 10 (0A) for my export in a text file.

My test looks like this:

Code: Select all

repeat with tCounter = 8 to 13
   put tErgebnis & numToChar(tCounter) into tErgebnis
end repeat

The result as Hex Dump (by BBEdit) shows:
08 09 0D 0B 0C 0D (the 0A is missing!!)

Correct is:
08 09 0A 0B 0C 0D

So, it is a bug in LiveCode 5.0.2!

The constant CRLF creates '0D 0D' instead of '0A 0D'.
It's a bug too.

I also tried to use MacToISO before export, but I get 0D 0D again.

What I can I do?

Best regards from switzerland.

[FourthWorld]

Here I get the expected string using:

Code: Select all

on mouseUp
  repeat with tCounter = 8 to 13
    put numToChar(tCounter) after tErgebnis
  end repeat
  --
  repeat for each char k in  tErgebnis
    put baseConvert(charToNum(k),10,16) &" " after tOut
  end repeat
  put tOut
end mouseUp

Result: 8 9 A B C D

Note that the original line, "put tErgebnis & numToChar(tCounter) into tErgebnis", causes the current value of tErgebnis to be replicated each time through the loop in addition to whatever new value is being added.

Not sure if that was the source of the problem you experienced, but using the snippet shown here seems to get you what you're looking for.

[3d-swiss]

Hello Fourthworld,
you made my day.

So I see, there is no bug in LC. Now I get "10 <> 13"

Code: Select all

   if (numToChar(10)=numToChar(13)) then
      put "10 = 13"
   else
      put "10 <> 13"
   end if

But my mistake was to use the wrong export command "into url ("file:" & tFileName)
instead of

Code: Select all

put field "fErgebnis" into url ("binfile:" & tFileName)

Now I found the explanation on page 340 in the user guide.

I get my 0A as need to. And thanks for the tip to use 'after' instead of put tErgebnis & ... into tErgebnis.
(I came from 4th Dimension where a lot of commands like 'after' do not exist. It will take time to forgot the old way of programing and to learn a new one

Thanks for your answers.

Best regards.

[3d-swiss]

There is one problem left:

By using

Code: Select all

set the clipboardData["text"] to field "fErgebnis"

I get (again) only 0D instead of 0A.

How can I stop the converting using the clipboard?

[FourthWorld]

You may need to do a replace on the field string before setting the clipboardData.

[3d-swiss]

I tried to convert ASCII13 to ASCII10 before or in the clipboard. See my stack in attachment.
When I check the result within LC: it's ok.

But when I put the clipboard to Textedit and check the Hex Dump (see image), then I will get again only ASCII 13 instead of ASCII 10.

[FourthWorld]

I tried to convert ASCII13 to ASCII10 before or in the clipboard. See my stack in attachment.
When I check the result within LC: it's ok.

But when I put the clipboard to Textedit and check the Hex Dump (see image), then I will get again only ASCII 13 instead of ASCII 10.

img1.png

Could the app used for hex editing be altering that? When I run your stack I see the bottom field contains:

58 A 59 A 5A

So it seems there is no ASCII 13 in the field data at all.

In fact, consistent with LiveCode always using ASCII 10 for line endings in fields, when I check this line in the Message Box:

put numtochar(13) is in fld "fEingabe"

...I get "false".

[3d-swiss]

The goal is to use a program, with generates an QR-Code. For that I need as Return Hex 0A.

In LiveCode the Return is Hex 0A, as I could show with my small stack.

But if when I use the text generated with LC via clipboard and put it in ANY program like Textedit, BBEdit and so. My Hex 0A becomes 0D, as I show by the hex dump of BBEdit.

So, there is problem with the text in the clipboard, which is transformed by pasting it.

I still believe, that's a LiveCode problem, because, when I generate the text from LiveCode in a text file and open it, do copy and paste, than I still have my Hex 0A in the text (checked by HexDump and my QR-Code works fine).

[jacque]

If the engine is translating the clipboard, then you can do a replacement yourself:

get the clipboardData["text"]
replace numToChar(10) with numToChar(13) in it
set the clipboardData["text"] to it

Untested, but logically it should work.

[FourthWorld]

The goal is to use a program, with generates an QR-Code. For that I need as Return Hex 0A.

In LiveCode the Return is Hex 0A, as I could show with my small stack.

But if when I use the text generated with LC via clipboard and put it in ANY program like Textedit, BBEdit and so. My Hex 0A becomes 0D, as I show by the hex dump of BBEdit.

So, there is problem with the text in the clipboard, which is transformed by pasting it.

I still believe, that's a LiveCode problem, because, when I generate the text from LiveCode in a text file and open it, do copy and paste, than I still have my Hex 0A in the text (checked by HexDump and my QR-Code works fine).

If you generate the text using binfile instead of file, you should get the exact data in the field.

Since LiveCode displays the data correctly within its own environment, it would seem the problem lies elsewhere.

[mwieder]

3d-swiss-

I inserted the line

Code: Select all

put tErgebnis into url ("binfile"/home/mwieder/test.txt")

opened the text file with hexedit, and got exactly what you see in the the output field.

The problem I think you're seeing is that different operating systems use the line-ending characters in different ways. Your original post here mentioned Windows, but then you're talking about TextEdit and BBEdit.

Windows: crlf
OSX: cr
linux: lf

So I think what's happening is that the text editor you're using on OSX is helpfully converting the line-ending characters for you. I don't see this problem on linux because linux uses hex 0A as a line-end character. I'm sure if I tried this on Windows (I don't have one of those systems in front of me at the moment) I'd see a Windows text editor converting the clipboard data into a crlf pair for me.

[kdjanz]

BBedit actually has preferences to deal with line endings and can write any of the 3 if you opt to go one way or the other. Being a Mac program, it does what it needs to do to show you the file on the screen, but it has intelligent reading and writing for dealing with files from disk.

Check your preferences on BBedit.

Kelly