BBedit won't take variable input!! Ack!

[neuby]

Ok folks - I am going insane here! Just to make sure that the problem was not in some surrounding code (like where the BBedit tell was placed), I moved all of the BBedit stuff to its own handler, passed the variables to that handler then tried it there.


on grep_it(current_name, new_item_name)
tell application "BBEdit 6.5"
activate
if current_name = "CBB91F15-10D9-4A91-9C6D-84F29E93F44F" then
beep 2
display dialog ("The string is correct")
end if
--set current_name to "CBB91F15-10D9-4A91-9C6D-84F29E93F44F"

replace current_name using new_item_name saving yes searching in alias "Macintosh HD:Usersld_bfindlay:Sites:" options {search mode:grep, case sensitive:true, match words:false, extend selection:false, showing results:true}

end tell
end grep_it


The above code does display the dialog - indicating that this handler sees the correct string value, yet fails on the replace. (BBedit activates, cranks through the files, but fails to find or replace anything - no results window pops up.)

However, if i uncomment set current_name to "CBB91F15-10D9-4A91-9C6D-84F29E93F44F", just before passing it to the replace command, it works! Holy Crap Batman - it is THE SAME value!! Tested by the if logic. If I set it manually, it works, if I set it by passing the variable into the handler, it doesn't! (Course without accepting the variable, the entire script is useless!!)

-Brick walled on this one.

 

[neuby]

Hmm - progress, of a sorts. I have found the part in the script that is screwing things up. Just don't understand WHY or HOW it is screwing it up.

Before I call the BBedit code, I trim the extension and the "." off of the filename that I am replacing, as per:

tell application "Finder"
set extension to name extension of this_item
set trim_count to (count of characters in extension) + 1
set current_name to (characters 1 thru ((count of characters in current_name) - trim_count) of current_name) as string --trims the extension off the filename
set the parent_container_path to (the container of this_item) as text
--set grep_target to (container of (container of (parent_container_path as alias))) as string --use two levels up from current folder as grep path
set new_item_name to new_item_name as string
end tell


If I call the BBedit code BEFORE this tell statement, it DOES work - mind you it is finding "CBB91F15-10D9-4A91-9C6D-84F29E93F44F.html" and replacing it with 'entry1". (Not the behaviour I want, but it does demonstrate that the BBEdit code appears to function)

However, If I place the call AFTER I strip the extension and dot from the filename, it fails.

the line that appears to screw things up is

set current_name to (characters 1 thru ((count of characters in current_name) - trim_count) of current_name) as string --trims the extension off the filename

Now - to my mind, this first turns current_name into a list of characters, but it then coerces it back to a string.

Recall, that I put a checking if statement in the code

if current_name = "CBB91F15-10D9-4A91-9C6D-84F29E93F44Fl" then
beep 2
display dialog ("The string is correct")
end if

just before the BBedit replace command, and Applescript does indeed see this as the correct string! However, BBedit does not.

is this a program bug in BBedit? Applescript? My brain? What?

 

[neuby]

Feels like I am having a diologue with myself, but for the interested reader, I solved this puzzle:

Ok, that was weird!

I finally figured out that BBedit was seeing something different in the replace text, than what Applescript was displaying on the screen. I clued in that setting the current_name to characters, and then coercing it back to string was the problem. Turns out that before doing this it was class "utxt" and after it was class "TEXT". That was the problem. Coerced it back to unicode, and all went well.

Dang - that was subtle, and to me still appears to be a fault in BBedit - it states that it wants a string input in the BBedit dictionary.

Oh well, on to the next stage...