At 20:17 +0100 3/18/01, Bart Lateur wrote:
>I think that that "mush" itself is stored in some kind of tree. The key
>to traversing this tree should be some length words/longs, indicating
>how long the individual parts are. I expect it to be not to different
>from how JPEG and/or TIFF files are stored. Or, more close to home: I
>expect that the structure of the clipboard is very closely related to
>the structure of a file's resource fork.
Bart...I'm quoting this message as representative of the entire thread.
This isn't "aimed" at you.
Inside Mac: More Macintosh Toolbox, chapter 2. Scrap Manager.
1. The clipboard is a user concept. It is implemented as the System
Scrap, and however each application wants to do things internally
(collectively "private scrap" as far as Apple is concerned). The System
Scrap is in memory except when it's on disk (grrr!, but this stuff began in
the days of very small memory).
2. The Scrap Manager provides routines for loading stuff into the System
Scrap, finding out what's there, and retrieving what one wants (but not
always: you seem not to be able to retrieve directly a second chunk of
TEXT if it is there).
3. The raw stuff this thread has been discussing can mostly be ignored if
one wants to. But the format of the block addressed by the scrap handle
returned by InfoScrap is
4 bytes: type code (TEXT, PICT, styl, etc etc)
4 bytes: length of the data (must be even)
n bytes: the data
Repeated until one runs out of stuff.
This is pretty easy to walk. No indication of alternate 2 and 4 byte lengths.
4. Rather than my quoting IM: More Mac Toolbox:2 here, see
http://gemma.apple.com/techpubs/mac/MoreToolbox/MoreToolbox-109.html
5. The various LM... things related to the System Scrap are not supported
in Carbon...the Carbon spec says to use the Scrap Manager APIs instead.
Therefore, instead of LMGetScrapHandle one should use InfoScrap, for
instance.
6. Routines of interest for retrieval:
InfoScrap
How much is on the scrap; where it is (memory or what file); whether it
has changed since the last time you looked.
GetScrap
You provide a handle and indicate the type of data...
Scrap manager hands back the data contained in the FIRST chunk of data
of that type, or tells you there isn't any.
7. There can be (and usually are) multiple representations of the contents
of the Scrap. Apple would like to see TEXT and PICT (or PICT and TEXT, if
the application building the clipboard prefers PICT. More generally, an
app should load the clipboard with its most preferred form first, down to
least perferred (and of course some forms work together, as in TEXT and
styl). And it's friendly to put at least one standard form there for other
apps to display and work with.
8. You can use the Scrapbook to get a good idea what's presently on the
clipboard: do Paste, then look at the type list at the bottom of the
Scrapbook window. I copied some styled text from an MS Word 2001 document,
and found CLAP, DSIG, and styled text (TEXT and styl) in the Scrapbook
window when I pasted).
9. Having put an unknown clipboard into the ScrapBook, you can drag to the
desktop and examine the resulting clipping file in ResEdit (or with
Resource Manager routines). Doing this with my little test shows
CLAP:
4D535744000B4D5552464F424A445254462048544D4C7374796C54455854504943544E4154564F4C4E4B4F4A4C4B4C4B5344
(ie, a bunch of stuff --mostly upper case letters, starting with MSWD, I
don't care to decode).
DSIG:
000A5DBC
(I haven't the foggiest).
And sensible TEXT and styl items.
The 'drag' resource is the mechanism by which clipping files index their
contents and can be ignored here.
10. The AppleScript scripting addition command
clipboard info
does the walking of the scrap data in the AppleScript environment. For my
little test MS Word 2001 document (copied into the clipboard) it returns:
{
{
«class DSIG»,
4
},
{
«class CLAP»,
50
},
{
string,
43
},
{
scrap styles,
102
}
}
HTH.
--John
--
John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA
