Distribution: COMPANY CONFIDENTIAL
Project: Project
Issue: 0.03
Author(s): Julian Smith
Date: 25 Apr 1996
Last Issue: None
0.01 JPS 26 Apr 1996 First created. 0.02 JPS 26 Apr 1996 Added allocated SWI number (19) for Message_ReleaseEntity. 0.03 JPS 03 May 1996 Added note about passing taskhandle in 'window handle' field of Message_DataRequest.
The current clipboard protocol (see Support Group Application Note 240) results in all clipboard data being lost if/when the current holder of the clipboard quits.
Below is a possible way of rectifying this situation.
There are 3 propposed additions to the clipboard system:
The suggested protocol for giving the clipboard to the background task is as follows:
The quitting application broadcasts the following new message, based on Message_ClaimEntity:
Message_ReleaseEntity (19) 0 message size (24) ... 16 Message_ReleaseEntity 20 Flags: Bit 2 set -> clipboard being released. All other bits reserved (must be 0).
The background task then replies with a standard 'Paste' request, using Message_DataRequest, which the quitting application is expected to deal with as normal, before quitting.
This means that transfering the data to the background task can use the quitting-application's existing clipboard code.
Because the background task will never display the data, only send it to other applications whose filetype-preferences it doesn't know about, it will use an empty list of preferred filetypes in its Message_DataRequest message, indicating that it can handle any filetype.
When the background task has received the clipboard data, it should tell the rest of the desktop that it now owns the clipboard, using a broadcast of Message_ClaimEntity with bit 2 of the 'flags' word set, as described in the existing clipboard protocol.
If the quitting application doesn't receive a reply to its Message_ReleaseEntity, it should ask the user whether to save the clipboard contents. If this is required, a standard save-box should be used.
This will be a fairly simple application, with code for the standard clipboard protocols (for receiving the clipboard data from quitting applications, and sending clipboard data to other applications when a paste is requested), the detection of Message_ReleaseEntity, and the storing of data in application-space, a dynamic area or on disc.
On receipt of the DataSave message in the data-transfer protocol, the background task should attempt to reserve memory for the estimated size of the data. If there is enough memory, a standard memory-transfer should be carried out. Otherwise, the task should use the standard file data-transfer protocol, using a temporary file such as Wimp$ScrapDir>.Clipboard. From the point of view of the quitting application, this will look like a save to the Filer.
The background task doesn't import the clipboard into a window, but Message_DataRequest has a window handle at offset 20. The background task should put its task handle in this field, so that the application that owns the clipboard can simply reply to what it thinks is a window handle when it initiates the data-transfer of the clipboard with a Message_DataSave.
This avoids the need for any window-handle checking code in clipboard applications (eg TechWriter doesn't seem to check the window handle before replying to it, and will end up broadcasting its Message_DataSave if the window handle is 0).
It might be useful to extend the background task so that it provides a way of saving/loading the clipboard. This might not fit very well with the NC's limited desktop however.
There is no provision in this proposal for saving/loading the clipboard when the desktop is closed down or restarted. This is because there are a number of complications caused by such behaviour, briefly described below:
It would be possible to automatically save the clipboard or ask the user whether they want the clipboard to be saved when the background task / desktop is closed down, and then automatically load it when the background task / desktop is next started.
However, this gets complicated if the background task is not started up when the machine boots - the user may start it after using a different clipboard application, in which case someone has to decide what to do with the saved clipboard. The user may also decide to temporarily quit the background task in order to save memory, causing similar problems.
There are also problems with saving the clipboard on recipt of a Message_PreQuit, because of the way in which an application could halt the desktop-shutdown after the background task has saved the clipboard or been told by the user that the clipboard should be saved.
While these problems could possibly be worked around (eg by waiting for Message_Quit before saving the clipboard if saving was automatic, or the user had indicated that the clipboard was to be saved and restored on startup in a dialog box opened in response to Message_PreQuit), it seems rather complicated to implement in view of the problems with re-loading a saved clipboard the next time the desktop is started.
If the functionality of the background task is integrated into the Wimp in the future, saving of the clipboard when the desktop is shut-down will be much more practical. The background task will always be active, so there will be no possibility of it starting up after another application has claimed the clipboard.