shf@well.UUCP (Stuart H. Ferguson) (08/26/88)
I've been playing with the Clipboard.device recently in an attempt to understand all of the things that a low-level iff.library should be able to do. Generally, I'm pretty impressed, and I'm a little surprised that so few developers actually use it. Why is this? Is it because it's a device, and therefore a little more difficult to work with? Or is it because it's IFF oriented? Both these complaints can (and will) be answered by a general iff.library. Also, looking at (and typing in) the sample clipboard code in the RKM (rather devoid of comments, I must say), I find one bit of logic I find queer. It's in the CBCheckSatisfy() function, which tests to see if a "post" with a given post ID needs to be satisfied. The function gets the current clip ID from the clipboard and then tests to see if it's GREATER than the post ID in question. If so, it assumes that the clipboard is now concerned with a new clip and that the post ID in question will never be satisfied. This ``greater than'' test looks like a hack to me. The manual doesn't explain what the clip ID's are, just that they are unique, nothing about how they are assigned. Strange but true fact about the clipboard.device: If you cut something into the clipboard and close the device, you can turn your machine off and turn it back on later and paste the *same* thing into another program. Aside: Any way to get it to save to someplace other than devs:clipboards? Workbench disk may already be pretty full. The clipboard *almost* qualifies as a Commodore-supported pipe-like device, except that it stores the latest clip. You can use units other than PRIMARY_CLIP for private data exchange, and you can synchronize data transfer with the post/satisfy mechanism of the clipboard. But the way its designed, the clipboard retains a memory of the last thing clipped, so it's not *quite* as simple as a pipe. If you could turn off the memory then the clipboard would be a really reasonable pipe. -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC (shf@Solar.Stanford.EDU)