Hard line break: getting it into calc

[ESpringer]

One of you guru types will know:

I need to get a calc field to yield multiple lines, NOT with the &"¶"& trick, but with whatever FM uses for its own line-break stuff.

Background, in case that's not clear: I have a label-maker (brother QL-500) that doesn't interface with FM but does have its own (terrible) software, which doesn't wrap text (!) and handles pasted text oddly. (I may yet ditch it for the Dymo I saw recommended by someone here, Vaughn maybe, back in May!) I'm printing labels for articles, whose titles may be long. So I want FM to give me a calc field with line breaks in the right places, so that I can zip out a label on the fly (or on the crawl, as it turns out).

Now, if I copy from an ordinary text field with line/paragraph breaks (like my author field, where I hit return between multiple authors -- it's not a repeating field by definition), then the label-editor software uses the line break as desired. But when I specify a calc field with &"¶"& to break up my long string, the resulting text does not paste properly (The software interprets this as requests for multiple label records, one for each line). So, I'm quite sure that FM marks this difference between two kinds of line-break in a way that makes it onto Mac Os X's clipboard.

Any ideas about how to get the result I want (besides ditching the QL-500, which I'm on the verge of doing!)?

Thanks! And hello to anyone who remembers me from many moons ago!

Edited October 11, 2007 by Guest

[comment]

I believe your basic premise is wrong. I suggest you try it the other way round: type a line break into your label-editor software, copy it and paste it into your formula.

[ESpringer]

Comment: Thanks, but I had spared y'all the gory details which explain my approach. The software (P-Touch Editor) doesn't accept PASTE into the actual label space. Believe it or not. Only typing. (This is surely a bug, but I'm wondering if I can get past it.)

However, it has a merge-with-database function, and I can paste into its spreadsheet-like representation of an imported database in order to EDIT my imported data. (Alas, it imports only CSV and tab-delimited ASAIK, so I can't import things with line breaks already included. And anyway, I don't want to rely on importing, b/c I want to do one-off prints easily.)

OK, so I'm pasting my data into their spread-sheet like grid so that it shows up on the label as merged data. And it won't let me manually add line-breaks within that grid, because it's taking all variations on return/enter (with or without modifier keys) as "go to next row" commands.

You see why I'm asking for the way to get the other kind of carriage return out of FM?

(BTW, I did find reference online to someone who figured out how to embed the CR code within a CSV line so that the editor would import multi-line fields, but alas the source didn't say how. If anyone knows a standard thing to try (besides n, which I tried), I'd be happy to hear it!)

Edited October 11, 2007 by Guest
added PS about embedding CR in CSV

[Fenton]

I remember you -], and your intense calculation method to create a checksum from found set IDs.

I cannot see what you describe. But I wonder what would happen if you passed it through AppleScript? You could run a Perform AppleScript step from a button.

tell application "FileMaker Pro Advanced"

set Add_block to cell "_cAddressBlock" of current record

set the clipboard to Add_block

end tell

[Ender]

Hey Elise,

I don't know if this is something you've already tried (or if it would work), but maybe try a global text field, and enter a in it. Then use that field as the separator in the calc.

[Fenton]

When you export as CSV, the FileMaker in-field return is exported as ASCII character 11. Does this not work for a database merge to your program? If not I wonder what it would want? You can fairly easily set it to anything you want, with an AppleScript find/replace.

Another possibility is the Repeating field separator, which is ASCII character 29. Here's a basic AppleScript find/replace script. (It is actually very clever, by one of the experts at MacScripter. It is sort of like pasting into a formatted field, in that it preserves the encoding of the text (string or Unicode). But maybe in your case you want to force it to string. You could just use "as string".

It's hard to say what is needed, trial and error.

tell application "FileMaker Pro Advanced"

set Add_block to cell "_cAddressBlock" of current record

set add_fixed to my switch(return, ASCII character 11, Add_block)

set the clipboard to add_fixed

end tell

on switch(char1, char2, str)

-- switch char1 to char2 in str

set od to AppleScript's text item delimiters

set AppleScript's text item delimiters to char1

set temp to text items of str

set AppleScript's text item delimiters to char2

tell temp to set temp to beginning & ({""} & rest)

set AppleScript's text item delimiters to od

return temp

end switch

[comment]

Some of these 'gory details' are crucial, and I am still unclear on the entire process - esp. the part about "spreadsheet-like representation of an imported database". Perhaps you should give us a step-by-step description.

One thing I am reasonably sure of: when you copy from a Filemaker field containing carriage returns, the character separating the individual paragraphs is exactly the same as the one used in TextEdit, for example. So the problem must be elsewhere.

[ESpringer]

Hi Fenton, Ender, and all... thanks for all the suggestions! Being lazy, I jumped on Ender's point. Indeed, the gReturn field trick works, and I should have thought of that, but was so frazzled with the whole printer process that my brain ground to a halt. I'm still not sure I'll continue using the brother QL-500 -- in my opinion, it doesn't deserve Mac customers, but at least I can make it work without so much mousing around...

Cheers!

[comment]

OK, if this is true, then I wish someone would show me a way - any way - to tell the difference between the results of the two calculation fields here.

CRdiff.fp7.zip

[ESpringer]

Comment is right. How embarrassing to have called on the wisdom of FMForum experts over a non-issue...

Explanation: the apparent difference was an artifact of two ways I pasted, without recognizing that the P-Touch Editor software database interface (into which I was pasting) cared about whether I had a text cursor *in* a cell or was merely *at* a cell. It does not allow returns to be typed in a cell, but it does accept pasted returns within a cell, provided the cursor is already blinking in a cell when the paste happens; if the target cell is highlighted but without a text cursor, any tabs and returns in pasted text causes spreadsheet-like occupation of neighboring columns and rows, right and down.

The psychological piece of the explanation is that this software had so many *other* bad design features (on the Mac side at least) that I was all-too-willing to believe that it was going to thwart all reasonable efforts.

, :

[Ender]

Thank goodness! Now comment can go home knowing that a ¶ is a return, and all is right in the universe. Whew, that was a close one!