writefile - problem with CR's

[hwinther]

HI,

I stumbled into a problem when I write text to a file. Irrespective of which format I choose for the ascii file, when I open it with Notepad everything comes out on one line. With Word/Wordpad it looks fine. Whether it is FileMaker, ScriptMaker og me that is the problem I don't know but can anyone help me out? The application that is supposed to import the file requires it to be correct. If I fix it manually in Notepad it works fine, but of course that is not feasible for an automated interface.

The text I am exporting looks something like this:

Set Variable [$text_export; Value:$text_export & ...stuffdeleted... & "","",0,"",0¶¶"]

Theoretically that should result in a blank line between this one and the next, but only if I view the file in WordPad. Is there a CR character missing or???

BTW for FM server platforms the list of choices are a little inadequate - we run FM server 10 on Windows Server 2008 which is not an option in the profile. Anyone know where to propose this changed?

[TheTominator]

The manner in which you are exporting this text data will have a direct effect on how the field's line endings are handled.

How exactly are you exporting this information to a file?

Export records from the file menu?

Export Field contents?

Something specific using ScriptMaster (the third-party plug-in in whose forum section you have posted)?

[hwinther]

I am indeed using ScriptMasters WriteToFile function, so everything is stored in a text string which is then written at the end.

I need a plain text iso-8859-1 or windows-1252 encoded file. I have verified that the encoding works ok only problem seems to be the missing CR's or whatever the problem is.

Edited April 6, 2010 by Guest

[TheTominator]

The problem is either the internal encoding for the ¶ or the line ending convention for the writetofile command. From the tools you are using, it is difficult to tell them apart.

When FileMaker exports to an ASCII file (e.g. tab-delimited or comma separated), the ¶ in a text field will come out as an ASCII vertical tab. It could be that the writetofile command is passing this encoding straight through to the output. NotePad will show empty rectangles in place of these vertical tab characters. WordPad will treat these as line endings.

If the writetofile command creates a text file with UNIX standard line endings (ASCII linefeeds) instead of DOS standard line endings (both carriage return and linefeed). NotePad will display these linefeed characters as empty rectangles whereas WordPad

will treat these as line endings.

Try opening up the text file in Mozilla Firefox. (Name the file to end with .txt and use Open File from the File menu.)

If the ¶ is being encoded as a vertical tab, Firefox will show only one line of text. If writetofile is making it into a UNIX line feed, then Firefox will show multiple lines as intended.

Edited April 6, 2010 by Guest

[hwinther]

I looked at the file using HexView. It seems that the output being produced is only ASCII-10 and not ASCII-13 + ASCII-10 as is expected of a DOS file. I checked the output format used - it is still windows-1252 encoding. I tried changing from the built in FileMaker symbol to Char(13)&Char(10) - but the WriteToFile function simply changes that to 2xASCII-10.

[hwinther]

I have now solved the problem by adding the following lines after writing the file:

Set Variable [$newfileName, Value:Substitute ($fileName, "", "/")]

Set Variable [$command, Value:"unix2dos " & $newfileName]

Set Variable [$writefile, Value:RunShellScript($command)]

This solves the problem, which seems to be that irrespective of whether you choose a windows native format, WriteToFile will still write unix-style line feeds.

unix2dos is a freeware format converter which replaces the unix ASCII-10 with windows ASCII-13+ASCII-10

RunShellScript is another ScriptMaster function.

Edited April 7, 2010 by Guest