Thread on comp.sys.atari.st.tech concerning Clipboards ========== comp.sys.atari.st.tech #359, 1262 chars, Mar 21 21:02 94 From: ogal@cix.compulink.co.uk, ---------- Article: 10066 of comp.sys.atari.st.tech Newsgroups: comp.sys.atari.st.tech Path: cix.compulink.co.uk!ogal From: ogal@cix.compulink.co.uk ("Ofir Gal") Subject: Re: Clipboard problems Message-ID: Organization: Compulink Information eXchange X-Newsreader: CixRead/CixComm References: 57@cix Date: Mon, 21 Mar 1994 21:02:29 GMT In message 57@cix, sdssoft@delphi.com said: > >The environment variables have nothing to do with the location of the >system clipboard directory. There is an OS call scrp_read() and scrp_write() >that are meant to manipulate this. The default action of a process that >wants to use the clipboard is to scrp_read() to find it. If none has been >installed, it should create a directory and then use scrp_write() to >acknowledfge >that it has done so. MasterBrowse and Everest apparently do not follow the >rules. You should point the program authors to the Compendium or the article >I wrote about the Clipboard in Atari Explorer. Hope this helps. This is correct to my knowledge. However, some applications do use environment variables for this. Everest follows the correct procedure up to a point. If it fails to locate the system clipboard to does not install one. Ofir ogal@cix.compulink.co.uk ========== comp.sys.atari.st.tech #366, 1618 chars, Mar 22 11:31 94 From: dwhite@rd.eng.bbc.co.uk, ---------- Article: 10085 of comp.sys.atari.st.tech Newsgroups: comp.sys.atari.st.tech Path: cix.compulink.co.uk!uknet!lyra.csx.cam.ac.uk!pavo.csi.cam.ac.uk!pipex!bbc!ant!dwhite From: dwhite@rd.eng.bbc.co.uk (David White) Subject: Re: Clipboard problems Message-ID: Sender: usenet@bbc.co.uk Nntp-Posting-Host: rdmailgate.rd.eng.bbc.co.uk Organization: British Broadcasting Corporation, UK X-Newsreader: TIN [version 1.2 PL0] References: <2d7cc8c6@p2.stacken.ct.se> <1994Mar9.182917.28147@cc.ic.ac.uk> Date: Tue, 22 Mar 1994 11:31:54 GMT Lines: 20 sdssoft@delphi.com wrote: : The environment variables have nothing to do with the location of the : system clipboard directory. There is an OS call scrp_read() and scrp_write() : that are meant to manipulate this. The default action of a process that : wants to use the clipboard is to scrp_read() to find it. If none has been : installed, it should create a directory and then use scrp_write() to : acknowledfge : that it has done so. MasterBrowse and Everest apparently do not follow the : rules. You should point the program authors to the Compendium or the article : I wrote about the Clipboard in Atari Explorer. Hope this helps. : So, how does scrp_read know where the clipboard is? Does the programmer need to worry about the position at all? David White -- ------------------------------------------------------------------------- One STFM and going up ||| david.white@rd.eng.bbc.co.uk ||| # STANDARD DISCLAIMER # / | \ ------------------------------------------------------------------------- ========== comp.sys.atari.st.tech #368, 1335 chars, Mar 22 16:06 94 From: C.J.Ridd@cs.bham.ac.uk, ---------- Article: 10094 of comp.sys.atari.st.tech Path: cix.compulink.co.uk!uknet!warwick!bham!bhamcs!cjr From: C.J.Ridd@cs.bham.ac.uk (Chris Ridd) Newsgroups: comp.sys.atari.st.tech Subject: Re: Clipboard problems Date: 22 Mar 1994 16:06:29 GMT Organization: NHS Information Management Centre Lines: 20 Message-ID: <2mn525$6nb@percy.cs.bham.ac.uk> References: <2d7cc8c6@p2.stacken.ct.se> <1994Mar9.182917.28147@cc.ic.ac.uk> NNTP-Posting-Host: fat-controller.cs.bham.ac.uk dwhite@rd.eng.bbc.co.uk (David White) writes: >So, how does scrp_read know where the clipboard is? Does the >programmer need to worry about the position at all? scrp_read() returns the value last given to scrp_write(), which defaults (on boot) to an empty string. There is a little CPX around which takes care of reinitialising the scrap directory every boot, as well as also being able to view the scrap file. There should be a copy at a.a (clipcpx.lzh perhaps?) Yes, the programmer does have to worry -- if scrp_read returns something that isn't suitable, there is a little algorithm (included in the Compendium) to generate some directory on an appropriate device. IIRC, it is usually \\CLIPBRD on the boot drive. -- --Chris X.400: g=chris;s=ridd;o=nhs imc;ou1=cosit;a=attmail;p=nhs imc;c=gb Cix: chrisridd@cix ========== comp.sys.atari.st.tech #370, 2048 chars, Mar 22 16:07 94 From: walra@moacs11, ---------- Article: 10096 of comp.sys.atari.st.tech Path: cix.compulink.co.uk!uknet!pipex!sunic!EU.net!sun4nl!moacs11!walra From: walra@moacs11 (Waldi Ravens) Newsgroups: comp.sys.atari.st.tech Message-ID: <_ukeetpwziu@moacs11> Organization: private site Subject: Re: Clipboard problems References: <2d7cc8c6@p2.stacken.ct.se> <1994Mar9.182917.28147@cc.ic.ac.uk> Reply-To: walra%moacs11@nl.net Date: Tue, 22 Mar 1994 16:07:14 +0100 Lines: 40 In , David White wrote: > So, how does scrp_read know where the clipboard is? If a previously running program has set the path to the clipboard with scrp_write(), than scrp_read() will set that path and return a value >= 0, otherwise scrp_read() will return -1. > Does the programmer need to worry about the position at all? Yes the programmer should always verify that the path returned by scrp_read() exists, is writeable and readable; the AES does no checks at all! If something is wrong with the path returned by scrp_resd() or scrp_read() returned -1, than the program is on its own ;-). A reasonable strategy would be: 1. Look for an environment variable SCRAPDIR or CLIPBOARD, if either of those exists and contains a valid and useable (i.e. writable and readable) path, than that should be used after it has been reported to the AES with scrp_write(). 2. Use an existing folder \CLIPBRD on the boot device, if necessary try to create one, and of course verify that it can be written-to/read-from. If successful use scrp_write() to register this path. 3. Same as 2. with a path C:\CLIPBRD (or A:\CLIPBRD). 4. If all previous steps fail the program should not use the clipboard. Note that this procedure is likely to create a big mess in a multitasking environment. It's best if the user installs a CPX that sets the clipboard path at boot time. Regards, Waldi (walra%moacs11@nl.net) -- A C program is like a fast dance on a newly waxed dance floor by people carrying razors. ========== comp.sys.atari.st.tech #392, 1406 chars, Mar 24 01:45 94 From: warwick@cs.uq.oz.au, ---------- Article: 10142 of comp.sys.atari.st.tech Path: cix.compulink.co.uk!uknet!EU.net!howland.reston.ans.net!vixen.cso.uiuc.edu!uchinews!msuinfo!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!uqcspe.cs.uq.oz.au!warwick From: warwick@cs.uq.oz.au (Warwick Allison) Newsgroups: comp.sys.atari.st.tech Subject: Re: Clipboard problems Date: 24 Mar 1994 01:45:16 GMT Organization: Computer Science Dept, University of Queensland Lines: 19 Message-ID: <2mqrbc$50a@uqcspe.cs.uq.oz.au> References: 57@cix NNTP-Posting-Host: everest.cs.uq.oz.au ogal@cix.compulink.co.uk ("Ofir Gal") writes: >Everest follows the correct procedure up to a point. If it fails to locate >the system clipboard to does not install one. IMO, this is how the standard should read. If there is no clipboard installed, the user probably doesn't want to transfer data between applications, and therefore the clipboard should be kept internal to the program (if that would be more efficient). Creating a file just to cut and paste 5 characters of text can be a little annoying in Atari Workso, for example. -- Warwick _-_|\ warwick@cs.uq.oz.au |||||| GEM++ = C++ GEM library / * <- Computer Science Department, |||||| GEM++ is Free Software \_.-._/ University of Queensland, _// || \\_ C++ is the FUTURE v Brisbane, Australia. |_/ || \_| Use GNU C++ = FREE ========== comp.sys.atari.st.tech #448, 1994 chars, Mar 26 22:03 94 From: evanlang@uss.lonestar.org, ---------- Article: 10252 of comp.sys.atari.st.tech Newsgroups: comp.sys.atari.st.tech Path: cix.compulink.co.uk!uknet!pipex!howland.reston.ans.net!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!m2.dseg.ti.com!ernest!egsner!shyguy!uss!evanlang From: evanlang@uss.lonestar.org (Evan Langlois) Subject: Re: Clipboard problems References: <57@cix> <2mqrbc$50a@uqcspe.cs.uq.oz.au> Organization: uss.lonestar.org public access linux (214)424-9705 Date: Sat, 26 Mar 1994 22:03:33 GMT Message-ID: Lines: 30 In article <2mqrbc$50a@uqcspe.cs.uq.oz.au>, Warwick Allison wrote: >ogal@cix.compulink.co.uk ("Ofir Gal") writes: > >>Everest follows the correct procedure up to a point. If it fails to locate >>the system clipboard to does not install one. > >IMO, this is how the standard should read. If there is no clipboard >installed, the user probably doesn't want to transfer data between >applications, and therefore the clipboard should be kept internal to >the program (if that would be more efficient). > >Creating a file just to cut and paste 5 characters of text can be a >little annoying in Atari Workso, for example. Warwick, I'm gonna have to disagree. When you select a group of characters, this is a CUT. And should put the characters in a memory buffer. Getting them top the clipboard would mean doing a PASTE onto the clipboard. And therefore reading data from another app would mean CUTting from the clipboard and PASTEing into the document. This also means you can implement drag-n-drop much better since the CUT data is simply in a memory buffer (either a separate buffer or a pointer into your data or whatever - just internal). Then, the user decide later whether to paste it to the clipboard, paste it to a document, drag it to the clipboard, or drag it to an open window, or drag it to the trash, or drag to the printer, etc. This illiminates the slowdown and makes the programming part a bit easier. ========== comp.sys.atari.st.tech #449, 2369 chars, Mar 28 14:43 94 From: C.J.Ridd@cs.bham.ac.uk, ---------- Article: 10256 of comp.sys.atari.st.tech Path: cix.compulink.co.uk!uknet!bhamcs!cjr From: C.J.Ridd@cs.bham.ac.uk (Chris Ridd) Newsgroups: comp.sys.atari.st.tech Subject: Re: Clipboard problems Date: 28 Mar 1994 14:43:55 GMT Organization: NHS Information Management Centre Lines: 44 Message-ID: <2n6qfb$oue@percy.cs.bham.ac.uk> References: <57@cix> <2mqrbc$50a@uqcspe.cs.uq.oz.au> NNTP-Posting-Host: mother.cs.bham.ac.uk evanlang@uss.lonestar.org (Evan Langlois) writes: >In article <2mqrbc$50a@uqcspe.cs.uq.oz.au>, >Warwick Allison wrote: >>IMO, this is how the standard should read. If there is no clipboard >>installed, the user probably doesn't want to transfer data between >>applications, and therefore the clipboard should be kept internal to >>the program (if that would be more efficient). >> > >Warwick, I'm gonna have to disagree. When you select a group of >characters, this is a CUT. And should put the characters in a memory >buffer. Getting them top the clipboard would mean doing a PASTE onto >the clipboard. And therefore reading data from another app would mean >CUTting from the clipboard and PASTEing into the document. This also >means you can implement drag-n-drop much better since the CUT data is >simply in a memory buffer (either a separate buffer or a pointer into >your data or whatever - just internal). Then, the user decide later >whether to paste it to the clipboard, paste it to a document, drag it >to the clipboard, or drag it to an open window, or drag it to the >trash, or drag to the printer, etc. > >This illiminates the slowdown and makes the programming part a bit >easier. > Unfortunately your 'method' is completely alien to most users of computer software, ie Macintosh, Windows, X Windows etc. When you Cut something, it is *immediately* placed on the 'clipboard', which other apps can use to paste from. It doesn't go into some intermediate limbo, unless (as Warwick pointed out) the user is not interested in transferring data between apps. Perhaps you are missing the distinction between making a selection, and cutting something? Making life easier for the programmer is *not* the idea. Making life easier for the user *is*. -- --Chris X.400: g=chris;s=ridd;o=nhs imc;ou1=cosit;a=attmail;p=nhs imc;c=gb Cix: chrisridd@cix ========== comp.sys.atari.st.tech #452, 2194 chars, Mar 29 01:58 94 From: ogal@cix.compulink.co.uk, ---------- Article: 10263 of comp.sys.atari.st.tech Newsgroups: comp.sys.atari.st.tech Path: cix.compulink.co.uk!ogal From: ogal@cix.compulink.co.uk ("Ofir Gal") Subject: Re: Clipboard problems Message-ID: Organization: Compulink Information eXchange X-Newsreader: CixRead/CixComm References: <57@cix> <2mqrbc$50a@uqcspe.cs.uq.oz.au> <2n6qfb$oue@percy.cs.bham.ac.uk> Date: Tue, 29 Mar 1994 01:58:54 GMT In message <2n6qfb$oue@percy.cs.bham.ac.uk>, C.J.Ridd@cs.bham.ac.uk said: >>Warwick, I'm gonna have to disagree. When you select a group of >>characters, this is a CUT. And should put the characters in a memory >>buffer. Getting them top the clipboard would mean doing a PASTE onto >>the clipboard. And therefore reading data from another app would mean >>CUTting from the clipboard and PASTEing into the document. This also >>means you can implement drag-n-drop much better since the CUT data is >>simply in a memory buffer (either a separate buffer or a pointer into >>your data or whatever - just internal). Then, the user decide later >>whether to paste it to the clipboard, paste it to a document, drag it >>to the clipboard, or drag it to an open window, or drag it to the >>trash, or drag to the printer, etc. >> >>This illiminates the slowdown and makes the programming part a bit >>easier. >> > >Unfortunately your 'method' is completely alien to most users of >computer software, ie Macintosh, Windows, X Windows etc. When you Cut >something, it is *immediately* placed on the 'clipboard', which other >apps can use to paste from. It doesn't go into some intermediate >limbo, unless (as Warwick pointed out) the user is not interested in >transferring data between apps. > >Perhaps you are missing the distinction between making a selection, and >cutting something? > >Making life easier for the programmer is *not* the idea. Making life >easier for the user *is*. I agree, the way it's implemented in Everest is probably the