EndofLine versus chr(13) problem

Getting Started
1

Hi, I am working on a desktop app on a Windows machine, although I generally prefer to work on my Mac. I need to get text into the app and I have three ways of doing that. I can create a WordPad .txt file and use folderItem and textinputstream, or I can copy the text of the file and paste it into a Text Area, or I can run TeamViewer or Logmein or something similar and copy paste text from a Mac text document across to the Windows Text Area. I then take the text into a ListBox and on into a database and I also work the other way round taking database text into the ListBox and then to text files or into the Text Area. I have been having some baffling problems with extra blank lines appearing in the Listbox for example.

Now I usually define strings tab and cr as chr(9) and chr(13) but today I thought I would try to improve on that and defined eol as EndofLine instead. I then had problems with several of my methods and I noticed that when I added an eol to a string the string added two bytes instead of one. On checking the reference manual I find that Windows uses two bytes to end a line - chr(13) AND chr(10). Why on earth do they do that?

I don’t really want to rewrite all my methods if I can avoid it. The cr = chr(13) definition has worked 95% of the time and the odd problems I have had could easily be due to the invisible extra line-end bytes in Windows. The simplest way would be for me to chuck out any chr(10) bytes as part of the parsing process. What’s the best way to deal with this?

2

Use ReplaceLineEndings to turn all Windows line endings into EndOfLine.Unix before using the data.

3

In the printer you needed two commands for a new line.
Chr(13) moves back to beginning of line.
Chr(10) than moves to next line.

4

Function EOL() As String // return a platform specific EndOfLine #If TargetCarbon Return Encodings.UTF8.Chr(13) #ElseIf TargetCocoa Return Encodings.UTF8.Chr(10) #ElseIf TargetWin32 Return Encodings.UTF8.Chr(13) + Encodings.UTF8.Chr(10) #ElseIf TargetLinux Return Encodings.UTF8.Chr(10) #Else // raise new PlatformNotSupportedException Return "" #EndIf

5

[quote=270348:@Christian Schmitz]In the printer you needed two commands for a new line.
Chr(13) moves back to beginning of line.
Chr(10) than moves to next line.[/quote]

Which is EndOfLine.Windows BTW.

6

@Joost Rongen That is what endofline does for you.

7

"The end of line String for the platform being compiled. " that’s what the documentation says, indeed you’re right. No need to have the function I added above, just use EndOfLine.

8

It is safer to use ReplaceLineEndings before as you may be importing a file generated from another platform.

9

[quote=270348:@Christian Schmitz]In the printer you needed two commands for a new line.
Chr(13) moves back to beginning of line.
Chr(10) than moves to next line.[/quote]

actually today a printer does not “need” this… it stuck around in windows especially to originally maintian the ability to use ASR33 teletypes https://en.wikipedia.org/wiki/Teletype_Model_33

10

Thanks guys, that’s given me a lot of help

11

One more quick question. Rather than keep defining tab and eol in all the methods, now that I have switched to the UNIX line ending (Chr(9)) I have tried to define these in the two main classes I am using (myListbox and myTextArea). I have used the Insert button to insert constants in the classes and have eol as default value chr(10) as string and public and tab as default value chr(9) as string and public. Unfortunately, my methods are not finding these values. Am I missing something here?

12

That is Tab. Unix line ending is chr(10).

Why do you need to create a new EOL constant when EndOfLine and eventually EndOfLine.Unix is already here ?

13

Thanks Michel, sorry chr(9) was a typo in my post but I entered it correctly in Add Class Constant.

Firstly, I want to add more than just eol for EndOfLine.Unix to the list of constants such as tab, or perhaps ktab at the moment.

Secondly, it makes the code less cluttered but I can still understand it instantly when I revisit it.

Thirdly, I know xojo is supposed to allow me to define public constants in a window or a class but I can’t find anything in the documentation that makes it clear how to do this so it works.

I guess I could declare the constant in the open event of the window or my class, but that wouldn’t make it public, would it?

I just want to be able to refer to ktab, keol, kwhatever in as many methods and events as I can without cluttering up the code.

14

make a module
add them globally to that module then use them throughout your project

15

Well thanks, but that doesn’t explain why it isn’t working when I insert the constants in my Listbox class, for example. I would insert them in a module the same way. An additional module seems superfluous.

16

If you have constants defined in a Listbox subclass then they aren’t necessarily defined for use elsewhere
They’re basically only for that listbox subclass

If you want them to be global then you need to define them in a module - but if you forget to put that module in other projects then they wont exist

This has everything to do with Scoping

A module is the only means to be able to make it truly global.

17

OK, thanks, I’ll try that then, but almost all of the relevant methods are in the myListbox class, where Ihave added the two constants, so I am still not going to understand what I have done wrong there or why they are not working in an instance of the class

18

If you added the constants to the subclass, myListbox class, then they should just work

Would have to see the code to know why they dont

19

Chr() is a function. You cannot use a function to define a constant. Your constant ends up being the string “chr(10)”, seven characters, not a single character with the byte value 10.

20

That would explain the problem, Tim. Thanks. Is there any way I can define ktab as a constant string equal to the chr(9) character without using the chr() function?