[softwarelist] Re: OvPro and RO 6.06
- From: Steve Fryatt <lists@xxxxxxxxxxxxxxxxxx>
- To: davidpilling@xxxxxxxxxxxxx
- Date: Sat, 16 Feb 2008 12:43:39 GMT
On 16 Feb, Martin Wuerthner wrote in message
<107afc714f.martin@xxxxxxxxxxxxxxxxxxx>:
> In message <2089bb714f.Jo@xxxxxxxxxxxxxxxxxxxxxxxx>
> John Tytgat <John.Tytgat@xxxxxxxx> wrote:
>
> > In message <1357b7714f.steve@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> you wrote:
>
> > > It's got the clipboard holder, which does something along the lines
> > > of take cut/copied items off the hands of the originating
> > > application and then supply them in response to pastes. I've never
> > > found a definitive explanation of exactly what it does -- but ISTR
> > > that when it came out, it broke ClipMan, which does a similar task
> > > to Dave's utility.
>
> > More info:
> > http://developer.riscos.com/registered/Documents/Clipboard/clipboard.html
>
> > BTW you can use Google for this. 'site:riscos.com clipboard' gave
> > that link and several other ones.
>
> Thanks, but that document does not even mention ClipboardHolder nor
> does it shed any light on what it does. One of the other links gives at
> least a little glimpse:
> http://select.riscos.com/prm/desktop/clipboardholder.html It lists two
> SWIs provided by ClipboardHolder that applications can use to directly
> copy/paste files to/from the clipboard.
Indeed: as I originally said, before John tried to be 'clever' and
patronising, there is information available about what the clipboard
holder does (including those two SWIs in Select, which IIRC are used by
Edit, Draw, and writable icon support), but not *how* it does it or *why*
it does it that way.
A few months ago, when debugging IcnClipBrd, I spent a long time looking
at Wimp messages passing between tasks in an attempt to fathom what was
actually going on when cut/copy was done on the global clipboard. As a
result, and unlike John, I'm at least aware that there is stuff I don't
know about what is going on. What transpired from my investigations was
this:
- On pre-Select machines (RISC OS 5, RISC OS 3, probably 4.02 as well), a
cut/copy results in the task concerned issuing a Message_ClaimEntity and
then retaining the clipboard data. This is how the old Acorn docs define
the clipboard protocol to operate.
- With the Clipboard Holder on Select running, the MessageClaimEntity is
followed immediately by a Message_DataRequest from the CH. The clipboard
contents is transferred across, and then the CH sends out its own
Message_ClaimEntity. That is, the originating task does not retain the
clipboard contents, which is different from how it works on other versions
of RISC OS.
Note that there is nothing /wrong/ with the Select way of working: it's a
perfectly legitimate use of the protocol and will not affect applications
which /use/ the clipboard. However, multiple clipboard applications will
be trying to do a very similar trick in order to control the data held on
the clipboard. This means that there is a good chance that they will
conflict, as I commented had already happened with ClipMan.
Also note that pre-Select behaviour can be obtained by killing the
clipboard holder module on Select. However, this breaks clipboard support
in Paint, Draw and writable icons (again IIRC), and anything else that
uses those two clipboard SWIs. It isn't a sensible way out of the
problem.
Back to Dave's problem with the Clipboards applet...
In the light of the information above, and with a little more snooping on
Wimp messages, it's actually fairly easy to explain what is going wrong.
Let's start with the situation before the clipboard holder came along.
As long as we only cut or copy within O-Pro, then the Clipboards applet
does exactly what we would expect. However, as soon as we cut or copy
from another global clipboard enabled application, the clipboards applet
'stops working' because O-Pro is now pasting data from that external
application and so totally ignores its own internal clipboard support.
Whatever board we select in the Clipboards window, the data pasted is that
from the other application, collected via Message_DataRequest. The
solution is to cut or copy something from O-Pro to a spare clipboard in
the applet, so that O-Pro becomes the owner of the global clipboard again.
On Select or RO6, with the Clipboard Holder present, O-Pro is never the
owner of the global clipboard because the CH claims it away as soon as
O-Pro sends around the first Message_ClaimEntity. As a result, O-Pro will
always take the text to be pasted from the global clipboard, which will
always be the last thing to be cut or copied from O-Pro (or elsewhere).
The clipboards applet is totally out of the loop.
I don't think that there is anything that David P can do to fix this,
without breaking global clipboard support in some way. Like ClipMan, the
clipboards applet seems to be another unintended victim of the
over-zealous Clipboard Holder.
From a position of ignorance, and knowing that there is stuff about the
Clipboard Holder that I don't know, I would have thought that a change to
the way that the module operates would sort things out. If the CH only
holds data that has been cut via its own SWIs, or that has come via
Message_ReleaseEntity from a dying task, it would still continue to fulfil
its purpose of holding clipboard data for posterity, while not conflicting
with other utilities like this. I can only assume that this wasn't done
because ROL felt that Message_ReleaseEntity wasn't well-enough supported,
or because there is something else we don't know about what the module
needs to do.
So, as I originally said, John, I'd like to see a full functional
description of what the Clipboard Holder does, how it does it, and why it
does it that way -- if only to be able to accept that there is a good
reason for breaking things like this. Your links (and Google), don't
help.
To Dave S, the only sensible fix is to turn off Global Clipboard in
O-Pro's General choices. You can't then cut and paste between O-Pro and
other apps, but the multiple clipboards in the clipboards applet will work
again.
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
To unsubscribe or subscribe goto: //www.freelists.org/list/davidpilling
Other related posts:
