At one time there was a problem doing drag & drop to the icon of an AppleScript located on the desktop. This may still be true.(?) Make sure the icon (alias or original) is located inside a folder window.
If you need information returned from an application, this is a response and “ignoring application responses” will cause your script to not wait for a value to be returned from the app and, consequently, the variable will be undefined. There are other ways of listing a folder (Standard Additions has a “list folder” command; you could then iterate through the files checking file properties without using the Finder to determine if the file is something you want; or you could use shell scripts).
Jon
First of all, thanks again, Jon, for your help.
Regarding the “list folder” command, that’s how I had it coded originally, but figured (and after several tests, confirmed) that using a one-line filter reference form within a Finder tell block would be much more efficient than listing the folder contents, examining each item item one by one, etc., and calling a potentially recursive subroutine.
I recoded the ‘process_folder_’ handler to use a “list folder” recursive subroutine. When dropping a folder of files onto the application icon or opening a folder through the File->Open command, I now have a 3-6 second delay before the processing of files even begins–a delay that wasn’t there when I used the Finder.
I guess I still have trouble understanding how the huge initial hang when I drop files onto the target is caused by the inefficiency of the Finder.
As I said before, I have 3 methods to initiate the processing of files:
A) drop files onto the application icon – ‘on open’ handler
B) select files through File->Open menu – ‘on choose menu item’ handler
C) drop files onto an NSImageView in the application window – ‘on drop’ handler
All 3 methods, A, B, and C, call the same subroutines to process the files. For an example folder of 50 files, say method A takes 30 seconds, method B takes 30 seconds, and method C takes 60 seconds. How is the extra time that method C takes explained by “inefficiencies of the Finder” when the same code works just fine for method A and B? I hope that makes sense.
Oh, you can see the current state of my code at http://homepage.mac.com/mdouma46/applescript/dfontifier2code.html. Also, FWIW, dfontifier.sitx (.sitx, ~488 KB) is the Xcode project file.
Thanks in advance…
Do you experience the delay when you use my dropper demo app?
http://homepage.mac.com/jonn8/as/dist/dropper.hqx
Jon
Okay, I’m kind of confused now.
When I mentioned that I got that 3-6 second delay, I was only referring to when I drop a folder of files onto the application icon or open a folder through the File->Open command. In other words, methods A and B, but not C. I guess the point I was trying to make was that it seemed to me that doing that ‘list folder’ recoding was like a step in the wrong direction, as my app was now slower than it was before in methods A and B. As far as performance in C, there’s still quite a bit of lag, but I still have a bit more revamping to do to remove the Finder from all of the subroutines.
On using your app, I don’t get that initial hang like I would get in mine, as your app starts processing right away, whereas mine would wait with %CPU at 0 until the Finder finished returning the results. However, the Finder returned those results almost instantaneously when I would drop the files onto the application icon or chose them from the menu command; only when I drop them onto the NSImageView does the Finder seem to take forever.
When using your dropper I still experience a sluggishness of sorts. If I drop a folder with 400-500 jpg’s onto the NSImageView, it begins to process the files. The cursor seems to freeze into that pointer with the green blob with a white plus sign in it. After about 20 seconds, the folder of items I dragged onto the NSImageView “snaps” back to where it was in the Finder, for whatever reason. The app then finishes with “Took 34 seconds for 453 valid items.”
One other thing regarding your dropper demo. I dunno about you, but I was having the same problem I’ve had in the past with “file type” being changed to “file kind”. Only solution I’ve found is to hit compile, find all instances of “file kind” and replace them with “«class asty»” and then immediately save and the script and build the app.
I haven’t had the constant switching problem. Perhaps its an OSAX conflict?
Jon
Which would be…? :lol:
Or you mean a conflict of sorts with any Scripting Additions I have?
Hmm, I have “Adobe Unit Types”, and “QXPScriptingAdditions.osax”. Duh… osax. Okay, I’ll try disabling them… Thanks…
Well, I don’t know what the heck it was, but suddenly I’m no longer having that problem. Maybe it was the upgrade to 10.3.3? I dunno, didn’t look like there were any changes to AppleScript, only thing I saw was Image Capture scripting addition but…
Oh well, I ain’t gonna complain…
Well, after all this time, I figured I’d post back with what I’ve found.
Jon, I think you were right in a sense about the Finder being an inefficient process, but it only seems to effect cases like mine, when you drag files from the Finder onto some Cocoa object in your application, to which you’ve attached a script that involves the Finder in some way to process the files.
I’m in the process of gathering evidence in order to submit a bug report, because, IMO, something has got to be seriously wrong. This is what I’ve got so far:
"There seems to be a bug that effects the dragging of items from the Finder onto an object in an ASStudio app to which an ‘on drop the_object_ drag info drag_info_’ handler is attached, if that handler involves the use of the Finder in any manner whatsoever to process the dropped files. For example, you have an application that’s set up to use the Finder to set the file type and creator codes for files that you drop onto an NSImageView in the main window.
The bug causes a hang in the ASStudio application for roughly 20-25 seconds, after which point the app suddenly kicks into gear and processes files normally. At around 20 seconds, the files you dragged onto the object in the window will seem to “snap back” to their original location in the Finder, almost as if you had “returned false” for the drag and drop handler.
When it comes to obtaining the files you want to process, there are several ways of doing so:
-
As I already mentioned, one option would be to set up some sort of “target” in a window onto which you can drag and drop a selection of files (using an ‘on drop the_object_ drag info drag_info_’ ).
-
Another method would be to drag and drop the files onto the application icon itself (using an ‘on open dropped_items_’ type handler).
-
And yet another method would be to choose the files through an Open dialog (an ‘on choose menu item the_object_’ handler).
This application hanging-bug seems isolated to the dragging and dropping of files onto a Cocoa object, or namely method #1) described above. For example, you use these 3 methods above to “collect” the files to be processed, and in each case, you feed those files into the same handler (which involves the Finder) that does the processing of the files (like setting the Creator Code, for instance). Only when you drag and drop the files onto the window “target” will this hang occur; in the other 2 cases, the files will be processed normally.
The File Typer application I’ve built can demonstrate this bug. The “Sample Files” folder included with this example contains 100 “dummy” files which you can use with File Typer to set the file type and creator codes for. To process these files, select all of the files in the folder (not the folder itself) and then drag them either onto File Typer’s application icon or onto the “SET” target in the main window. These are the results on my machine for this example:
-
Drop the files onto File Typer’s icon in the Dock, and use System Events to set the file types and creator codes:
Items processed: 100 items
Total time taken: 4 seconds -
Drop the files onto File Typer’s icon in the Dock, and use the Finder to set the file types and creator codes:
Items processed: 100 items
Total time taken: 4 seconds -
Drop the files onto the “target” in the main window, and use System Events to set the file types and creator codes:
Items processed: 100 items
Total time taken: 4 seconds -
Drop the files onto the “target” in the main window, and use the Finder to set the file types and creator codes:
Items processed: 100 items
Total time taken: 27 seconds"
If you want, you can get ‘File Typer’ here: File Typer.sitx (.sitx, ~60 KB).
I realized that I didn’t include the actual Xcode project which I intended to do. Also need to correct the link.
New link is FileTyperBug.sitx (.sitx, ~76 KB).