I have a large block of text in a TEXT field in MySQL. Line breaks are by \r. If I query in MySQL and view in any normal text viewer, such as textwrangler on Mac, it shows clearly as \r. In Servoy the text is showing as one big 5 yard-long string; also, in servoy, if I type a return, it shows up in MySQL as \r, and also renders in in Servoy visually as a return. There seems to be no difference between existing \r in MySQL and \r typed into a servoy field, yet the already present \r chars are not showing in Servoy visually as a return.
Any ideas? I’m using MySQL 5.1 and Servoy 5.1.2.
Make sure you only use fields that support multi-line (for example TEXT_AREA type) for a data provider in Servoy if you can have multi-line content in it.
For example if you use a TEXT_AREA to input the content and a TEXT-FIELD to display it, in the TEXT-FIELD it will be flattened into one line - and that can end up being committed into the DB.
It is a TEXT_AREA now, I did manage to figure that out. Now it wraps the text into one giant block, but still does not recognize the carriage returns (\r). Again, if I type a return into the field in Servoy, it recognizes that return and saves it into MySQL as \r; but the other \r that were there already are not recognized in Servoy. Thanks for the response.
So it turns out that unless you have \r\n as the carriage return in a text block, Servoy doesn’t display it as a line break in a TEXT_AREA. I did a test replace on a record and it displayed perfectly once the \r chars were changed to \r\n. Just posting in case someone else comes along and needs to know my route to solution.
Also, as posted in another place on the forum, you have to set the scrollbars - horizontal to never to make the text wrap where there isn’t a carriage return.
jmcneely:
So it turns out that unless you have \r\n as the carriage return in a text block, Servoy doesn’t display it as a line break in a TEXT_AREA. I did a test replace on a record and it displayed perfectly once the \r chars were changed to \r\n. Just posting in case someone else comes along and needs to know my route to solution.
This might well depend on your platform.
\r\n is newline for Windows, in Unix/OS X \n is enough (in old Mac OS it was \r).
You can use the java.lang.System.getProperty(“line.separator”) to know what your platform line separator is.
We’re a Mac shop, although there will be some cross platform use, I imagine. This was all occurring on the Mac.
I did try to input text in TEXT_AREA for a Sybase text column in both Mac OS X and Win. Then I saved it and restarted client.
After restart when I went to that record it looked ok in both cases.
So as long as you are using only TEXT_AREA controls for that column it should be ok…
Or isn’t this what you are trying to do? Did you already have multi-line content in the DB that was not entered by Servoy? In this case it’s strange as you say that what Servoy is saving to the DB is using \r exactly as the content you had before. So there should be no difference on how they are interpreted by the text area when queried back. Are you sure end of line chars are exactly the same as saved by Servoy?
What happened is that when I put the text straight out of the db into TextWrangler, and made it show the invisibles, it showed a single character as the return. I did a search for \r to make sure I was seeing that right and it showed the instances of \r which coincided with the carriage returns. Naturally I assumed that they were all completely \r. Really, the ones entered by Servoy were actually \r\n. you almost have to go into a HEX editor to work with these squirrelly carriage returns. The discovery is, \r\n seems to be what Servoy is looking for.