Hello. This is my first time posting here, but I’ve gleaned so much from this site for years. Thank you all.
My issue is this: I am trying to simplify my workflow of scanning cover images of films to a library database in Filemaker Pro. I have almost all of the steps worked out, but I have hit a road block with the way the scanner software passes the output file to the program I tell it to launch the resulting image with. I’m using a Canon Canoscan 9900F, and the toolbox software will let you set an application to open the image with after it has been scanned. When I set this to my applescript (a droplet, posted below) all that happens is the applescript runs, then closes. I assume this is because the way the scanner software passes the file is different in some way on a system level than how the droplet works. Anyone have any ideas? My applescript as of now looks like this:
on open some_items
repeat with this_item in some_items
try
tell application "Image Events"
launch
set the target_width to 500
-- open the image file
set this_image to open this_item
set typ to this_image's file type
copy dimensions of this_image to {current_width, current_height}
if current_width is greater than current_height then
scale this_image to size target_width
else
-- figure out new height
-- y2 = (y1 * x2) / x1
set the new_height to (current_height * target_width) / current_width
scale this_image to size new_height
end if
tell application "Finder" to set new_item to ¬
(container of this_item as string) & "scaled." & (name of this_item)
save this_image in new_item as typ
end tell
end try
end repeat
tell application "FileMaker Pro Advanced"
activate
tell current record of current layout of window 1
set cell "LargeImage" to file new_item
save record
end tell
end tell
end open
Browser: Firefox 3.0.6
Operating System: Mac OS X (10.5)
Only thing I see that might throw things is how the variable ‘some_items’ can be a list or an alias, depending on whether one or more files are dropped onto it. That’d mess up the ‘repeat with this_item in some_items’ if ‘some_items’ is an alias or string instead of a list. Used to be that the open command in applescript droplets wouldn’t always accept drops onto them as a list if it’s just one item. I think they do now, but I always trap for the possibility of an alias or string getting passed to my droplets.
on open some_items
if class of some_items is not list then ¬
set some_items to {some_items}
repeat with an_item in some_items
set file_name to name of (info for (contents of an_item))
display dialog file_name
end repeat
end open
Perhaps the scanner software that lets you select your applescript application to open new scans is getting passed an alias, not a list. I tried the above droplet applescript application by right-clicking on another file and selecting the droplet as the “Open With…” option and it displayed the file name that I had selected and passed the open command to it with the Finder. I tried it successfully both with the script saved as an application bundle and as just an application.
If you designate the above applescript application as the application which will open new scans and it doesn’t launch and display the file name, then most likely, yes, the way the scanner software passes the file is different than how the Finder passes the file (the equivalent of ‘open [reference] using [reference]’ in Finder ‘open’ applescript command - tho, I’d think that it should be the same if it isn’t, durn them. Or it is doing things the same way but there’s only one other problem I’ve encountered doing exactly what you’re doing (tho not with a scanner) is that sometimes selecting an applescript application as the target application isn’t enough to keep it referenced as a unique application, and later the ‘open with’ is sent to a different applescript application. Doesn’t sound like that’s happening, tho; since the correct applet runs, it just doesn’t repeat thru a list of a single item and do anything to it.
Thanks for the response pandrake. Looks like it isn’t doing it the Finder way though.
I did exactly what you did and still no go. The script just opens and then promptly closes. If I pass it a file using “Open With…” it works just fine.
The toolbox software will let me launch the files with Preview just fine. Maybe I can run something from inside Preview. Either that or ignore using the launch feature and just set up a watch folder and pass in the file to the Filemaker importer when it gets saved.
There are a few weak points in the script (the FileMaker stuff’s not in the repeat, the Image Events documents aren’t being closed, Image Events isn’t being quit at the end, there are nested application ‘tell’ blocks), but none of these seem to make it fail as a droplet.
Experimenting with my own Canon Toolbox software (for a different scanner model), the only way I can get it to work with a droplet is to save the droplet as a stay-open application. Then it works brilliantly. Of course, the droplet then needs a ‘quit’ or ‘tell me to quit’ at the end, immediately before the ‘end open’ line.
As for the other points, I left the Filemaker part outside the repeat because, ultimately, I really only want it to pass one file, no matter how many get thrown into it. This way it will just use the last image. It isn’t a problem in the main context since the scanner will probably only ever pass one image anyway. The other stuff has been corrected except for this:
“there are nested application ‘tell’ blocks), but none of these seem to make it fail as a droplet.”
I’m not quite sure what you mean by it. Could you explain further?
Hi. Yeah. Your ‘tell application “Finder” .’ line’s inside the ‘tell application “Image Events”’ block. Many people in the know reckon that ‘tell’ blocks should (as far as is possible and sensible) only contain code that depends on them. This avoids any possibility of terminology conflicts, ownership errors, or delays caused by passing events around unnecessarily. It can also look better on the page!
In your script, having that particular Finder terminology inside the Image Events ‘tell’ block doesn’t in fact seem to be causing any problems; but a purist would finish the Image Events block with an ‘end tell’, tell the Finder to work out the path to the new file, and then tell Image Events to save the file. Better still, since the Finder stuff’s based on this_item and not on anything that Image Events does, that line could be transposed to just before the ‘tell application “Image Events”’ line.
By the way, thanks for the idea of using a script droplet as CanoScan Toolbox’ target application. It’s just given me some functionality with that software! When I bought my N1240U some years ago, it came with OS 9 software. The “OS X” Toolbox that I downloaded for it later thinks that application bundles are ordinary folders, so it’s not possible to set an OS X application as the one to open the scans! I’ve usually rebooted my PowerBook into OS 9 to do scans, or else drag-dropped the files onto Preview manually. However, Toolbox will accept a script droplet as its target and that in turn can open the files with Preview or anything else. I’ve been playing with it all afternoon!
