ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) (05/29/91)
I wrote a simple MPW tool last night to display and change Finder comments using the Desktop Manager calls. I have a vague idea that such a thing may be useful as part of a scheme for preserving such comments when you rebuild your desktop. I've already found a mistake in Inside Mac Vol VI. In the documentation for the PBDTGetComment and PBDTSetComment calls (pages 9-54 and 9-56 respectively), it says that the comment is stored and returned as a Pascal-format string. This is not true: it's just a string of straight text characters, with no preceding length byte. This makes sense, because the length is passed and returned in a separate field anyway. (By the way, if you're looking for Inside Mac Vol VI, you could try calling APDA. I got my copy on Monday, after faxing them the order on Friday!) As other people have noticed, the Desktop Manager calls only allow you to perform very specific functions. You can't scan through all the comments and application information on a volume, you can only do it for explicitly-named files. Thus, to get all the information on a volume, you have to do a scan on every file and folder on the volume in turn, and see if there's any information stored for each one of them. This means I'll have to add a directory-scanning function to my tool. I've already discovered that it's rather slow trying to call an MPW tool a thousand times... On the other hand, did you realize that the DTRefNum you get back from PBDTGetPath appears to be the file refnum of the "Desktop DB" file itself? I wonder... One little oddity I noticed is that, when you add a comment to an object with the Finder, and then delete the comment, the Finder leaves a zero-length comment attached to the object. Yes, that's right--the Desktop Manager distinguishes between a zero-length comment, and no comment at all. Why? I don't know. Another thing I've discovered is that you shouldn't try changing the comment for an object that's currently visible in the Finder-- the Finder doesn't notice that the comment has changed. This is all very well if the object is in a folder--just make sure the folder window is closed while you're performing the change. But it means there's no reliable way of *programmatically* changing the comment attached to the volume icon itself. Unless, of course, a FlushVol call is what you need to get the Finder to notice the change... One thing I find annoying is, why can't I use the Desktop Manager calls on a floppy disk? The way it stands at present, the Finder would have two sets of code inside it for handling the desktop database; one set would make calls to the Desktop Manager on volumes where that's available, while the other would do direct manipulations on the "Desktop" resource file. Why not move the latter code from the Finder into the Desktop Manager itself? Then there'd only be one uniform interface which would work on all volumes, and it becomes possible for other applications to get at the Desktop file without having to lock the Finder out. Lawrence D'Oliveiro fone: +64-71-562-889 Computer Services Dept fax: +64-71-384-066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00 "...so she tried to break into the father bear's computer, but it was too hard. Then she tried to break into the mother bear's computer, but that was too easy..."
alexr@apple.com (Alexander M. Rosenberg) (05/30/91)
In article <1991May29.102245.3827@waikato.ac.nz>, ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: > .. > > I've already found a mistake in Inside Mac Vol VI. In the documentation > for the PBDTGetComment and PBDTSetComment calls (pages 9-54 and 9-56 > respectively), it says that the comment is stored and returned as a > Pascal-format string. This is not true: it's just a string of straight > text characters, with no preceding length byte. This makes sense, because > the length is passed and returned in a separate field anyway. > .. I have also notices that although Inside Mac VI tells you how to open and close the Desktop for a volume, it does _not_ mention that the Desktop Manager doesn't work at INIT time. (It tries to make calls to the Process Manager, which isn't set up yet at that time.) --------------------------------------------------------------------------- - Alexander M. Rosenberg - INTERNET: alexr@apple.com - Yoyodyne - - 330 1/2 Waverley St. - UUCP:ucbvax!apple!alexr - Propulsion - - Palo Alto, CA 94301 - - Systems - - (415) 329-8463 - Nobody is my employer so - :-) - - (408) 974-3110 - nobody cares what I say. - -
mdavis@pro-sol.cts.com (Morgan Davis) (05/30/91)
In-Reply-To: message from ldo@waikato.ac.nz } As other people have noticed, the Desktop Manager calls only allow } you to perform very specific functions. You can't scan through all } the comments and application information on a volume, you can only } do it for explicitly-named files. Thus, to get all the information } on a volume, you have to do a scan on every file and folder on } the volume in turn, and see if there's any information stored for each } one of them. Or, and this is what my original message was about, you could use the DesktopDB file (which is some kind of binary tree -- the key to QUICKLY accessing information on all files and folders on a volume). If some MacGenius spent a while browsing through its contents, perhaps he or she could document its structure -- and we could all benefit from being able to *read* through it. I'm not interested in modifying it at all. } Lawrence D'Oliveiro fone: +64-71-562-889 } Computer Services Dept fax: +64-71-384-066 } University of Waikato electric mail: ldo@waikato.ac.nz } Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00 UUCP: crash!pro-sol!mdavis AOL, BIX: mdavis ARPA: crash!pro-sol!mdavis@nosc.mil GEnie: m.davis42 INET: mdavis@pro-sol.cts.com ProLine: mdavis@pro-sol
andyp@treehouse.UUCP (Andy Peterman) (05/30/91)
In article <1991May29.175613.14352@crash.cts.com> mdavis@pro-sol.cts.com (Morgan Davis) writes: >Or, and this is what my original message was about, you could use the >DesktopDB file (which is some kind of binary tree -- the key to QUICKLY >accessing information on all files and folders on a volume). If some >MacGenius spent a while browsing through its contents, perhaps he or she >could document its structure -- and we could all benefit from being able >to *read* through it. I'm not interested in modifying it at all. I believe the DesktopDB file format is a B-Tree that could be accessed by the not-yet-supported B-Tree Manager. This manager, which has been internally used in the HFS system for years, was announced two years ago as being part of the 7.0 release, but was one of the casualtys that didn't make it. I asked one of the Apple people at the Dev. Conf. a few years ago about whether one could use the B-Tree manager to scan the desktop for all applications or icons and his reply was "Please don't!". I think they want to keep its format private so they can diddle with it in the future (if they already haven't). Oh well... -- Andy Peterman | Opinions expressed treehouse!andyp@gvgpsa.gvg.tek.com | are definitely those of (916) 273-4569 | my employer!
d88-jwa@byse.nada.kth.se (Jon W{tte) (05/30/91)
> mdavis@pro-sol.cts.com (Morgan Davis) writes:
Or, and this is what my original message was about, you could use the
DesktopDB file (which is some kind of binary tree -- the key to QUICKLY
accessing information on all files and folders on a volume). If some
MacGenius spent a while browsing through its contents, perhaps he or she
could document its structure -- and we could all benefit from being able
to *read* through it. I'm not interested in modifying it at all.
Don't you huys ever LEARN ? Why do you think the format of the desktop
mgr files was undocumented for system 6 (the INIT) ? Because the FORMAT
CHANGED in system 7. Why do you think the format of the desktop files
still isn't documented ? What will happen in the next release if you
build something that depends on the present format ? What does about a
zillion technotes say about relying on undocumented features ?
PLEASE !
--
Jon W{tte
h+@nada.kth.se
- Speed !