On Mon, 13 Sep 1999, Dominique Busso wrote:
>
> Our app (MC 2.2.4) is generating a text file, that is text characters and
> a "special" character for "end of line" (linefeed (10) for instance).
> Step 1: we run the App on MacOS, generate the file -> file1
> Step 2: we run the same App on Windows, generate the file -> file2
> When we copy file1 on Windows and opened it: it's not the same as file2
> (for instance file2 will ave good end of lines, but file1 will display 1
> line with the special character..
> -> is there any differences made by MetaCard when running on MacOS or
> Windows?
> -> or am I missing something very obvious here?
For historical reasons (its UNIX heritage), MetaCard always uses LF
(ASCII 10) as the line delimiter internally. For compatibility
reasons, this is mapped to the token "return", which is CR (ASCII 13)
which is the MacOS line delimiter. Windows and some Internet
protocols (including HTTP/HTML), uses the CRLF pair of characters as
the line delimiter.
So, obviously some translation needs to be done when dealing with the
OS or other apps on a particular platform. MetaCard does this
automatically when cutting and pasting text between apps, and when
reading and writing files opened with the default "open file" command
and the "file:" URL type. You can override this behavior by adding
"for binary read | write | update" to your "open file" commands, or
using the URL type "binfile:". But it's then your responsibility to
provide whatever translation is required (use the replace command with
numToChar() to do it) if you want the file you produce to be readable
by other apps on the target platform.
Regards,
Scott
> Thanks!
>
> Dominique Busso
>
> OpenMind International
> http://www.openmind.fr
> ______________________
>
********************************************************
Scott Raney [EMAIL PROTECTED] http://www.metacard.com
MetaCard: You know, there's an easier way to do that...
