Just confirmed with Softpress – if you use the fwBigPrompt, the text stream it returns will always contain Mac Classic line-endings.
Whether or not you see this depends a lot on which text editor you use and whether you are using this text first in your output code or not.
The TemplateHelper Action just got a nice makeover last week and that exposed the problem to me. I added a way to “wrap” the partial files created by that Action with a little header and footer code. To do that, I used the fwBigPrompt to open up a new text window for editing. When the result of that window was added to the fwItem with fwAddRawln or fwAddRaw, the result was a mixed up file containing a mix of Unix and Classic Mac linefeeds, and BBEdit showed it to me as four lines of nicely indented PHP followed by one long line of HTML punctuated with upside-down red question marks where the line-feeds used to be.
I tried fixing this with fwConvertLineEndings = true, but it had either no effect or the wrong effect – converting everything in the partial to Mac linefeeds instead of the document’s preference of Unix.
For some reason, this problem just doesn’t seem to happen if the code you are inserting appears after the file has started, but if you are inserting text from fwBigPrompt as the very first characters of a text file, you will see this problem.
To work around this, Joe Billings suggested that I force the fwBigPrompt text into the required format using a regular expression. So here’s what I ended up with:
function addComment(thisObj){
var test = thisObj.fwToHTML();
if(test.match(/rn/)) filter = 'rn';
if(test.match(/r/)) filter = 'r';
if(test.match(/n/)) filter = 'n';
var startComment = fwParameters.before.toString().replace(/rn|r|n/gi, filter);
startComment.fwConvertLineEndings = true;
var endComment = fwParameters.after.toString().replace(/rn|r|n/gi, filter);
endComment.fwConvertLineEndings = true;
if(startComment.length + endComment.length > 0){
var dummy = thisObj.fwAddEnclosing("",true);
var c = dummy.fwAddRawln(startComment);
dummy.fwMove(thisObj,c);//this puts the comment first
dummy.fwAddRawln('');
dummy.fwAddRaw(endComment);
return thisObj = dummy;
}
return thisObj;
}
This works, and it’s been testing consistently here.
I recall having to do this in the past but did so slightly differntly by
splitting the input into an array and then asking Freeway to add each line as a
fwAddRawln (which should append the correct line ending).
Looking forward to seeing this fixed in the application though.
Regards,
Tim.
Just confirmed with Softpress – if you use the fwBigPrompt, the text stream
it returns will always contain Mac Classic line-endings.
Whether or not you see this depends a lot on which text editor you use and
whether you are using this text first in your output code or not.
The TemplateHelper Action just got a nice makeover last week and that exposed
the problem to me. I added a way to “wrap” the partial files created by that
Action with a little header and footer code. To do that, I used the
fwBigPrompt to open up a new text window for editing. When the result of that
window was added to the fwItem with fwAddRawln or fwAddRaw, the result was a
mixed up file containing a mix of Unix and Classic Mac linefeeds, and BBEdit
showed it to me as four lines of nicely indented PHP followed by one long
line of HTML punctuated with upside-down red question marks where the
line-feeds used to be.
I tried fixing this with fwConvertLineEndings = true, but it had either no
effect or the wrong effect – converting everything in the partial to Mac
linefeeds instead of the document’s preference of Unix.
For some reason, this problem just doesn’t seem to happen if the code you are
inserting appears after the file has started, but if you are inserting text
from fwBigPrompt as the very first characters of a text file, you will see
this problem.
To work around this, Joe Billings suggested that I force the fwBigPrompt text
into the required format using a regular expression. So here’s what I ended
up with:
function addComment(thisObj){
var test = thisObj.fwToHTML();
if(test.match(/rn/)) filter = 'rn';
if(test.match(/r/)) filter = 'r';
if(test.match(/n/)) filter = 'n';
var startComment = fwParameters.before.toString().replace(/rn|r|n/gi,
filter);
startComment.fwConvertLineEndings = true;
var endComment = fwParameters.after.toString().replace(/rn|r|n/gi,
filter);
endComment.fwConvertLineEndings = true;
if(startComment.length + endComment.length > 0){
var dummy = thisObj.fwAddEnclosing("",true);
var c = dummy.fwAddRawln(startComment);
dummy.fwMove(thisObj,c);//this puts the comment first
dummy.fwAddRawln('');
dummy.fwAddRaw(endComment);
return thisObj = dummy;
}
return thisObj;
}
This works, and it’s been testing consistently here.