FilerAction now includes a flag on its options to force it to never invoke proxy tasks. This flag should be used by proxy clients who wish to start FilerAction tasks to perform tasks on their behalf.
This facility is required by 'delete trapping' proxies (for example, a rubbish bin) which wish to use FilerAction to perform deletions on the objects within the bin itself.
A full list of the options as supplied in +24 of the message block is as follows :
Proxying FilerAction messages
FilerAction under RISC OS Select now provides the ability to 'proxy' requests for other users. This can be used to replace the functionality of the standard FilerAction utility with another, user supplied, application. The major use of this is to provide a means for user provision of an updated 'Find' utility. However, this functionality might also be used to provide an automatic waste-basket facility, or a more graphical count utility.
In this mode, FilerAction becomes a 'proxy' for the extended tools. Known messages sent to the FilerAction task will be passed to their opposite (usually this means that messages from the Filer go to FilerAction as a proxy, and from there on to the extended tool). The reason that this - somewhat indirect - method is used, is to provide support for older applications. Applications unaware of the existance of the new tools will be able to benefit from the new operation of FilerAction, and the method of launching such tools remains backwards compatible for all clients.
To provide a tool that replaces the functionality of FilerAction you must first set a system variable to inform it of the existence of that tool. Generally, this will take the form :
*Set Alias$@FilerAction_<operation> /<Obey$Dir>.!Run
Operation is one of :
Find an object with a given name.
These mirror the operations that FilerAction currently provides. Additional operations will be given similarly descriptive names.
The extended tool will be launched using this command, and you should be prepared to either support multiple invocations by starting new applications, or by receiving multiple requests and servicing them.
Before issuing the command, FilerAction will broadcast a Message_FilerAction (&405). Tools which are able to service the request should reply to this message. Any tool unable to service the request (because it does not handle that form of request, or because it is busy with another request) should ignore the message. If the message is replied to, FilerAction will treat that task as a client. If it bounces, FilerAction will issue the above command to start the tool.
Once started, messages will be sent to the extended tool in exactly the same manner as FilerAction receives them. This means that a Message_FilerSelectedDirectory will arrive first, followed by multiple Message_FilerAddSelection, and then finally a Message_FilerAction. The recommended way of implementing this protocol is as follows :
parent_Task=-1 state=Idle WHILE running receive message CASE message OF WHEN Message_FilerAction: CASE state OF WHEN Idle: IF messageblock.operationtype = one_we_understand THEN state=Starting parent_Task=messageblock.taskhandle SYS "Wimp_SendMessage",17,messageblock,parent_Task ELSE ignore it ENDIF WHEN Starting: state=Processing do whatever stuff we need to ENDCASE WHEN Message_FilerSelectionDirectory: IF state = Starting THEN remember the directory WHEN Message_FilerAddSelection: IF state = Starting THEN process the names WHEN Message_FilerControlAction: IF state = Processing THEN act upon control command; code 0 will always be handled for you, because FilerAction knows what you can do ENDIF ENDCASE IF finished_processing THEN state=Idle either: quit normally or: send message_TaskShutdown (&400C3) to parent_Task ENDIF ENDWHILE
Implementing the protocol defined in the PRMs for FilerAction clients is sufficient to get an initial implementation running. Adding the simple state machine on top of this will protect against multiple tool invocations getting confused.
You will need to handle PreQuit requests as you would in a normal application, as FilerAction cannot do this for you.
Possible extended tools
There is only limited scope for extended tools, but of some of the things that might be implemented are :
This documentation is copyright 3QD Developments Ltd 2013 and may not be reproduced or published in any form without the copyright holders permission. RISC OS is subject to continuous development and improvement as such all information is reproduced by 3QD Developments Ltd in good faith and is believed to be correct at the time of publication E&OE. 3QD Developments Ltd cannot accept any liability for any loss or damage arising from the use of any information provided as part of the RISC OS Documentation.
HTML document version 1.03 3rd November 2015