![[JPEG image]](images/pcal.jpg)
The variable names used in the example BASIC program are included after the message number.
Message_WhosAbout (&83484) (Msg_Whos%)
Broadcast by Local task when opening Utility sub-menu/popup (see the section on user interface).
The block pointed to by R1 contains:
R1+20 filetype of object
R1+24 address of object tag
R1+28 PCA version word:
all bits clear - PCAv1.00
bits 0-12 Local task flags:
b0 reserved. Write as zero and assume zero.
b1 reserved for object change protocol. Write as zero and assume zero.
b2 set - Local task supports undo extension protocol.
b3 set - Local task is using PCA-2 user interface.
b4 set - Local task supports Help extension protocol.
b5 set - Local task is a colour history provider
b6 set - Local task would like to inplace redraw if possible
b7-12 reserved - set to zero.
bits 13-15 Local task request action flags:
b13 Clipboard paste please
b14
b15
bits 16-31 reserved - set to zero.
b2 If the Local task can undo the operations made on the object by a remote then it should set this bit, and handle Message_MiscOp calls 83482 and 83484 as defined below. If this bit is clear then a remote app. which might want to make use of undo can take its own action.
b3 When set the tool should pass the new style 32x32 pixel 'pca' sprite in Message_ImHere instead of its RISC OS !appsprite. There should be two forms of the pca sprite, 'sprite' and 'psprite' (see example icons).
b5 If this bit is set then the Local task supports the PCA palette SWIs and messages (see miscop messages below). Immediately after sending DoYourStuff it will send MiscOp SubReason_PaletteWindow
b6 If this bit is set then the Local task would like to redraw the object when doing inplace editing (the local task can redraw it in a special way). This bit may be ignored by the applet if it needs to redraw its own 'widgets' over the object. It can also be ignored if the applet has a 'fast' redraw mode (see PCA inplace v2 details below).
b13 This bit is set by a NC style Local task when it selects an applet as a result of a 'Paste from clipboard' action by the user. It indicates to the applet that it would like the applet to paste from clipboard. This would typically cause the applet to find out what is on the clipboard and if appropriate data exists, to get a copy of it using the standard clipboard protocol before allowing the user to paste it into the object.
Receiving remote tasks should respond with Message_ImHere as defined below if the filetype is 'interesting'. You can examine the data in the tag at R1+24 if the filetype alone does not suffice (for example, a program which can only edit 32bpp sprites should examine the sprite type word at !(R1+24)+(R1+24)!4) +40 (ie tag address field+offset to object field)+40 before sending Message_ImHere).
Message_ImHere (&83485) (Msg_Im%)
Sent by Remote task to Local task. Local records the data passed for later use in creating a dialogue box or menu.
The block pointed to by R1 contains:
R1+20
bits 0-7 flags:
b0 Spritename supplied
b1 Info available
b2 Generate 'Ping' messages.
b3 Tool wants to 'own' the object
b4 Tool wants In place editing
b5 Tool can do inplace v.2 (b4 must also be set)
b6 Tool is busy - load another copy if chosen [NYI]
b7 Tool is multi-document aware
b8-31 Reserved - 0
R1+24 Tool id.
R1+28 String. Menu entry/Function name (eg. Contrast...).
Length limited to 31chars+terminator.
R1+60 String. Name of sprite in wimp sprite pool
(if b0 of R1+20 is set)
The tool id is intended for remote tasks which provide more than one
utility. It is returned to the task with Message_DoYourStuff.
Flags:
b0 indicates to the recipient that there is a sprite name at R1+60
- the sprite is stored in the Wimp sprite pool and should be
used when rendering the popup dialogue box.
b1 indicates that the tool can provide a response
to Message_Info.
b2 indicates that the tool would like to 'move' with
the selected object (ie it gets sent Message_DoYourStuff
again when the 'selected object' changes.
Note: If preferred, the local application can offer this as an
option as it is part of the standard that remote applications
must accept Message_DoYourStuff messages for objects
they cannot edit without producing an error.
b3 indicates that the tool wants to 'own' the object.
Local task should send Msg_Deselect for the object
before sending Message_DoYourStuff if this bit is
set. Do not set this bit unless you have to as it
will prevent other remote tasks from sharing the
object at the same time. It should only be set when
the remote task wants to 'take over' the object completely.
- such as Composition taking over a 32bpp sprite
for use as a canvas.
b4 This bit is designed to allow for real 'in place editing'
operations. Because of the amount of code necessary
at the local end to handle this it has been defined
as an optional part of the standard.
b5 This indicates that the tool knows about inplace editing (v2)
where a nested window is opened and the tool redraws the object.
Some tools allow the local task to override this by setting bit
6 of the PCA version word in Message_DoYourStuff. Some tools
may ignore this though if they need to draw their own user
graphics over the object (drag handles etc.)
b6 NYI
b7 Indicates that the tool is multi-document capable
If b7 is set then b6 should only be set if the tool has a limited maximum number of documents and all of them are currently in use.
Local applications which do not support in place editing should clear bit 4 of the flags word and send that with DoYourStuff. On receipt, the remote application should check if bit 4 is still set and if not open a remote window onto the object.
Message_DoYourStuff (&83486) (Msg_Do%)
The block pointed to by R1 contains:
R1+20 Filetype of object
R1+24 Address of object tag
R1+28 PCA version word:
all bits clear - PCAv1.00
bits 0-12 Local task flags:
b0 reserved. Write as zero and assume zero.
b1 reserved for object change protocol. Write as zero and assume zero.
b2 set - Local task supports undo extension protocol.
b3 set - Local task is using NC user interface.
b4 set - Local task supports Help extension protocol.
b5 set - Local task is a colour history provider
b6 set - Local task would like to inplace redraw if possible
b7-12 reserved - set to zero.
bits 13-15 Local task request action flags:
b13 Clipboard paste please
b14
b15
bits 16-31 reserved - set to zero.
R1+32 Tool id
R1+36 Tool flags word
R1+40 String. Name of object or null (&0)
Sent by Local task to remote task depending on entry selected in Utilities sub-menu/dialogue. Remote task should record the tag address and open its window (or just its toolbar if bit 4 of the flags word is set).
Notes:
If the Remote task set bit 4 of the flags word in Message_ImHere when replying to Message_WhosAbout it should check that this bit is still set now. If it has been cleared then the Local task cannot handle remote messaging and the Remote task must open a separate window onto the object.
If bit 4 is still set it means that the local task is willing to participate in an in-place editing session. In this case the Remote task should simply open its toolbar and send Message_HookMe to the Local task to ask it to intercept mouse button and other Wimp events. Receipt of this message will also cause the Local task to send Message_ObjectPosition to move the remote tasks toolbar to the correct position.
Nothing about the standard prevents the object changing type (eg from sprite to Drawfile) between Message_WhosAbout and this message. On receipt of this message the Remote task must therefore check the filetype field and as much of the object's data structure as necessary to ensure that it can edit the object and delink/ignore the message quietly if the type is not to its liking. This allows the Local task to 'move' a remote task to different objects cleanly.
Before sending Message_DoYourStuff with bit 4 set the local task should broadcast Message_UnhookMe to prevent more than one remote task attempting to do in-place editing at once.
Before sending Message_DoYourStuff with bit 3 set the local task should broadcast Message_Deselect as the remote task in question wants to 'own' the object.
The PCA version word at R1+28 is very much the same as the same word in Message_WhosAbout. The only difference being in the interpretation of bit 3. b3 If this bit is set then the applet knows that it is expected to use a NC style user interface. If the applet has the ability to look like a NC app. then it should do so, hiding window titlebars and rearranging toolbars to match the NC look and feel.
Message_Deselect (&83487) (Msg_Desel%)
Broadcast by Local task when the object has been deleted.
The block pointed to by R1 contains:
R1+20 Filetype of object. R1+24 Address of object tag
All Tasks interested in the object should close their window/abandon their operations as the object in question has been removed from the PCA system (usually because it has been deleted). Local tasks must generate this message when deleting an object, quitting etc. or remote tasks using the object will crash. If the Local task is using PCASupport for tag generation it should call SWI PCA_DeleteAndKill which will delete the tag and send this message in one operation but only when the object really is being deleted.
Note: This implies that the remote task, on receipt of this message cannot rely on more than the tag address as a key to the object. It _cannot_ access the object data via the tag passed as SWI PCA_DeleteTag has already been called (the address fields within the tag will contain -1 and the object data itself may well have been discarded). This is unavoidable without a two message (Message/Ack) deselection system which would be more difficuilt for tasks to handle. Especially (as is often the case) if the local task is about to quit.
Message_DoneMyStuff (&83488) (Msg_Done%)
Broadcast by a task when it has modified the object. All tasks accessing the object other than the originator of the message should recognise this message and redraw the object.
The block pointed to by R1 contains:
R1+20 0 R1+24 Address of object tag
Use this message for 'whole object changed' operations which do not involve changes to the object's basic structure (Eg. image filter of sprite).
Note: Recepit of this message by the Local task should not be taken as an indication that the remote task is no longer interested in it. That is what Message_UnhookMe is for.
Message_Changed (&8348A) (Msg_Changed%)
Broadcast by Local or Remote task when the object has changed (either in size or its details). Task should act as if it had got a new DoYourStuff message.
Broadcast by Remote task after it has changed the object's size. Local and other interested Remote tasks will re-read the object's details and redraw the object.
The block pointed to by R1 contains:
R1+20 Filetype of object R1+24 Address of object tag R1+28 reserved - 0 R1+32 String. New name of object or zero for no change.
Note: Nothing about the standard prevents the object changing type (eg from sprite to Drawfile). On receipt of this message please check the filetype field as well as all necessary aspects of the object's data structure. If the object is not to a Remote task's liking it should send Message_UnHook and delink quietly.
Message_ResizeRequest (&8348B) (Msg_Resize%)
Sent by Remote task to Local (task handle in R1+4 of DoYourStuff message). If the Local task fails to deal successfully it will claim the message.
The block pointed to by R1 contains:
R1+20 0
R1+24 Address of object tag
R1+28 reserved - 0
R1+32 New size. Total size of object structure
(including header, offset to base etc.) if flags b1
clear otherwise new size of object itself.
R1+36 Flags
b0 set 'Resize associated objects as well'
b1 set 'New Size is for object alone - does not include header.'
If the Local task succeeds then it will send Message_ResizeAck (basically, copy R1+8 to R1+12, put Message ResizeAck into R1+16, update R1+32 and return to sender). On receipt of ResizeAck message the sender of ResizeRequest should modify the object appropriately (for example, adding rows/columns to a sprite).
Notes:
You must be prepared for the resize request to fail in which case it is the responsibility of the Local task to report to the user and the Remote task to continue safely.
If the ResizeAck message returns to a Remote task you must check that the field in R1+12 is equal to the MyRef generated by the Resize message you sent to ensure that the ResizeAck is for the object you have requested be resized. If it is, ensure that the object is in a renderable state before the next Wimp_Poll by updating the relevant parts of the object's internal data structure.
The local task's only modification to the data after a Resize is to write new size fields where appropriate and to update the object's tag address fields if the object moves. For sprites the new total area size should be written into 'Base of data'+0 - it does not know what the Remote task is going to do with the sprite and therefore cannot make any other modifications to the data.
For data types which do not store size within their data structure then the length field of the tag should also be modified (along with the address fields if the object has to be moved).
After modifying the object the Remote task must broadcast Message_Changed.
Composition will read bit zero of the flags word. If this bit is set, it will resize masks associated with the sprite in question as well. The amount by which masks will be resized is calculated from the resize-request for the sprite itself. Other applications can ignore or act on this bit as they wish. The task which requested the resize must be able to handle either action.
Bit one of the flags word is intended to facilitate the resizing of paths in Drawfiles and similar data structures under the PCA though no code has been written to do this yet.
This is what you do to change the size of an object you are editing:
From a Remote task's point of view:
Send Message_ResizeRequest and keep myref generated >from the message. On receipt of ResizeAck check myref, modify object data and broadcast Message_Changed.
From the Local task's point of view:
On receipt of Message_ResizeRequest resize object if possible, update the objects tag anchors and send ResizeAck otherwise claim the message and report an error to user.
Both Remote and Local tasks:
On receipt of Message_Changed re-read the object header as if it was newly created and redraw the entire object. (You may need to regenerate an area of your window the size of the old object - remember the new object may occupy less screen area).
Resize speed issues
When the object being resized is very large, VM (Virtual Memory)is being used, or the resize requests are frequent, there may be a performance issue. In such situations the Local task should consider moving the object to the top of its data storage area to prevent repeated memory moving operations. In applications where many small resize requests are likely then consider employing a tag extension system similar to the one defined above for text files to reduce the frequency of the resize requests.
Message_UpdateArea (&8348C) (Msg_Uparea%)
Broadcast by task when it has modified part of an object. Apps interested in the object should redraw the appropriate area of the object as quickly as possible if they have a window onto the object open.
The block pointed to by R1 contains:
R1+20 Format of subsequent data (0) R1+24 Address of object tag R1+28 Xlow (OS units at 1:1 scale) R1+32 Ylow (OS units at 1:1 scale) R1+36 Xhi (OS units at 1:1 scale) R1+40 Yhi (OS units at 1:1 scale)
where coordinates are relative to the bottom left of the object.
Currently this is the only format supported by code (working with bitmap sprites).
Other proposed formats are as follows:
R1+20 Format of subsequent data (1) R1+24 Address of object tag R1+28 Xlow (Draw units = OS units <<8) R1+32 Ylow (Draw units = OS units <<8) R1+36 Xhi (Draw units = OS units <<8) R1+40 Yhi (Draw units = OS units <<8)
where coordinates are relative to the bottom left of the object.
R1+20 Format of subsequent data (2) R1+24 Address of object tag R1+28 Xlow (Draw units = OS units <<8) R1+32 Ylow (Draw units = OS units <<8) R1+36 Xhi (Draw units = OS units <<8) R1+40 Yhi (Draw units = OS units <<8)
where coordinates are relative to the top left of the object.
If you have anyother suggestions please contact Clares or the author.
Message_ResizeAck (&8348D) (Msg_ResizeAck%)
Sent by Local task when a resize request has succeeded. On receipt by a Remote task, check that R1+12 is the myref generated from Message_ResizeRequest before modifying the object data structure and broadcasting Message_Changed.
The block pointed to by R1 contains:
R1+20 reserved - 0 R1+24 Address of object tag R1+28 reserved - 0 R1+32 New size allocated to object R1+36 Flags
Message_MiscOp (&8348E) (Msg_Misc%)
This message is designed to provide an extension hook to the PCA message block. It also allows a private interface option for PCA programs without them having to request other message allocations from Acorn.
The block pointed to by R1 contains:
R1+20 Sub-reason code
- other data dependant on sub-reason code.
The sub-reason codes available to application developers are allocated in line with SWI and Message blocks - if you have one of these then those values may be used by your programs. Where appropriate, please make details of your messages available to the PCA community by sending them to Clares for distribution.
Several sub-reason codes (within the PCA message block itself) have been used to extend create several 'mini-protocols' which may be of interest to PCA developers. Details of the subreason codes used follow.
SubReason_GiveAssociatedData (&83480)
Broadcast by remote plug-in when it would like to know more about the object.
The block pointed to by R1 contains:
R1+24 Address of object tag
SubReason_AssociatedDataCompo (&83481)
Sent by Compo to Remote which broadcast GiveAssociatedData containing a tag pointing to a Compo object.
The block pointed to by R1 contains:
R1+24 Address of object tag
R1+28 reserved - 0
R1+32 two eight bit and one sixteen bit fields
bits 0-7 Masks in use by object
bits 8-15 Format of subsequent data (zero)
bits 16-31 Reserved
R1+36 Reserved (0)
R1+40 Blend mask address or zero = no Blend mask
R1+44 Tint mask address or zero = no Tint mask
R1+48 Curve mask address or zero = no Curve mask
R1+52 Displace mask address or zero = no Displace mask
R1+56 Shadow mask address or zero = no Shadow mask
R1+60 Reserved
R1+64 Reserved
R1+68 Opacity of object (65536=solid 0=transparent)
R1+72 Math type in use for object
Notes: The 'mask address' passed is the address of the base of a sprite area containing one eight bit greyscale sprite (at address+address!8). The size of a mask should not be assumed to be the same as that of the object - read it from the mask sprite data or use OS_SpriteOp to extract it.
The data returned by this message is fragile - re-read whenever you want to make use of it.
Undo protocol
This uses Message_MiscOp.
R1+20 SubReason_UndoUpdate (&83482) R1+24 Address of objects tagThe Remote task sends this message when it wants the local task to keep a snapshot of the objects current state. How the Local task does this is up to it. Uncompressed in a Dynamic area, compressed, on disc - whatever.
R1+20 SubReason_UndoPlease (&83483) R1+24 Address of object tagThe Remote task sends this message to the Local when it wants it to undo the changes made since the last UndoUpdate or undo grab made by the Local task. The Local task will generate Message_Changed by way of a response which the Remote task should take as a cue to redraw the 'undone' object.
Help protocol A method whereby an applet can pass help text to the Local task for inclusion in its help bar. Used in project NCPaint. This protocol uses Message_MiscOp.
R1+20 SubReason_ToolHelp (&83484) R1+24 Null terminated stringEgs.
"Hold the left button and move the pointer to draw a line"
(The pointer is over the work window)
The applet should send this message to the local when the users pointer moves over a tool it wants to give information on. It should also be sent when the pointer moves over its trap window during inplace editing. For efficiency, it should not send this message unless the string has changed since it was last sent or the pointer has been outside its window(s).
Colour history protocol
This uses Message_MiscOp.
The Remote task sends this message when it wants the Colour history provider to remember the colour specified. If R1+28 contains -1 then the Colour history provider should roll a temporary buffer of colours right and insert the supplied colour in the first entry. If a value other than -1 is supplied then the colour should be inserted in the specified slot in another palette of more permanent colours for later use. Valid values are 0-255 though values outside this range should not cause a crash.
The Colour history provider will send this message when the user drags a colour from one of its palettes to the applet. The applet is determined by the window and icon handle when the drag event ends, in this respect the message is similar to Message_DataSave. However, the destination window handle, icon handle and coordinates may be given as -1. This allows the sender to send this message if the drag is made to an icon within its own workspace which is used to represent the applet.
Local tasks which have bit 5 set in their PCA flags word in Message_DoYourStuff will send this message to the remote task immediately after it has been given the object. The local task will also generate this message if its palette window changes. A remote task which supports palette management should use the information passed in this message to open a small 'colour patch' window nested within the local tasks window. This is to give the appearance that the colour information handled by the remote task is actually owned by the local task.
This message is sent by the Remote task to the task which sent it SubReason_PaletteWindow if it wants to change the size of the palette window in order to incorporate a status bar or other information. Values in R1+32 and R1+36 are OS-unit offsets which will be added to the palette window x0,y0,x1 and y1 extents. The palette window will be reopened extended to the new size and SubReason_PaletteWindow returned. Applets should set a flag when calling SubReason_ResizePaletteWindow and not attempt to send the message again if the returned size is different to that requested. They should take other action instead.
This message is broadcast by the owner of the palette window whenever it is moved. The applet can use it to attatch a status/tool pane.
Message_Info
(&8348F) (Msg_Info%)
Sent by Local to Remote application when the info button in the pop-up is clicked.
The block pointed to by R1 contains:
Remote application should write a suitable info string into +20, change the
message size and return the message to the sender.
Example info strings:
Message_ObjectPosition
(&83490) (Msg_ObjPos%)
This message is generated by the Local application after receipt of Message_HookMe, object repositioning operations and window
open operations, if the Local application supports 'in-place editing'.
The block pointed to by R1 contains:
On receipt, the Remote task should open its toolbar/infobar relative to the
positions in R1+32 and R1+36 behind the window handle at R1+44. The
coordinates passed in R1+32 and R1+36 should be limited to the windows
visible area (by the Local task) while those at +52 and +56 should not.
The information at R1+28 and R1+48 onwards is for use by the Remote task
during mouse click operations on the object. To convert mouse coordinates
read directly it should subtract the values at R1+52,R1+56 from the raw
mousex and mousey coordinates, and then scale them by the factors in
R1+28 and R1+48.
The X and Y scale factors are in 16.16 format. To convert a scale factor
into this format, multiply by 1 << 16. For example, 100% = a scale factor of
one and is therefore (1 << 16) * 1 which is 65536 or &10000. 150% = a scale
factor of 1.5 and is therefore (1 << 16) * 1.5 which is 98304 or &18000.
See the remote painting code (DEFPROCremote_win) in !Spaint for a practical
example of what you should do.
Message_HookMe
(&83491) (Msg_Hook%)
This message is sent by the Remote task to the Local task. It indicates to
the Local task that it should begin intercepting mouse button and other Wimp
events to the object and send them to the Remote task. On receipt, the Local
task should create a trap icon over the object (using the button type in
r1+28) and send Message_ObjectPosition.
The block pointed to by R1 contains:
To make life easier for the remote task the Local task should also take note
of the window handle at R1+32 and insert that value into the window handle
field when passing on Wimp messages. This allows the remote task to use much
of the same code to deal with remotely generated messages and messages to
their own window.
The optional indirection string at R1+36 is intended to allow for adding a
mouse pointer change when entering in-place edited objects. Take care with
this string as certain settings can disrupt the Local task's message
trapping. This extension is optional. Some local tasks may not support it so
do not rely on it.
If the remote task is already editing an object in-place (and it is going to
replace it) then it should send Message_Unhook to the local task previously
being worked with so that it deletes its trap icon.
Please see the section below on In-place editing for details of the best
method of trapping messages and the alterations which should be made before
forwarding them.
Message_UnhookMe
(&83492) (Msg_Unhook%)
This message is sent by a remote task to the Local task (or local to remote)
when it wants to 'unhook' from the object.
The block pointed to by R1 contains:
This message should be used by a Remote task to indicate its lack of
interest in an object. After sending this message the Remote task should
forget any references to the object and close its toolbar and/or window.
Little action need be taken at the Local end on receipt of this message
unless 'Inplace editing' is going on between the tasks in which case it
should remove the traps on Button click messages etc for the object. If the
Local task wishes to be efficient in its generation of PCA messages then it
should keep a counter for each object in the PCA system, increase the
counter on each call to Message_DoYourStuff and decrease it on each receipt
of Message_UnHook. Then PCA messages need only be generated in response to
changes made by the Local task if the objects counter is greater than zero.
When the counter reaches zero the Local task should broadcast Message_Deselect
as a saftey measure to ensure that all Remote tasks stop using the object.
The 'unhook type' at R1+36 currently has two defined values:
All values other than zero should currently be treated as 'permanent'.
Message_AppletsChanged
(&83493) (Msg_AppletsChnged%)
Currently no other information is passed with this message. It informs dynamic pca applications that either:
Message_ColourSetChanged
(&83494) (Msg_PalChnged%)
This message is broadcast by a colour history provider task when the PCA palette has changed (see colour history protocol below).
Message_AppletQuitIfIdle
(&83495) (Msg_KillIdle%)
This message is broadcast by the PCA support module task every two minutes (by default - see SWI PCA_AppletTimeOut) to assist in the implimentation of a simple applet timeout scheme. Any running pca applets that are not editing objects and are not 'working' as normal RISC OS tasks should quit on receipt.
R1+20 SubReason_RememberColour (&83485)
R1+24 Colour to remember &BBGGRR00
R1+28 Slot to insert colour into or -1 to use a FIFO buffer
R1+20 SubReason_UseThisColour (&83486)
R1+24 Colour to use &BBGGRR00
R1+28 Destination window handle or -1
R1+32 Destination icon handle or -1
R1+36 Destination x coordinate or -1
R1+40 Destination y coordinate or -1
R1+44 Colour importance (described below)
R1+48 Null or Null terminated colour name
On reciept, the applet should decide how to use the colour data given to it and update windows etc. as necessary. It should not use SubReason_RememberColour as the colour given it will already appear on the senders colour palettes.
R1+20 SubReason_PaletteWindow (&83487)
R1+24 object tag
R1+28 handle of local tasks palette window
R1+32 xoffset within this window (from left)
R1+36 yoffset within this window (from top = windowblock!16)
R1+40 preferred width of colour patch subwindow
R1+44 preferred height of colour patch subwindow
R1+48 basic width of palette window
R1+52 basic height of palette window
If the window handle at R1+28 is -1 then the remote task should resume control of its own colour settings. The suggested way to do this is to attatch the colour patch window to its toolbar.
The basic width and basic height in R1+48 and R1+52 is the size required by the palette window to accomodate its own icons etc (which will include your colour patch at the offsets given). If you require more space, for example to add another nested tool status window you should call SubReason_ResizePaletteWindow which is described below.
The remote task should not check that the task which sent it this message is its local task. It is sufficient to check the tag passed in R1+24 is one it has been given to edit. This provison allows for the creation of a central 'palette manager' task which is not necessarily the same as the Local task.
R1+20 SubReason_ResizePaletteWindow (&83488)
R1+24 object tag
R1+28 handle of remote tasks status window
R1+32 desired change in palette window x0
R1+36 desired change in palette window y0
R1+40 desired change in palette window x1
R1+44 desired change in palette window y1
R1+20 SubReason_PaletteWindowMoving (&83489)
R1+24 object tag
R1+28 handle of palette window
R1+32 palette window x0
R1+36 palette window y0
R1+40 palette window x1
R1+44 palette window y1
R1+48 Reserved (0)
R1+20 SubReason_UndoInfo (&8348A)
R1+24 object tag
R1+28 Local task undo state
0 = can undo
-1 = Has undone, can redo
2 = cannot undo (perhaps a lack of memory?)
R1+20 0
"Image Filter. No image linked at the moment."
"Image Filter. Image 'Face' linked at the moment."
R1+20 0
R1+24 Address of object tag
R1+28 Y scale of object in Local window (65536=1:1 or 100%)
R1+32 Xlow of object on screen in 'Local' window. (limited to visible area)
R1+36 Ylow of object on screen in 'Local' window. (limited to visible area)
R1+40 Handle of 'Local' window.
R1+44 Handle of Local windows toolbar window (or -1 if no toolbar)
R1+48 X scale factor of object in Local window (16.16 format eg 65536=1:1 or 100%)
R1+52 Xlow of object on screen in Local window. (unlimited)
R1+56 Ylow of object on screen in Local window. (unlimited)
R1+20 0
R1+24 Address of object tag
R1+28 bits 0-27 Flags - reserved and set to zero.
bits 28-31 Window 'work area' button type to use for trap icon.
R1+32 Window handle
R1+36 String. indirection string for icon or Null (&0)
R1+20 0
R1+24 Address of object tag
R1+28 reserved - 0
R1+32 Window handle
R1+36 Unhook 'type'
R1+36 0 'Unhook' is temporary
(used by Compo to support the 'Track selected'
preference option)
R1+36 1 'Unhook' is permanent - forget about this PCA.
* A new applet has registered
* An applet has started
* An applet has quit
In all cases, the Local task should set a flag to regenerate its toolbar of PCA applets. (If the number of applets does not change as a result of this you can use Wimp_UpdateWindow to redraw the pca applet icons without flicker).
NB. This message is low priority, it is not gauranteed to be sent for *every* event. For example, if an obey file were to register three applets at once the message would only be sent once.