🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: comp.sys.acorn.tech
5 messages
5 total messages Started by Simon Burrows Fri, 31 Jul 1992 21:18
FilterManager SWIs
#92
Author: Simon Burrows
Date: Fri, 31 Jul 1992 21:18
9 lines
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
#99
Author: James
Date: Mon, 03 Aug 1992 07:52
154 lines
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
#104
Author: Ug!
Date: Mon, 03 Aug 1992 21:58
8 lines
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
#106
Author: TMOTA
Date: Mon, 03 Aug 1992 22:28
42 lines
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
#107
Author: Andrew Brooks
Date: Tue, 04 Aug 1992 13:44
32 lines
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