This Technical Note describes known anomalies in Standard File.
Changes Since December 1991: Updated for System 6.0. Problems with the infinite loop and SFMultiGet2 reply record are fixed.
When you advance to the next volume using Command-Tab (or just Tab, before 6.0), Standard File checks your prefix against the name of the volume now in the same device you were just using, to see if you switched disks (this is possible on a 5.25 drive, for example). If the name doesn't match, you stay at the same device.
Unfortunately, the comparison in 6.0 and earlier is case sensitive. If you have a volume called "MyDisk" and prefix zero is set to ":MYDISK", advancing to the next volume doesn't get you anywhere the first time (but the prefix changes from ":MYDISK" to ":MyDisk").
The following two problems are fixed in System 6.0:
In System Software versions 5.0 through 5.0.4, all Standard File dialogs can hang if both prefixes 0 and 8 are empty (GS/OS uses prefix 8 to expand partial pathnames if prefix 0 is empty).
If this affects your software, use GetPrefix to check for empty prefixes before calling Standard File. If 0 and 8 are both empty, set prefix 0 to "*:" (or any other convenient pathname).
SFMultiGet2 and SFPMultiGet2 in System 5.0.4 and earlier accidentally validate the multi-file reply record as if it were a regular new-style reply record (as for SFGetFile2, for example). The validation is a check that the words at offsets $08 and $0E in the record are not $0002 (these are nameRefDesc and pathRefDesc in a new-style reply record).
To ensure that Standard File does not erroneously reject your multi-file reply record (and return error $1704), you may include ten bytes of $00 following the six-byte record.
This and all of the other Apple II Technical Notes have been converted to HTML by Aaron Heiss as a public service to the Apple II community, with permission by Apple Computer, Inc. Any and all trademarks, registered and otherwise, are properties of their owners.