How to add Copy and Paste to WIMP Window ?

!ARM_Debug(32) is a RISC OS debugger that I’m porting to RO5. Most of the complex debugging and data capturing is done in a relocatable module and can be saved out as a data file for subsequent analysis. Double clicking on these data files opens up the !ARM_Debug application (written in BBC BASIC), which shows the contents of the data file in a WIMP window allowing the address/instruction and registers to be read. This window is defined as a Risc OS template file that can be opened and edited in WinED or WinEdit etc.

How do I go about adding text ‘selection’ and ‘copy and paste’ to this window, so that I can copy any highlighted text to (say) !Edit or wherever ?

I see that RO5 has been modified during the last few years to ‘Add copy & paste and drag & drop operations to the Wimp’. Is there an easy way of modifying the BBC BASIC programme and/or the WIMP templates to provide ‘select/copy/paste’ functionality to move the window’s text to another application ?

Ralph

I know nothing of how to use the copy/paste interface (yet) – but it is probably a set of SWI commands to write to, or read from, the clipboard? If so:

How does the application display the data in the window? Does it display it in an ‘editable way’ (like an !Edit style window), or does it just ‘paint’ the text (directly drawing it when requested for Wimp_Redraw, or painting it into a sprite which is then used to display in the window?);

If it just draws the text, what is needed will be to find a way to determine what the user wants copied to the clipboard – via mouse clicks or a menu click maybe? – and then saving that to the clipboard. A simple interface would be to ‘click / hold / move mouse’, which then EORs what you have selected in the window, and the application then figures out what was selected once the user clicks ‘Menu’ then ‘Copy’?

How much data is shown in the window? Initially it may be easiest to ‘copy everything’ (if the clipboard can manage that), then, after pasting to !Edit, deleting what you don’t need manually?

How much data is shown in the window? Initially it may be easiest to ‘copy everything’ (if the clipboard can manage that), then, after pasting to !Edit, deleting what you don’t need manually?

!ARM_Debug was originally written on an ARM2 machine back in the mists of time. I’ve had a look through Theo’s WIMP code used to display the captured register data this morning. Theo uses ARM assembler routines to read the data from the data file and display it (to the window) using OS_Write0 and OS_WriteS calls as required – presumably for speed at that time. The max size to the captured register values data file is 99.999Mbytes, so no chance of buffering it on a 1Mbyte A310 (or whatever) ! Theo must be reading the data from the file as you scroll down the window, if the data file is large. You just don’t notice on an RPi, as everything on Risc OS is now virtually instantaneous compared to an ARM2 ;-)

So rather than try and implement select/copy/paste for this data I’ve decided to:

1. Add an additional option in the module to output the register data to a text file (this option already exists to output just address or address/mnemonic data in the module – so most of the work is already done).

2. Add an extra menu option to the !ARM_Debug BBC Basic programme to create a text file from the captured register data file, There are already menu items on this window – so adding a new menu item should be ‘relatively’ easy.

Ralph

Am not sure how complex this would be, but – I’m not sure how the data is stored, or how it is presented, but if there was some kind if numerical ‘index’ – something like a frame number, or snapshot number, it should be possible to make it output a range of ‘frames’ to a text file; you could even use a menu entry where you can enter a string, such as 37362:37800,:to generate a range of frames etc?

The use of OS_WriteS and OS_Write0 etc also suggests the code could be examined more easily for ‘how’ to decompress the data file into a readable text form. It sounds like an interesting project, and hope you can get it sorted soon!

On semi-modern versions of the OS (ie. 4.39 and 5.26-ish onwards) all you need is a writeable icon, and copy/paste should be automatic. If you’re not using icons (or want to do something more creative), you’ll need to implement it yourself which is a fairly long-winded process of wimp messages IIRC.

I can’t find a link to the protocol, but suggest Steve Fryatt as a resident clipboard expert – he wrote several programs to monitor clipboard activity. Annoyingly the exact implementations are subtly different between OS 5 and Adjust, although most of the protocol can be done “agnosticly” by applications. IIRC there’s a clipboard holder module in Adjust which aims to automate things a bit, whereas things are a touch more manual on OS5. However, as long as you handle and send the various messages, I think it mostly all works out OK.

Also Andy Vawer who implemented it into the RISC OS 5 wimp is a good contact.

On semi-modern versions of the OS (ie. 4.39 and 5.26-ish onwards) all you need is a writeable icon, and copy/paste should be automatic.

Thanks very much Andrew – this is just the type of top-level advice that I was after !

I added a writable icon to my app’s window using WinEd, by dragging the ‘text box’ in WinEd’s ‘Icon picker’ to my apps ‘window’ open for edit in WinEd (note: it wasn’t obvious to me just how to add an icon to a window in WinEd, so I added this step for anybody finding this post in the future).

Now I get an error message when I start the !ARM_Debug app "There is not enough memory to create this window or menu!. Progress – I’ll add some more memory tonight and see what happens:-)

Ralph

I’ll add some more memory tonight and see what happens:-)

That would work for the short term … but far better is to first use Wimp_LoadTemplate with r0=0, which returns the required sizes. Then get that memory, and the actual Load will work. The result it that it works dynamically however Templates are changed in the future, and with no wasted space either.

IRC there’s a clipboard holder module in Adjust which aims to automate things a bit, whereas things are a touch more manual on OS5.

There is a Clipboard module in the RO5 sources which eases use of the global clipboard in a similar way to ClipboardHolder. Putting a text string on the clipboard from BASIC is just a single SYS call:

SYS "Clipboard_Put",0,&FFF,Text$,LEN(Text$),"LeafName",0

Only drawback is that you need to build it yourself as it’s not part of any current RO5 roms/distributions.

That would work for the short term … but far better is to first use Wimp_LoadTemplate with r0=0, which returns the required sizes. Then get that memory, and the actual Load will work. The result it that it works dynamically however Templates are changed in the future, and with no wasted space either.

Thanks for the tip Martin. Using your method I found that the buffer and the indirect workspace needed to be massively larger for the writable icon to appear in the centre of my window. The writable icon now appears in the centre of my window, and the icon’s text is indeed selectable and I can copy the text “icon1” to an !Edit window. Just need to redirect all the OS_Write0 and OS_WriteS calls so they write to this icon and not to the window.

As an aside, whilst randomly messing about using trial and error to guess the buffer sizes, the !ARM_Debug front-end BBC Basic programme was crashing with an abort at &FC16D828. This crash was stopping ‘F12’ from bringing up the command line so I could not perform the usual “*where &FC16D828” to find out which module was crashing. A useful feature of the !ARM_Debug module is that CTRL SHIFT keypad minus takes you into the !ARM_Debug control screen. Once there !ARM_Debug supplies it’s own seemingly independent ‘*’ command screen. Typing “*where &FC16D828” in !ARM_Debug shows that this address is in the window manager module (as expected really;-).

Ralph

There are three different clipboard protocols on RISC OS.

• the ClaimEntity/DataRequest/ReleaseEntity Wimp messages from RO3 – ubiquitous
• the ClipboardHolder module SWIs from RO4 and RO6 – built-in
• the Clipboard module SWIs from RO5 – optional and not widely supported

Although it’s bureaucratic, the Entity protocol is the most widely used and ought to be implemented by anyone thinking of interacting with a clipboard concept. I’d strongly recommend not using the Clipboard module.

I think the current documentation for the first of these methods may still be the Acorn appnote. There is also a related appnote for the Drag and Drop protocol. I implemented both of these in the Impact database which has its own code for multi-line writable icons.