A pair of tips for converting between RS Cocoa/Carbon and XOJO Cocoa
Default Line Endings Have Changed for OSX.
A reminder to those who need to work cross platform and/or do their own parsing of text. We always had to deal with the difference between OSX, Windows, and Linux line endings.
The transition of XOJO to building for Cocoa as a default has changed the default EndOfLine for Mac Cocoa builds.
RS OSX builds (both Carbon and Cocoa) previously used CR as the line ending. It is now LF for XOJO Cocoa builds.
Text parsing code that previously worked under both Carbon and Cocoa (with RS) may now break when XOJO makes a Cocoa build.
If you use WriteLine and Readline to work with lines of text in a file, the various possible CR, LF, CRLF endings are handled for you. However, if you readAll and split the lines in your own parser, you will see problems if writeLine now writes a different line ending than your parser expects.
You could simply change your parser to expect the new line ending, but you would still have a problem with data written by old versions of your app.
One work around is to always replace line endings before you parse a string. Something like…
s=ReplaceLineEndings(TextField1.Text,EndOfLine.Unix)Another place that line endings has changed is TextArea. You may need to ReplaceLineEndings of TextArea.text to ensure continued compatibility with your old code.
I recommend searching your old apps for instances of “WriteLine” and verifying the associated reads are expecting and can handle alternative line endings.
Default Encodings are No Longer Defaulted for Some Items That Previously Received a Default Encoding
Under XOJO Cocoa builds, you may see some “garbage” characters appear in text fields. Those are probably due to the encoding of a string being NIL.
We always had to explicitly handle encoding for things like socket.read data, but there may be new sources of strings with NIL encoding.
Once example is memoryBlock.StringValue.
Previously, memoryBlock.StringValue was assigned a default encoding. It is now assigned a NIL encoding. If you use memoryBlock.StringValue, be sure now to define its text encoding before using the resultant string.
There may be other text sources that have lost their default encoding. If your app starts showing odd chars, trace back the source of your string and add code to explicitly handle or set text encoding.