Wimp message numbers

Are the wimp message numbers in the toolbox headers represent a complete list? My reason for asking is that impression uses one that’s not in the list, and I wanted to make sure a future allocation didn’t brake it all? Or was it allocated to CC? It’s number 19.

From the StrongHelp manual…
Message_ReleaseEntity (dec 19, hex 13)
This message should be broadcast to all tasks when your application has the clipboard and is about to quit.
Part of the NEW RISC OS Selection Model and Clipboard protocol.

But I suspect you meant hex 19?

No I do mean decimal 19 – Hex 13. This is used by the file import system of impression / artworks and others to process files from one format to another. When was it allocated? It does relate to the clipboard and dropping files from one app to another.

I don’t know when Message_ReleaseEntity was allocated (it’s not mentioned in the 1993 App Note about the clipboard, although it’s not in the new one either!), but have you seen this list?

In the latest DDE tboxlibs.h.wimp:

#define Wimp_MDataRequest 0×10
#define Wimp_MDragging 0×11
#define Wimp_MDragClaim 0×12
#define Wimp_MAppControl 0×15
#define Wimp_MMenuWarning 0×400c0

are all that are defined 0×13 is not?? [Labeled WimpRecorded in CC sources]

The action number is 0×80E1F, and the layout of the message is:

typedef struct
{
int destination_window;
int destination_icon;
int destination_x;
int destination_y;
int ref;
int file_type;
int dest_filetype;
char name¹⁶;
char params⁴⁰;
char pathname¹⁵²; // zero terminated
} WimpRecordedMessage;

Is this the same? Should the header file hold this.

the action number 0×80E20 is also used.

I think you’re getting yourself confused.

0×13, or 19, and the name “WimpRecorded” suggests that’s Wimp Poll reason code 19: User Message Acknowledge. That’s not a message number; it’s the reason code that un-claimed recorded messages are returned to you under.

Action numbers 0×80e1f and 0×80e20 are your message codes. They look to be in the regions that would have been allocated by Acorn to third parties, in which case they wouldn’t have been publicly acknowledged unless CC did so. They would be very unlikely to be in the DDE headers, as they’re most likely proprietary to CC. If you need to confirm that they’re allocated correctly, you might be able to get ROOL to confirm that they fall into a block allocated to CC in the database.

Actually, another look at the list of messages shows those codes to be in the range allocated to the OLE Protocol. Given that CC devised that and then bequeathed it to Acorn, it wouldn’t surprise me if Impression made use of some lesser known facilities within it.

It could also be that CC used the same allocation block for more than one thing: meaning that the OLE Protocol shares the number range with some unrelated message functions.

Given that you’re looking at the source, you’re probably best placed to answer that!

Actually, another look at the list of messages shows those codes to be in the range allocated to the OLE Protocol.

Is the OLE protocol described anywhere? I want to use a filetype that will load into Impression as a draw file but when CTRL-double clicked from within Impression will load itself into my app for editing; when saved it then just updates the image in Impression. Within the draw file (which will have an allocated filetype but not &AFF) will be a tagged item reserving space for the ‘source code’ from which the draw file was created inside my app.

Similar to TableMate files.

This any help?

http://www.riscos.info/index.php/OLE_Specification

Yes, many thanks.