Clipboard module queries

I have a few queries regarding the Clipboard module.

Is anyone currently working on it? I’ve done some work on it lately (and have implemented most of SWI Clipboard_Get) but before doing more I’d like to make sure that there’s no duplication of effort.

The documentation states that the module will use its application slot for clipboard data but the code is using a dynamic area (or the RMA when DA support is turned off). Does anyone know whether it’s the code that needs changing or that it’s the documentation that is out-of-date?

When SWI Clipboard_Put is called in response to a Message_Put it acknowledges the message and then calls the statehandler. Am I correct in thinking that it should first read the clipboard data passed to it before calling the statehandler?

The documentation states that the module will use its application slot for clipboard data but the code is using a dynamic area (or the RMA when DA support is turned off). Does anyone know whether it’s the code that needs changing or that it’s the documentation that is out-of-date?

I haven’t looked at the source for Clipboard for ages, so I can only talk in generalities. But as no one else seems to want to reply I don’t think it’ll do any harm.

There are some minor advantages in using the application space, mainly on the Iyonix/RO5.

Firstly if you wanted to cut a very large piece of data to the clipboard (say a couple of hundred megabytes) this would require a big chunk of address space from the DA Area, possibly causing fragmentation.

Second is that if the clipboard module crashes any used up memory would be automatically released – an exit handler would be required to automatically kill off a DA.

Conversely on R04/6 Dynamic areas are superior because you aren’t limited to 26MB.

IIRC the documentation also has differences in the spec for Clipboard_Get/Put compared to what is stated in the source files. I think you should probably treat it as a guide at the moment rather than a rigorous specification.

IIRC the documentation also has differences in the spec for Clipboard_Get/Put compared to what is stated in the source files.

If you remember anything specific then I’d be interested in hearing it. It would be helpful in synchronising source and documentation.

I think you should probably treat it as a guide at the moment rather than a rigorous specification.

Yes, that’s what I’m doing at the moment. However it would be good if a decision on how things are stored could be reached before an updated version of Clipboard is made available.

Progress so far: All of the SWIs are now fully implemented with the exception of Clipboard_CatchDrop. A new test application has been added to exercise Clipboard_Get, and work has started on a simply clipboard viewer.

If you remember anything specific then I’d be interested in hearing it. It would be helpful in synchronising source and documentation.

Okay, from examining the sources/document:

;-----------------------------------------------------------------
; Clipboard_Get - get data from clipboard
;
; On entry: R0 = flags
;             bits 0-2: notify type:
;                        0 => send message Message_ClipboardFetched
;                        1 => call a callback routine
;                             (may corrupt R0-R3, R14; preserve rest)
;                             R0=pointer to data, R1=data len, R2=data type
;                             User mode, R13->512 bytes+ of stack
;                        2-7 reserved
;                  3-30: reserved
;                  31: end operation and dispose data
;           R1 -> list of filetypes (terminated by -1), needn't be static
;           R2, R3 depends on notify type
;             0 => R2=reference
;             1 => R2=routine to call, R3=value to pass in R12
; On exit: R0, R1 preserved
;          R2, R3 depend on notify type
;             0 => R2, R3 preserved
;-----------------------------------------------------------------

R0 =     flags:     bit 31 set     =>     flag reply messages
as for the attention of the Wimp (this bit must only be set by the Wimp) 
all others are reserved and must be clear

R1 =     destination window handle 
R2 =     destination icon handle (-1 if none) 
R3 =     destination x co-ordinate 
R4 =     destination y co-ordinate 
R5 =     pointer to list of data types that the task is interested in receiving,
in order of preference, terminated by -1 (may be a null list if the native format is required)

This seems like quite a significant difference to me.

This seems like quite a significant difference to me.

Yes, that is quite a difference. The log file explains why this is; the module has been changed to handle multiple concurrent data transfer transactions. Code that hasn’t been updated yet – such as Clipboard_Get – is commented out pending a rewrite. So, in this case it’s the documentation that’s correct and it’s what I based Clipboard_Get on.

Fred’s updates to the Clipboard module sources are now in our cvs repository. We will shortly be releasing pre-built versions of the module but for the time being you’ll have to build it yourseslf if you want to give it a try.

Steve, would you be willing to add the PutClip and GetClip applications to the pre-built stuff? I think they would be useful in showing folks that the Clipboard module does work, there being no other applications currently that use the module. They would also show how to use the module. TIA.

No problem. Please drop me an email to srevill@riscosopen.org to remind me. Thanks.

GetClip and PutClip are now available from the downloads pages, under applications → test. Note: until yesterday, it was version 0.08 of the Clipboard module on our downloads pages. The fully working version is 0.09 which is now available. Earlier versions won’t work very well.

To help prove that no good deed goes unpunished: I’ve opened a ticket for some bugs that I’ve found in PutClip 0.09

http://www.riscosopen.org/tracker/tickets/180

Firstly, thanks to Steve for adding PutClip and getClip to the pre-built applications and putting up the correct version of the Clipboard module.

Thanks to James for reporting these bugs. I’ve updated the bug status with my findings. Entering text directly just wasn’t considered, I’ve done masses of tests on the module and I’m way too lazy to keep typing test phrases, drag-and-drop is so much easier. ;-)

The draw file problem seems to be caused by the application creating the draw file (NetSurf) not setting up the bounding box for the main group in the image. It’s just all zeros leading to a division by zero error.