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: <Cn1945.8MC@cix.compulink.co.uk>
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: <Cn2DD7.90w@bbc.co.uk>
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> <ZsyPofv.sdssoft@delphi.com>
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> <ZsyPofv.sdssoft@delphi.com> <Cn2DD7.90w@bbc.co.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>
	<ZsyPofv.sdssoft@delphi.com> <Cn2DD7.90w@bbc.co.uk>
Reply-To: walra%moacs11@nl.net
Date: Tue, 22 Mar 1994 16:07:14 +0100
Lines: 40

In <Cn2DD7.90w@bbc.co.uk>, 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 <Cn1945.8MC@cix.compulink.co.uk>
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> <Cn1945.8MC@cix.compulink.co.uk> <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: <CnAL9x.MI3@uss.lonestar.org>
Lines: 30

In article <2mqrbc$50a@uqcspe.cs.uq.oz.au>,
Warwick Allison <warwick@cs.uq.oz.au> 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> <Cn1945.8MC@cix.compulink.co.uk> <2mqrbc$50a@uqcspe.cs.uq.oz.au> <CnAL9x.MI3@uss.lonestar.org>
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 <warwick@cs.uq.oz.au> 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: <CnELI6.BIM@cix.compulink.co.uk>
Organization: Compulink Information eXchange
X-Newsreader: CixRead/CixComm
References: <57@cix> <Cn1945.8MC@cix.compulink.co.uk> <2mqrbc$50a@uqcspe.cs.uq.oz.au> <CnAL9x.MI3@uss.lonestar.org> <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 best
solution. Give the user a choice between the GEM Clipboard or a memory
buffer and place this with other user preferences.

Ofir   ogal@cix.compulink.co.uk



