cks@radio.toronto.edu (11/05/87)
[Reposted due to news problems; I'm sorry if you see this twice.]
I'm working on an application that I'd like to support the clipboard.
Unfortunately, the clipboard.device wants data in IFF format, and
writing IFF-format data really needs something that supports writes at
random offsets. The documentation for the clipboard.device hints that
you can do this by playing with the io_Offset field (indeed, it hints
at having a Seek() call of some sort), but I'd like to be sure before
I start writing a lot of code.
--
"How EMBARASSING."
KWOOOOOM!
Chris Siebenmann {allegra,mnetor,decvax,pyramid}!utgpu!radio!cks
cks@radio.toronto.edu or ...!utgpu!{yetti!lethe, darwin}!ontmoh!cksjimm@mitsumi.UUCP (Jim Mackraz) (11/10/87)
In article <562@radio.toronto.edu> cks@radio.toronto.edu (Chris Siebenmann) writes:
) I'm working on an application that I'd like to support the clipboard.
)Unfortunately, the clipboard.device wants data in IFF format, and
)writing IFF-format data really needs something that supports writes at
)random offsets. The documentation for the clipboard.device hints that
)you can do this by playing with the io_Offset field (indeed, it hints
)at having a Seek() call of some sort), but I'd like to be sure before
)I start writing a lot of code.
)Chris Siebenmann {allegra,mnetor,decvax,pyramid}!utgpu!radio!cks
How about writing the data to a file in the RAM disk, and copying the
result to the clipboard? I'd like to see the standard expanded so that
the file name (in RAM:) can be passed, so that ram for just one copy
of the IFF form of the data need be around at any one moment. It
might also be good to let the user specify (via "environment" variable
or TOOLTYPE) what directory to use for TEMP.
Anyway, this is low risk, so write that code, support that clipboard!
jimm
--
Jim Mackraz
Mitsumi Technology, Inc. 408/980-5422
{amiga,pyramid}!mitsumi!jimmkodiak@amiga.UUCP (Robert R. Burns) (11/11/87)
Chris Siebenmann writes: > I'm working on an application that I'd like to support the clipboard. >Unfortunately, the clipboard.device wants data in IFF format, and >writing IFF-format data really needs something that supports writes at >random offsets. The documentation for the clipboard.device hints that >you can do this by playing with the io_Offset field (indeed, it hints >at having a Seek() call of some sort), but I'd like to be sure before >I start writing a lot of code. Yea! (ambiguous: yes, enthusiam). Realize that the clipboard.device is an Exec style device, and is thus written to with a variant of the IORequest structure (IOClipReq in libraries/clipboard.h) using SendIO/DoIOish code. In the IOClipReq there is an io_Offset field that after a Write (CMD_WRITE) points to the "next" position, but you can set it to any value you want before a Write (i.e. Seek) The clipboard.device tries to keep things in ram, but if ram runs low it puts the clip in the file DEVS:clipboards/0 (which is the intended place to exchange data: other units besides 0 are available, though) - Kodiak
keithd@cadovax.UUCP (Keith Doyle) (11/13/87)
In article <986@mitsumi.UUCP> jimm@mitsumi.UUCP (James Mackraz) writes: >How about writing the data to a file in the RAM disk, and copying the >result to the clipboard? I'd like to see the standard expanded so that >the file name (in RAM:) can be passed, so that ram for just one copy >of the IFF form of the data need be around at any one moment. It >might also be good to let the user specify (via "environment" variable >or TOOLTYPE) what directory to use for TEMP. Ah, well, I haven't had time myself to check out just what the clipboard is and does, so this may seem kinda uninformed, but... I always pictured a "clipboard" as a fancy name for a subdirectory (probably really called RAM:clipboard) and an agreement on the format of stuff in there. On the MAC there's an icon for the clipboard, and you can open up it's window and see what's in there. You could do that with RAM:clipboard too. What does it buy you to have the clipboard a seperate "device" or whatever? Just a workbench Icon that looks like a clipboard, so I don't have to go looking in RAM: for it? I mean if you get Microsoft DDA (or whatever the name of that "update your spreadsheet from your dbms on the fly protocol is) type functionality, that's great, but if not, why not just use RAM:? Or perhaps a RAM: driver clone that instead of being named RAM2: is called CLIP: or something with it's own icon? Or is that what it is? DISCLAIMER Don't get me wrong, I'm not trying to be a rabblerouser and suggest we don't use it, or suggest it go through a major redesign. I'm just wondering what it does that's fantastic. Keith Doyle # {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170
keithd@cadovax.UUCP (Keith Doyle) (11/13/87)
In article <1964@amiga.amiga.UUCP> kodiak@amiga.UUCP (Robert R. Burns) writes: >The clipboard.device tries to keep things in ram, but if ram runs low >it puts the clip in the file DEVS:clipboards/0 (which is the intended >place to exchange data: other units besides 0 are available, though) AHA! Part of my question has been answered. The clipboard is kind of a virtual RAM: disk. Hm.. Could be interesting to have a virtual RAM: handler. Uh oh, you guys are in trouble now, just wait until I publish the book "weird unsupported things nobody ever figured you'd want to do with the clipboard.device". :-) Keith Doyle # {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170