Thread View: comp.sys.acorn.tech
5 messages
5 total messages
Started by Simon Burrows
Fri, 31 Jul 1992 21:18
FilterManager SWIs
Author: Simon Burrows
Date: Fri, 31 Jul 1992 21:18
Date: Fri, 31 Jul 1992 21:18
9 lines
695 bytes
695 bytes
Hi Folks, Does a list of the filtermanager SWIs exist? It would be most useful. Simon. ----------------------------------------------------------------------------- + Simon Burrows smb@cs.nott.ac.uk Tel 0533 712030 + + University of Nottingham psyhsmb@unicorn.nott.ac.uk + -----------------------------------------------------------------------------
Re: FilterManager SWIs
Author: James
Date: Mon, 03 Aug 1992 07:52
Date: Mon, 03 Aug 1992 07:52
154 lines
4704 bytes
4704 bytes
In article <1992Jul31.211826.3088@cs.nott.ac.uk> smb@cs.nott.ac.uk (Simon Burrows) writes:
>Hi Folks,
>
>Does a list of the filtermanager SWIs exist? It would be most useful.
>
>Simon.
As luck would have it, I do have a list of the filter manager SWI's. Cut
and save from the dotted line.
--James
PS: I am not sure wether or not this is the right place to post this sort
of stuff, but I will anyway!
---------- 8< ---- cut here ------------------------------------
Filter Manager
--------------
Filter Manager service calls:
Service_FilterManagerInstalled (&87)
------------------------------
in R0 = Version number of Filter Manager *100, ie. 1.23 => 123
R1 = Service_FilterManagerInstalled
out all must be preserved, must never be claimed
This service call is broadcast to allow modules that install a Filter
to be reinstalled when the filter manager is reloaded / re-inited.
The SWI is issued on a callback, so the SWI interface is valid for
registering filters.
Service_FilterManagerDying (&88)
--------------------------
in R1 = Service_FilterManagerDying
out all must be preserved, must never be claimed
This is broadcast when the filter manager has unlinked all filters from
its active lists (just before the module dies) to allow the filter owners
to tidy any internal state.
Filter manager SWIs:
Filter_RegisterPreFilter (SWI &42640)
Add a new pre filter to the list of pre filters.
Entry:
R0 - Pointer to 0 terminated filter name.
R1 - Addresss of filter.
R2 - Value to be passed in R12.
R3 - Task handle of task to which filter is applied.
or 0 for all tasks.
Exit:
Registers preserved.
The address pointed to by R1 will be called whenever the task who's
handle is passed in R3 calls Wimp_Poll with R12 equal to the value of R2
when this SWI is called.
The routine pointed to by R1 will be called with:
R0 = Event mask as passed to Wimp_Poll
R1 -> Event block as passed to Wimp_Poll
R2 = Task handle of task that called Wimp_Poll.
On Exit:
It may clear bits in r0 to provide a new event mask.
It must preserve all other registers.
Filter_RegisterPostFilter (SWI &42641)
Add a new post filter to the list of post filters.
Entry:
R0 - Pointer to 0 terminated filter name.
R1 - Addresss of filter.
R2 - Value to be passed in R12.
R3 - Task handle of task to which filter is applied.
or 0 for all tasks.
R4 - Event mask ( 1 bit masks the event out as for Wimp_Poll).
Exit:
Registers preserved.
The address pointed to by R1 will be called whenever the Wimp is
about to return to the task who's handle is passed in R3 from Wimp_Poll with
R12 equal to the value of R2 when this SWI is called.
On entry to the routine pointed to by R1:
R0 - Event reason code (as from Wimp Poll)
R1 -> User's event buffer.
R2 = Task handle for task to which the return is made.
Task paged in.
On Exit:
The routine may modify the reason code in r0 and the contents of the
buffer pointed to by R1 to provide a new event.
It must preserve R1 and R2.
Filter_DeRegisterPreFilter (SWI &42642)
Remove a pre filter from the list of pre filters.
Entry:
R0 - Pointer to 0 terminated filter name.
R1 - Addresss of filter.
R2 - Value to be passed in R12.
R3 - Task handle of task to which filter was applied.
All must be the same as those passed to RegisterPreFilter
Exit:
Registers preserved.
Filter de-registered.
Filter_DeRegisterPostFilter (SWI &42642)
Remove a pre filter from the list of pre filters.
Entry:
R0 - Pointer to 0 terminated filter name.
R1 - Addresss of filter.
R2 - Value to be passed in R12.
R3 - Task handle of task to which filter was applied.
All must be the same as those passed to RegisterPreFilter
Exit:
Registers preserved.
Filter de-registered.
Re: FilterManager SWIs
Author: Ug!
Date: Mon, 03 Aug 1992 21:58
Date: Mon, 03 Aug 1992 21:58
8 lines
653 bytes
653 bytes
Simon Burrows writes: > Does a list of the filtermanager SWIs exist? It would be most useful. Excuse my ignorance - exactly what *is* the filtermanager? (if it's what I think it is, then it's used for emulating the mouse/keyboard using stuff like concept keyboards, touch screens, and so forth, yes?) Ug!
Re: FilterManager SWIs
Author: TMOTA
Date: Mon, 03 Aug 1992 22:28
Date: Mon, 03 Aug 1992 22:28
42 lines
2312 bytes
2312 bytes
jbye@acorn.co.uk (James) writes:
>As luck would have it, I do have a list of the filter manager SWI's. Cut
>and save from the dotted line.
Wow! I finally know what the FilterManager actually does! Thanks, James!
Okay, so the next (rather obvious) question is:
What do people (especially thems what reside @ acorn...) think the FM can
be used for?
We have come up with a couple of ideas... but what else can you/have you
thought of?
* Conversion of "new style" WIMP events/messages to "Old Style" ones so that
Acorn can in future OSes completely rearrange the event structures without
losing compatability with "old" programs.
* Trapping and logging of all events for an app. during development.
* Keyboard-equivalent converters (Make save-all ctrl-A instead of shift-f9
in edit, for example (not that you'd necessarily want to, but it gives you
the power to...))
* Allow key equivalents (like f12) while TASKWINDOWs are running! Yeah!!!
(Or is this fixed under RO3?)
* Specialised icons: e.g. "slider" icons - can these now be added by trapping
redraw, click, etc. events, and automatically handling the slider before
the application has a chance to notice the click... These clicks can then
be converted to messages to the application telling it the new slider
position...
Hmmm... I'm beginning to like the idea of a filter manager...
One hint to Acorn, here... The text in those SWI descriptions is rather
hard to understand... Perhaps using 2 or 3 sentences would help... Fullstops
don't use much laser-toner... ;-)
--
_________________ "I'd like to answer this question in two ways:
/____ _ _/_ __ First in my normal voice, and then
// / //_//_ /_/ in a silly, high-pitched whine." (Monty Python)
Re: FilterManager SWIs
Author: Andrew Brooks
Date: Tue, 04 Aug 1992 13:44
Date: Tue, 04 Aug 1992 13:44
32 lines
1897 bytes
1897 bytes
In article <1992Aug3.222826.25211@cs.aukuni.ac.nz> jwil1@cs.aukuni.ac.nz (TMOTA) writes: >Wow! I finally know what the FilterManager actually does! Thanks, James! > >Okay, so the next (rather obvious) question is: >What do people (especially thems what reside @ acorn...) think the FM can >be used for? > >We have come up with a couple of ideas... but what else can you/have you >thought of? > * Allow key equivalents (like f12) while TASKWINDOWs are running! Yeah!!! > (Or is this fixed under RO3?) So I could have ` and ' mapped to quote-left and quote-right when typed in Impression, and left as grave and quote-single in all other applications? That would be useful! Does anyone have any idea how this could be achieved in RISC-OS 2, even if it affects all applications? > * Specialised icons: e.g. "slider" icons - can these now be added by trapping > redraw, click, etc. events, and automatically handling the slider before > the application has a chance to notice the click... These clicks can then > be converted to messages to the application telling it the new slider > position... How about detecting drags on all writable icons that are normally non-draggable allowing their contents to be dragged to other icons / text windows etc. Squirrel is very good in this respect (especially when used with Impression), but it would be useful if it was transparent to the application. Andrew. -- arb@comp.lancs.ac.uk
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads