home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
The Datafile PD-CD 5
/
DATAFILE_PDCD5.iso
/
utilities
/
p
/
python
/
pyhtmldoc
/
r
/
risclib
< prev
next >
Wrap
Text File
|
1996-11-14
|
6KB
|
122 lines
<TITLE>RiscLib -- Python library reference</TITLE>
Prev: <A HREF="../d/drawf" TYPE="Prev">drawf</A>
Up: <A HREF="../r/riscos_only" TYPE="Up">RISCOS ONLY</A>
Top: <A HREF="../t/top" TYPE="Top">Top</A>
<H1>13.5. Built-in Module <CODE>RiscLib</CODE></H1>
@modindex{risclib}experimental
<P>
These modules provide an experimental interface to the RiscOS toolbox.
<P>
They provide a class <CODE>TBObject</CODE> that implements the common toolbox
methods, and derived classes <CODE>ColourDbox</CODE>, <CODE>IconBar</CODE>,
<CODE>Menu</CODE>, <CODE>Quit</CODE>, <CODE>SaveAs</CODE>, <CODE>Window</CODE>. They provide a
simple event polling system.
<P>
Neither the modules or the documentation are complete. I have added methods
and objects when I needed to use them. The methods provided just call the
toolbox SWIs, and can be inspected by examining the code.
<P>
The event polling system works as follows (using !Ibrowse as an example) :
<P>
The controlling program imports <CODE>tbevent</CODE>.
<CODE>tbevent</CODE> imports three dictionaries from a module <CODE>events</CODE> that
include details of the toolbox events, wimp events and wimp messages that the
application is interested in. The dictionaries are called <CODE>edict</CODE>,
<CODE>wdict</CODE> and <CODE>mdict</CODE>. They contain event or message numbers as
keys and names as values. See @verb{!ibrowse.py.events} for an example.
<P>
The program must supply classes with methods to handle these events. The
methods will have the same names as the dictionary values.
<P>
The program calls
@verb{tbevent.initialise("<ibrowse$Dir>")} supplying an application
directory incuding a Resource file ``res'' and a ``Messages'' file.
<P>
The program registers instances of the handler classes with tbevent (see below).
<P>
The program then calls <CODE>tbevent.poll()</CODE> repeatedly.
<P>
Toolbox event handling works as follows:
<P>
The ancestor object number of the event is used to find a class instance to
handle the event. It is looked up in a dictionary <CODE>tbevent.tbclasses</CODE> to
find the handler, so each class that handles toolbox methods should have a
<CODE>__init__</CODE> method that registers itself in this dictionary.
<P>
Here is an example from ``!Graph''
<P>
<UL COMPACT><CODE>class Display(window.Window):<P>
actions={} #1<P>
def __init__(self):<P>
window.Window.__init__(self,"Display") #2<P>
tbevent.tbclasses[self.id]=self #3<P>
self.handle=self.getwimphandle() #4<P>
tbevent.winclasses[self.handle]=self #5<P>
</CODE></UL>
In line @verb{#2} the underlying window class is initialised. This creates
a toolbox object from a template named ''Display''
(This must be a window object. It should be an ancestor object, but not
autocreated).
<CODE>self.id</CODE> is set to the object identifier.
Line @verb{#3} now registers the class instance as a toolbox event handler.
<P>
If an event now arrives for an object with this ancestor its event number is
looked up in <CODE>edict</CODE>. The corresponding name should be the name of a
method in class <CODE>Display</CODE>. It will be called for this class instance.
<P>
The class method names are cached in a dictionary called <CODE>actions</CODE>, so
each handler class should contain an empty dictionary as in line @verb{#1}.
<P>
Some toolbox events will have no ancestor. These will be sent to a class
instance registered with a zero identifier. Most programs will have code
such as this, which will handle an autocreated bar icon object.
<P>
<UL COMPACT><CODE>class Orphans: #class to handle events with zero ancestor<P>
actions={}<P>
def __init__(self):<P>
tbevent.tbclasses[0]=self<P>
def BarClick(self):<P>
a=Display("dir","Top")<P>
def E_Q_Quit(self):<P>
exit()<P>
<P>
oi=Orphans() #create an instance of the class (the only one!)<P>
<P>
</CODE></UL>
Wimp event handling is similar. Wimp codes other than 7, 9, 13, 17 and 18
are sent to class instances registered by their wimp window handles.
Codes 7, 9 and 13 are given handles of zero. The classes are registered in
the dictionary <CODE>tbevent.winclasses</CODE>. Lines @verb{#4} and @verb{#5} in
the example above give an example of registration. The names of the actions
are obtained from dictionary <CODE>wdict</CODE>. Codes not in this dictionary are
ignored. Note that wimp and toolbox codes use the same <CODE>actions</CODE>
dictionary. This means they must have <I>different event numbers</I>. In
practice this means not giving low numbers to user defined toolbox events.
Starting user defined nubers at <CODE>0x1000</CODE> is a safe rule.
<P>
Messages are handled by a single class instance <CODE>tbevent.msghandler</CODE>
method names are looked up from the message number in dictionary <CODE>mdict</CODE>.
<P>
For example here is a trivial message handling class that just handles the
quit message.
<P>
<UL COMPACT><CODE>class Messenger: #This is the message handler class<P>
def Wimp_MQuit(self):<P>
exit()<P>
<P>
tbevent.msghandler=Messenger() #Register the instance <P>
</CODE></UL>
Toolbox event methods can examine the toolbox id block as <VAR>toolbox.idblock</VAR>.
All methods can use the wimp poll block as <VAR>tbevent.wblock</VAR>.
<P>
There is a simple system to assist with debugging built in to <CODE>tbevent</CODE>.
The function <CODE>tbevent.report(string,[priority])</CODE> broadcasts a wimp
message containing the string (truncated to 200 characters). The application
``!Reporter'' can display these messages. Messages are only sent if
<CODE>priority<=tbevent.usereport</CODE>, so debugging messages can be suppressed
by setting this variable. <CODE>priority</CODE> defaults to 16.
<CODE>tbevent.usereport</CODE> is initially 8. <CODE>tbevent</CODE> generates some
reports itself, error reports with priority 2, and reports of all events
with priority 32.
<P>