Ben, Thanks for the clarification... I *knew* I'd forgotten something... As for your comment about "CRLF", VB has that as a constant (vbCRLF), so why shouldn't MetaCard? ;-)
Ken Ray Sons of Thunder Software Email: [EMAIL PROTECTED] Website: http://www.sonsothunder.com/ ----- Original Message ----- From: "Ben Rubinstein" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, October 31, 2001 12:46 PM Subject: Re: Mac-text > on 31/10/01 3:54 PM, Ken Ray at [EMAIL PROTECTED] wrote: > > This has to do with the fact that the Mac uses a carriage return/line-feed > > combination (CRLF) at the end of each line, and Windows generally uses just > > LFs (or is just CRs? I can't remember right now). CRs are ASCII 13, LFs are > > ASCII 10, BTW. > > > >on 31/10/01 10:18 AM, Signe Marie Sanne at [EMAIL PROTECTED] wrote: > >> Could someone please enlighten me as to why ordinary text (no formatting) > >> uploaded via ftp to a server behaves perfectly when uploading it from > >> Windows, whereas on Mac all returns have disappeared and been replaced by > >> lots of boxes? This is with MC2.4. > > T'other way, actually. Mac standard to represent a line break is CR; Unix > standard is LF; DOS/Windows standard is CRLF. Things like this that make me > despair of ever achieving standards... > > This is essentially (correct me if I'm wrong) the difference between 'open > file for text' and 'open file for binary', or 'URL "file:/...' and 'URL > "binfile:/...' - in each case, the first formulation instructs MetaCard to > automatically scan the data, and convert all instances of CR or CRLF to LF. > > Virtually any FTP application will have the same facility, and have a > setting that allows you to choose whether to transfer files in Text or > Binary mode (often also some sort of 'automatic' mode in which it guesses > whether a file is binary or text). So the real question is, using the FTP > facilities in MC 2.4, is there a way to specify a similar switch? Or does > the FTP library always transfer in Binary mode? > > > Meanwhile, slightly off the original poster's question: > > CRs are ASCII 13, LFs are ASCII 10, BTW. > Correct - but bizarrely, MetaCard defines constants named "CR" and "return" > to have the value 10, instead of 13. A subtle gotcha for HC users who deal > with binary data, and a wind-up (IMHO). You have to define your own > 'constant' if you really want to deal with CR. I can (grudgingly) accept > the definition of 'return' as linefeed; but defining a new constant "CR", > with the wrong value, is just rubbing salt in the wound. Was this inherited > from some other xTalk? I suppose it's too late to appeal for a change in > the value of "CR"; but how about at adding a couple of new constants, > "asciiCR" with value 13, and "CRLF" with the value being a two-character > string, codes 13 and 10? > > > Ben Rubinstein | Email: [EMAIL PROTECTED] > Cognitive Applications Ltd | Phone: +44 (0)1273-821600 > http://www.cogapp.com | Fax : +44 (0)1273-728866 > > > > Archives: http://www.mail-archive.com/[email protected]/ > Info: http://www.xworlds.com/metacard/mailinglist.htm > Please send bug reports to <[EMAIL PROTECTED]>, not this list. > > Archives: http://www.mail-archive.com/[email protected]/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
