ASCII junk at EOL's in text fields

[Hijack]

Hey ya'll.... Who might know why, when pushing a record back to a database from an IWP client, carriage returns in text fields show up in the full desktop FM client as having ASCII 13 (carriage return) *and* ASCII 10 (line feed) appended to the end of each line? The full FM client shows ASCII 10 as an open character (usually a square in most font sets). So, the end result is a pretty ugly text field content on records that were touched and updated from any IWP client.

Anyone know how to correct this issue or if it is a problem with the IWP interface that I shouldn't bash my head against the wall trying to overcome?

Thanks!

[Attiton]

I know this request is stale...but I've been having this trouble for almost a year, and today I seem to have found a workaround, so I want to post an answer!!

All fields that will contain carriage returns (as entered through IWP) need to have the following auto-enter calculation appended (replace existing value, evaluate always):

If ( PatternCount ( YourFieldName ; ¶) = 0  ; YourFieldName ; Substitute ( YourFieldName ; Middle ( YourFieldName ; Position ( YourFieldName ; ¶ ; 1 ; 1) ; 1) ; ¶ ))

FM replaces the Mac carriage return with a Windows carriage return, believe it or not and the little empty ascii-10 characters disappear!!!

I hope this response serves...