You are not logged in.
The Scriptable Finder AppleScript 1.3.7
I understand that many long-standing bugs in the scriptable Finder, including some remaining from at least Mac OS 8.1, were not touched in Mac OS 8.6. Through an intermediary, I provided the following list of the eleven most-important Finder bugs to Apple in June 1999. They are ranked in order of importance as I see it, with the most serious first.
1. Comparisons of numeric values in filter references produce erratic results.
Chris Espinosa confirmed most of this in December 1998 and said he was filing a bug on it. Numeric comparisons in filter references generally produce unpredictable results, for example, using 'size', 'physical size', 'capacity', 'free space', 'modification date' and 'creation date'. Here are some tests I ran: For example, 'tell application Finder to get every disk where (XXX of it < YYY)' returns a list of references to fewer than the total number of qualifying disks on my system, where XXX is either 'capacity', 'free space', 'size' or 'physical size' and YYY is set to a number larger than the largest corresponding property among the disks on my system. (Incidentally, telling the Finder to 'tell startup disk to get (capacity = free space + size) --or + physical size' returns true.) I find that the problem also affects other finder items than disks, such as files, and that the correctness of the result depends on the magnitude of the number being compared against. For example, in a particular test I ran on two clipping files in a test folder, where both files have a 'size' of less than 500 bytes, 'every item of folder Test folder where size of it < 5000.0' returns an empty list, whereas 'every item of folder Test folder where size of it < 500.0' returns a list of references to both files. In fact, of course, both tests should generate a list of references to both files. And, reversing the test to '>' (greater than), each test produced the opposite result (for example, testing for 'size' and 'physical size' > 5000.0 reported that both files qualified, when in fact neither qualified. The problem also affects comparisons of Finder items using 'modification date' and 'creation date'. All of these errors make management of disks, such as backup scripts, using filter references impossible, and it has generated a lot of unhappiness on the lists. The workaround is to use slow repeat loops. [This bug has existed since at least Mac OS 8.1. I thought I had heard it was fixed in 8.5, but it apparently was not, or perhaps the fix backfired.]
2. 'Duplicate' in place returns empty list.
Eric Hellman reported, and Sal Saghoian, Andy Bachorski and Chris Espinosa of Apple have all confirmed, the widespread reports that duplicating one or more items in place (i.e., to the same folder) returns an empty list in Mac OS 8.5. I have confirmed, and Chris Espinosa has acknowledged, that this bug remains in Mac OS 8.6. Duplicating one or more items to another folder returns a reference to a single item, or a list of references to multiple items, as it should. An interesting cure is available, which may help track down the bug: Buy the commercial product Speed Doubler 8 from Connectix, turn on the Faster File Copying option under the Status tab, and check the Intercept Finder Apple Events option under the Copy tab. The 'duplicate' command now returns the correct result every time. Another workaround, suggested by Apple, is to duplicate items to another folder then move them to the desired destination with appropriate attention to potential name conficts. The 'move' command will return the desired result (but you have to know the destination anyway in order to use this workaround, so your script already has the desired information).
3. 'Where XXX of it' works but 'whose XXX' doesn't when getting attributes of Finder items using the filter reference form.
A statement like 'tell application Finder to get every item of desktop whose class is alias file' or 'to get (every item whose class is alias file) of desktop' returns an empty list even though there are alias files on the desktop. Changing it to the form 'tell application Finder to get every item of desktop where class of it is alias file' does work. The bug bites whether you are looking on the desktop or within a folder window. I have tested the following cases and found the bug in all of them: testing for kind alias, compiled script and folder, and class alias file, document file and folder. I assume the bug is a general problem with the implementation of the filter reference form. The workaround is always to use the 'where xxx of it' form instead of the 'whose' form.
4. 'Size' and 'physical size' properties of items return wrong class.
Select a file, then run 'tell application Finder to get size of selection' --or 'physical size of selection'. The result will appear to be of type 'real' because it has a decimal, such as '3679.0'. However, run 'tell application Finder to get class of (size of selection)' and it will return 'integer', as the dictionary says it should. Because of this discrepancy, you cannot coerce 'size of selection' or 'physical size of selection' to a string so as to display it or use it in a string. I wonder if the class of the returned value was changed to real to accommodate very large disks, but somebody forgot to fix the value returned by 'class' (and the corresponding description of the 'size' and 'physical size' properties of several classes). The workaround is always to work with the 'result' of the 'size' and 'physical size' properties, such as by assigning it to a variable. For example, the class of 'mySize' after running 'set mySize to size of selection' is 'real', and you can coerce it to a string. [This bug has existed since at least Mac OS 8.1.] [RadarWeb #2246150; I couldn't get the engineer to understand my bug report, possibly because I was confusing the 'size' and 'physical size' properties with the 'data size' command in the Standard Suite.]
5. Incorrect path to items on desktop of non-startup disk.
If you have more than one disk drive connected, drag an item from the non-startup disk onto the desktop and leave it selected. The statement 'tell application Finder to get selection as text' will return a path indicating that the selected item resides on the startup disk, when in fact it does not. The statement 'tell application Finder to get (selection as alias) as text' returns the correct path. This appears to be a coercion error, because the Finder returns a reference to the correct disk when you run the statement 'tell application Finder to get disk of selection'. It may not involve the Finder at all, since if you tell the Finder to get the selection, then coerce the result to text outside of the Finder tell block, you get the wrong result.
6. 'Creator type' and 'file type' when used with 'every' return raw event codes.
When used with 'every', 'creator type' and 'file type' return a list of raw event codes instead of the specified list of four-character strings. For example, 'creator type of every process' and 'file type of every item in selection' return a list of raw event codes in the form <<class XXXX>>, whether or not the filter reference form is used. This is inconsistent with the result of getting an indexed item, such as 'file type of first process', which returns a four-character string whether or not using the filter reference form. [This bug has existed since at least Mac OS 8.1.] [RadarWeb #2231601]
7. 'First item in window' returns arbitrary results.
The statement 'tell application Finder to reveal first item in front window' selects a different item in the window every time it is run. I don't know whether it should select the first item based on the current sorting column or instead based on a specific column (such as Name) no matter which column is currently in effect (I prefer the former, since the sorting order is scriptable and this would give greater control), but I do think it should select the same item every time it is run. [This bug has existed since at least Mac OS 8.1.] There is an interesting side effect: The order in which files in a window are listed by a statement like 'files of front window' changes each time you run it, at least if you preface it with a 'reveal first item' command. The result is now identical even if you change which column is currently being used to sort the window's display within the script, whereas I believe in Mac OS 8.1 it returned a different list ordering depending on which column was used to sort the display. [RadarWeb #2246142]
8. Can't test whether view of window is 'icon'.
The statement 'tell application Finder to get view of front window' returns the constant 'icon' if it is set to large icon view. However, you can't test a window's view for 'icon'. The statement 'tell application Finder to get (view of front window is icon)' generates an error message saying can't get icon. Testing for the other view constants in this manner (e.g., 'small' for small icon, 'name' for list by name) works fine. Is there a name conflict between the 'icon' constant and the 'icon' property of an item?
9. 'Titled' property of class window compiles to 'resizable'.
The statement 'tell application Finder to get titled of front window' compiles to 'tell application Finder to get resizable of front window'. Thus, it is now impossible to determine whether a Finder window has a title bar. (Are there any Finder windows that don't have a title bar? -- yes, Page Setup and Print Window, but they are modal and I'm not sure they belong to the Finder.)
10. 'Copy' doesn't record correctly.
Copying the name of a file, either by selecting the item or selecting its name in the Finder and selecting Copy from the Edit menu or pressing command-c, is recorded in the form of a raw event, <<event aevtcopy>>. The script as recorded will not run. If you manually edit the raw event by changing it to 'copy', it will run properly and put the name of the selected item onto the clipboard. [This bug has existed since at least Mac OS 8.1.]
11. 'Exists' doesn't work with 'original item' when applied to orphaned alias files.
The statement 'exists (original item of selection)' generates error number -1708 if an orphaned alias file is selected. It should return 'false'. The error message says the original item doesn't understand the 'exists' message, suggesting that a nonexistent object can't signal that it isn't there. Other statements incorporating this command don't generate an error at all but return incorrect results. For example, 'tell application Finder to get every item in desktop where (((original item of it) exists) is false)' returns a list of everything on the desktop, including an orphaned alias file if it is present on the desktop. [This bug has existed since at least Mac OS 8.1.]
Here are some more Finder bugs:
12. 'Move' without destination moves item to desktop.
The 'move' command moves an item from a folder to the desktop if no destination is specified. This could be considered a feature, not a bug, but I haven't seen it documented anywhere.
13. Errors and omissions in dictionary descriptions.
There are a few errors and omissions in descriptions of items in the Finder's dictionary ('aete' resource). For example, class desktop-object should list the 'disk' element as accessible 'by ID' as well as by numeric index and by name; after all, 'tell application Finder to get id of startup disk' does return an ID. There are a few other elements and properties in various classes whose descriptions are inaccurate.
14. Different commands return different names for the desktop.
Getting 'name of desktop' returns Desktop. This is what we call the desktop in conversation, but it is not consistent with what is returned when you get the name of any other container, namely, its full name without a trailing colon. The name that is normally used in the Finder is 'Desktop Folder', just as it is in the 'name' property of the 'info for' command in the Standard Additions scripting addition. As a result of this discrepancy, 'name of desktop' cannot be used in Finder scripts, as the name of a disk or folder can, by simply appending a colon. Coercing 'desktop' to a string correctly returns <startup disk>: Desktop Folder:, not only with the trailing colon but including the word Folder. You can extract the name from this string using standard (if somewhat awkward) string parsing methods. It would be easier if 'name of desktop' correctly returned Desktop Folder. [This bug has existed since at least Mac OS 8.1.]
Last edited by Kevin Bradley (2006-06-15 02:12:17 am)