[softwarelist] Re: problem with holding format during copy/paste

In message <218f937e50.steve@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
          Steve Fryatt <lists@xxxxxxxxxxxxxxxxxx> wrote:

> On 22 Jul, Martin Wuerthner  wrote in message
>   <3f5f907e50.martin@xxxxxxxxxxxxxxxxxxx>:

>> In message <5db5867e50.steve@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
>>           Steve Fryatt <lists@xxxxxxxxxxxxxxxxxx> wrote:
>>
>>> I've just had a play: a short piece of text with formatting in O-Pro,
>>> copy, and paste back.  On RISC OS 5, it works as expected and the
>>> formatting is retained.  On RISC OS 4.37, I see exactly what Martin
>>> describes (ie. the formatting is lost). [...]
>>
>> Yes, we have been here before on this list, years before. However, the
>> problem was fixed back then, and it is still working fine here on RISC
>> OS 4.39 and RISC OS 6.14. Maybe RISC OS 4.37 behaves differently, but
>> that is not too likely. I tried it with the 2-Jun-2006 version of OP
>> 2.77 (which is I happened to have installed in my copy of VRPC).

> I'm using O-Pro 2.77, dated 14-Jan-09.
> [...]
> Looking at the messages on RISC OS 4.37 (and with O-Pro as above), when the
> text is cut, the Clipboard Holder asks for an empty list of types (ie.
> the first type is -1, or end of list) in the DataRequest message. I
> assume this means "whatever you like".

No. The specification is very clear about that: If the list is empty 
or none of the types in the list is recognized, the application *must* 
return its native type.

I just tried it again, and indeed: it goes wrong with 2.77 
(14-Jan-09), but it works just fine with 2.77 (02-Jun-2006).

I notice that the 2006 version does not respond to the ClipboardHolder 
asking for its data, which means OP keeps the clipboard and can paste 
its own text with effects. The 2009 version delivers the data as Text 
to ClipboardHolder and immediately loses the clipboard, so it cannot 
paste its own text with effects, which is a serious shortcoming. The 
2009 behaviour violates the Global Clipboard specification.

Neither of the two is correct. What OP should really do is to deliver 
the file to ClipboardHolder in its own file type, not as text. Then, 
ClipboardHolder is clever enough not to claim the clipboard itself (to 
allow the application to still convert its own data to other types). 
Of course, that might mean a considerable amount of work because it 
would mean that OP would have to be able to paste its native type from 
the global clipboard, which may or may not be difficult to achieve. 
This is how EasiWriter works, for instance, which has a fully 
compliant implementation of the global clipboard protocol.

The behaviour of the 2009 version of OP is clearly wrong and causes 
trouble. Its only minimal advantage is that the clipboard is still 
present after OP is quit, but very few users would even notice, so 
this is dearly bought at the expense of always pasting plain text.

If fully correct behaviour as described above cannot be implemented, 
then a quick fix would be to revert to 2-Jun-2006 behaviour, which was 
at least only slightly wrong and much less broken at user level.

Finally, a request: The next time you issue an update David, can we 
please have a new version number?

Martin
-- 
---------------------------------------------------------------------
Martin Wuerthner           MW Software          lists@xxxxxxxxxxxxxxx
---------------------------------------------------------------------
To unsubscribe or subscribe goto: http://www.freelists.org/list/davidpilling

Other related posts: