Subscribe to
Posts
Comments
NSLog(); Header Image

AppleScript, Unicode, and ecto

I've spent a few minutes writing an AppleScript for ecto that I could use tomorrow to ease my live blogging of the final round of the British Open.

I get the time, put it in bold, and then prompt myself for text. I cut off everything but the first three paragraphs and move them down to the extended entry. Unfortunately, when I grab "paragraphs 1 through 5" of the top text, it includes a final carriage return. I don't want it, so I tried to remove the character by using this line:

set body text of currEntry to ( (characters 1 through ( (length of topText) - 1) of topText) as string)

This works beautifully when I run the script within Script Editor. Yet when I run the script from the Script menu, I get text that looks like this:

<&s&t&r&o&n&g&>&1&6&:&3&5&:&<&/&s&t&r&o&n&g&>

You can see the "<strong>" in there - the & are from the Unicode nature of Mac OS X's text system. Switching the call from "body text" to "entry body" has no effect.

How can I fix this script to work from the menu as it works from the entry body?

9 Responses to "AppleScript, Unicode, and ecto"

  1. I uploaded an image of the script here. Sorry, I didn't have time to convert it to HTML for copy/paste. As text, it is:

    set currTime to do shell script "date +%H:%M"

    tell application "ecto"

    set currEntry to front document

    set dialogBox to (display dialog "New Text:" default answer "")

    if button returned of dialogBox is "OK" then

    set newEntryText to "<strong>" & currTime & " -</strong> " & text returned of dialogBox & return & return

    set body text of currEntry to newEntryText & (body text of currEntry)

    -- prepare the top text

    set topText to (paragraphs 1 through 5 of body text of currEntry) as string

    -- prepare the text to move down

    set botText to (paragraphs 7 through (count of paragraphs of body text of currEntry) of body text of currEntry) as string

    -- this works fine

    set extended text of currEntry to (botText & return & return & extended text of currEntry)

    -- the problem occurs here, but may have been set up by something earlier???

    set entry body of currEntry to ((characters 1 through ((length of topText) - 1) of topText) as string)

    else

    -- do nothing

    end if

    end tell

  2. Not totally sure if this is what's going on, but here's my theory:

    1. The "characters 1 through x" part returns a list of characters, i.e. {"", ...}
    2. The "as string" coercion is then piecing the list of characters back together with "&" as a text item delimiter, putting a copy of the delimiter between each entry in the list.

    Try putting this statement before that line:

    set Applescript's text item delimiters to ""

    and see if that gets the correct behavior.

  3. I never changed the text item delimiters, so your suggestion had no effect (and I took it back out).

    However, my script is now mysteriously working. So who the heck knows what's going on… I did install the Satimage OSAX (to try out "extract string") but I'm not using it.

  4. Does this make any difference?

    set body text of currEntry to (text 1 through -2 of topText)

    Also, you might look into using 'Unicode text' instead of 'string.

  5. Bruce, that put an & where carriage returns were. I'm thinking that Brian's trick may be the one that works, actually, as it sets them for the script and then stays that way until you re-edit (right?).

  6. Does 'topText' look right when it is first set?

    If Brian's code helped, then you most likely have another script that isn't changing the delimiters back after using them (see below).

    set ASTID to AppleScript's text item delimiters

    set AppleScript's text item delimiters to {"something"}

    -- do whatever

    set AppleScript's text item delimiters to ASTID

  7. I thought I should expand on that last statement… When run via the script menu, changes to AppleScript's text item delimiters will affect other scripts (that are also run via the script menu).

  8. That's a little odd, but not entirely unexpected I suppose. I could totally see the delimiter being stored in the script itself (like declared properties are), but I suppose the script menu could be reusing some sort of context internally. Is this the system-wide Apple script menu, or a script menu implementation within the app itself?

  9. It's the system-wide menu. I didn't know changes to the delimiters "stuck" as Bruce tells us they do. That's good to know.