Toolbox tutorial
Robert Richards
Does anyone know of any Toolbox tutorials anywhere either on the web or in
print? I have found a single article by Tony Houghton, but haven't been
able to find the accompanying source code which kinda makes it a bit
difficult to follow :-)
I've got as far as initialising the toolbox, loading and iconbar icon and
menu, an info box and a quit menu entry. I culled most of the supporting
code from the few example files provided with Acorn C. Consequently, I
don't *really* understand what's going on.
I do have the Stronghelp manuals, but they don't seem to contain much
more (basic) information than the printed manual.
If anyone knows of anything that explains things in an easy to read
fashion suitable for a beginner I'd be much obliged. Or if anyone fancies
doing a bit of tutoring...
Right that's enough for now. Long query snipped because I was rambling and
I need to think about what I'm actually trying to ask.
TIA,
Robert
Richard Walker
Robert Richards <epy...@unix.ccc.nottingham.ac.uk> wrote:
> Does anyone know of any Toolbox tutorials anywhere either on the web or in
> print? I have found a single article by Tony Houghton, but haven't been
> able to find the accompanying source code which kinda makes it a bit
> difficult to follow :-)
I've noticed this. Information is sparse. :-(
> I've got as far as initialising the toolbox, loading and iconbar icon and
> menu, an info box and a quit menu entry. I culled most of the supporting
> code from the few example files provided with Acorn C. Consequently, I
> don't *really* understand what's going on.
Me neither.
I've looked at the Acorn C examples, and the single example supplied with
OSLib. I've also been reading the Acorn Toolbox manual (on the manuals CD
ROM).
> If anyone knows of anything that explains things in an easy to read
> fashion suitable for a beginner I'd be much obliged. Or if anyone fancies
> doing a bit of tutoring...
Me too. Let's discuss things here.
I think your first decision should be to decide if you are going to use
Acorn's libraries (EventLib, TboxLib etc.) as supplied with C/C++, or OSLib.
I get the impression that OSLib is slightly more friendly, and that's what
I'm currently playing with.
I have a minimal application (using OSLib) up and running, and have managed
to assign some events to buttons etc., but they don't do what I want! :-(
If I can't solve this, I'll be making another posting! :-)
> Right that's enough for now. Long query snipped because I was rambling and
> I need to think about what I'm actually trying to ask.
:-)
--
Richard.
"Don't pass me by don't make me cry don't make me blue."
Tony Houghton
Robert Richards <epy...@unix.ccc.nottingham.ac.uk> wrote:
> Hi,
>
> Does anyone know of any Toolbox tutorials anywhere either on the web or in
> print? I have found a single article by Tony Houghton, but haven't been
> able to find the accompanying source code which kinda makes it a bit
> difficult to follow :-)
I can't remember writing a web article, but I did a series for Archive
about the development of FormText.
--
TH * http://www.realh.co.uk
Paul F. Johnson
In message <Pine.GSO.4.21.011201...@granby.ccc.
nottingham.ac.uk>
Robert Richards <epy...@unix.ccc.nottingham.ac.uk> wrote:
> Hi,
>
> Does anyone know of any Toolbox tutorials anywhere either on the web or
> in print? I have found a single article by Tony Houghton, but haven't
> been able to find the accompanying source code which kinda makes it a bit
> difficult to follow :-)
Are you sure that's not Tony Howat? If it is, then the Nutshell CD from
RComp is your friend.
TTFN
Paul
--
Sent from the heart of British Technology at its best - the all
new RiscStation R7500 - now running with the new 50ns upgrade
All opinions expressed are solely mine and do not represent any
other persons or companies.
nico ter haar
Paul F. Johnson <paulf....@ukonline.co.uk> wrote:
> Hiya,
>
> In message <Pine.GSO.4.21.011201...@granby.ccc.
> nottingham.ac.uk>
> Robert Richards <epy...@unix.ccc.nottingham.ac.uk> wrote:
>
> > Hi,
> >
> > Does anyone know of any Toolbox tutorials anywhere either on the web or
> > in print? I have found a single article by Tony Houghton, but haven't
> > been able to find the accompanying source code which kinda makes it a bit
> > difficult to follow :-)
>
> Are you sure that's not Tony Howat? If it is, then the Nutshell CD from
> RComp is your friend.
>
Sure, he means the other Tony.
He did TplusLib for RiscUser as now sold on the NutshellCD. I have
found this to be a very helpfull way of learning to work with the
toolbox.
Especially as on the later releases it also contained the sourcecode to
the Tplus library to play with, don't know if that's on the CD.
rgds
nico
--
Richard Walker
> In message <Pine.GSO.4.21.011201...@granby.ccc.
> nottingham.ac.uk>
> Robert Richards <epy...@unix.ccc.nottingham.ac.uk> wrote:
>
> > Does anyone know of any Toolbox tutorials anywhere either on the web or
> > in print? I have found a single article by Tony Houghton, but haven't
> > been able to find the accompanying source code which kinda makes it a
> > bit difficult to follow :-)
>
> Are you sure that's not Tony Howat? If it is, then the Nutshell CD from
> RComp is your friend.
Yes, apparently there are a number of Toolbox articles in Risc User.
Perhaps the CD is a good purchase.
Tony Houghton's article is available in the 'tester' area of the Archive web
site. I suspect the relevant Archive magazines and discs could be of help,
as it's no doubt part of a series.
--
Richard.
"C'mon... Please please me, whoa yeah, like I please you."
Robert Richards
> In message <Pine.GSO.4.21.011201...@granby.ccc.nottingham.ac.uk>
> Robert Richards <epy...@unix.ccc.nottingham.ac.uk> wrote:
>
> > I've got as far as initialising the toolbox, loading and iconbar icon and
> > menu, an info box and a quit menu entry. I culled most of the supporting
> > code from the few example files provided with Acorn C. Consequently, I
> > don't *really* understand what's going on.
>
> Me neither.
>
> I've looked at the Acorn C examples, and the single example supplied with
> OSLib. I've also been reading the Acorn Toolbox manual (on the manuals CD
> ROM).
>
> > If anyone knows of anything that explains things in an easy to read
> > fashion suitable for a beginner I'd be much obliged. Or if anyone fancies
> > doing a bit of tutoring...
>
> Me too. Let's discuss things here.
>
> I think your first decision should be to decide if you are going to use
> Acorn's libraries (EventLib, TboxLib etc.) as supplied with C/C++, or OSLib.
> I get the impression that OSLib is slightly more friendly, and that's what
> I'm currently playing with.
I don't think the Acorn libraries will be all that bad once I understand
them. However, if we're both learners then perhaps it would make sense if
I tried OSLib and we could swap notes?
>
> I have a minimal application (using OSLib) up and running, and have managed
> to assign some events to buttons etc., but they don't do what I want! :-(
> If I can't solve this, I'll be making another posting! :-)
>
I've got as far as having various windows open and close by clicking on
buttons, and quitting the application by clicking on buttons. Trying to
work out how to use writable icons - they work fine in !ResTest, but
something funny is going on when the actual compiled program runs; nothing
appears in them when I type.
Perhaps we should take this to email - it all seems a bit elementary for
csa.p :-)
Cheers,
Robert
Richard Walker
Robert Richards <epy...@unix.ccc.nottingham.ac.uk> wrote:
> On Sat, 1 Dec 2001, Richard Walker wrote:
>
> > I think your first decision should be to decide if you are going to use
> > Acorn's libraries (EventLib, TboxLib etc.) as supplied with C/C++, or
> > OSLib. I get the impression that OSLib is slightly more friendly, and
> > that's what I'm currently playing with.
>
> I don't think the Acorn libraries will be all that bad once I understand
> them. However, if we're both learners then perhaps it would make sense if
> I tried OSLib and we could swap notes?
Could do. That is, if you are happy to install OSLib and get the example
Toolbox application built. I had to hack the Makefile about!
> > I have a minimal application (using OSLib) up and running, and have
> > managed to assign some events to buttons etc., but they don't do what I
> > want! :-( If I can't solve this, I'll be making another posting! :-)
>
> I've got as far as having various windows open and close by clicking on
> buttons, and quitting the application by clicking on buttons. Trying to
> work out how to use writable icons - they work fine in !ResTest, but
> something funny is going on when the actual compiled program runs; nothing
> appears in them when I type.
I had that problem. Now... what was the solution?... erm... I think it was
a flag in ResEd that I hadn't set. Heck... I can't remember! :-(
I'm currently unable to set values in display fields or sliders. That's
highly annoying. I've followed the advice in the OSLib example and the
Toolbox manual, and even looked for help in this very group (using Google's
archives). :-(
> Perhaps we should take this to email - it all seems a bit elementary for
> csa.p :-)
Maybe, but there isn't much traffic here at the moment. I say let the
experts suffer! :-)
--
Richard.
"Free As A Bird. It's the next best thing to be, free as a bird."
Paul F. Johnson
"Richard Walker" <runny...@mindless.com> wrote in message
news:4f91c5e24...@riscpc.ntlworld.com...
> I'm currently unable to set values in display fields or sliders. That's
> highly annoying. I've followed the advice in the OSLib example and the
> Toolbox manual, and even looked for help in this very group (using
Google's
> archives). :-(
Dunno about in OSLib, but using Acorn's libs
er = slider_set_value(unsigned int flags,ObjectId,ComponentId,int value);
E(er);
works for setting the slider (you may need a redraw as well)
er = displayfield_set_value(unsigned int flags, ObjectId,ComponentId,char
*str);
E(er);
works for displayfields.
(E(er) is my standard test for null macro, er is _kernel_oserror *er;)
ObjectId is the window (okay, it's the object, but can be thought of as the
window) and ComponentId is the gadget. flags are the generic bit 30 and 31
(IIRC) flags.
The OS_Lib version is pretty much the same (from memory).
example....
slider = 0x101;
objid = Window (set up during creation routine)
value = 10
er = slider_set_value(0,Window,0x101,10);
E(er);
Simple.
TTFN
Paul
Richard Walker
"Paul F. Johnson" <p.f.j...@salford.ac.uk> wrote:
> "Richard Walker" <runny...@mindless.com> wrote in message
> news:4f91c5e24...@riscpc.ntlworld.com...
>
> > I'm currently unable to set values in display fields or sliders. That's
> > highly annoying. I've followed the advice in the OSLib example and the
> > Toolbox manual, and even looked for help in this very group (using
> > Google's archives). :-(
>
> Dunno about in OSLib, but using Acorn's libs
>
> er = slider_set_value(unsigned int flags,ObjectId,ComponentId,int value);
> E(er);
>
> works for setting the slider (you may need a redraw as well)
>
> er = displayfield_set_value(unsigned int flags, ObjectId,ComponentId,char
> *str);
> E(er);
>
> works for displayfields.
I'll just concentrate on display fields at the moment, since they shoud be
simple. I've got code like this:
event_register_toolbox_handler(event_ANY, EVENT_MAINW_STOP,
event_mainw_stop, NULL);
...
static bool event_mainw_stop(uint uiEventCode,ToolboxEvent *pxEvent,
IdBlock *IdBlock,void *vHandle) {
displayfield_set_value(0,main_window,C_MAINW_INFO,"Stop clicked");
os_bell();
return (TRUE);
}
...where C_MANW_INFO is the gadget number of a display field. It's length
has been set to 256 with ResEd, and it's blank.
When you click this 'stop' button (a button in the same window with the
event code EVENT_MAINW_STOP) the os_bell() executes OK (you can hear the
computer beep!) but the display field remains blank.
I can't see anything wrong with the above.
I've tried using the x-version of the displayfield_set_value function and
examining the error block, but there is no error.
--
Richard.
"Oh, I believe in yesterday."
Paul F. Johnson
> I've tried using the x-version of the displayfield_set_value function and
> examining the error block, but there is no error.
Two things - one, you should be checking the return values for all of your
posted code, they return really useful stuff. Second, you more than likely
need a redraw over the gadget.
Just off the top of my head.....
TTFN
Paul
Richard Walker
"Paul F. Johnson" <p.f.j...@salford.ac.uk> wrote:
> > I've tried using the x-version of the displayfield_set_value function
> > and examining the error block, but there is no error.
>
> Two things - one, you should be checking the return values for all of your
> posted code, they return really useful stuff.
Yes, I know, but this is only a small demo application, just so I can get a
'feel' for the Toolbox and OSLib. (excuses, excuses...)
> Second, you more than likely need a redraw over the gadget.
Hmm... The Acorn/OSLib examples don't mention this. I'll have a delve into
the Toolbox manual (which is a right pain in the bum - these HTML manuals
are *awful*).
--
Richard.
"Hey Jude, don't make it bad. Take a sad song and make it better."
nico ter haar
Richard Walker <runny...@mindless.com> wrote:
> I'll just concentrate on display fields at the moment, since they shoud be
> simple. I've got code like this:
>
> event_register_toolbox_handler(event_ANY, EVENT_MAINW_STOP,
> event_mainw_stop, NULL);
>
> ...
>
> static bool event_mainw_stop(uint uiEventCode,ToolboxEvent *pxEvent,
> IdBlock *IdBlock,void *vHandle) {
>
> displayfield_set_value(0,main_window,C_MAINW_INFO,"Stop clicked");
> os_bell();
>
> return (TRUE);
> }
>
> ..where C_MANW_INFO is the gadget number of a display field. It's length
> has been set to 256 with ResEd, and it's blank.
>
> When you click this 'stop' button (a button in the same window with the
> event code EVENT_MAINW_STOP) the os_bell() executes OK (you can hear the
> computer beep!) but the display field remains blank.
>
> I can't see anything wrong with the above.
>
You haven't got the right windowID !
You have to set the object to be 'shared', inside the resource window
click MENU over the window and set the shared flag.
rgds
nico
--
Paul F. Johnson
In message <2f7238e34...@riscpc.ntlworld.com>
Richard Walker <runny...@mindless.com> wrote:
> > Second, you more than likely need a redraw over the gadget.
>
> Hmm... The Acorn/OSLib examples don't mention this. I'll have a delve
> into the Toolbox manual (which is a right pain in the bum - these HTML
> manuals are *awful*).
Why should they? The manuals tell you how to operate them, not how they
work.
If you have a bog standard icon with some text in it and change the text,
what do you get - a mess on the icon until you do a redraw.
Looking back on the code though, it seems you don't have the correct
ObjectId plus the event_register_toolbox_handler doesn't seem right.
According to the manual
_kernel_oserror *event_register_toolbox_handler (
ObjectId object_id,
int event_code,
ToolboxEventHandler *hand,
void *handle
);
whereas the code you've posted doesn't indicate this at all.
I'm not sure why you're using an unsigned int for the EventCode when it's
an int.
These may help.....
Geoff Youngs
[snip]
> static bool event_mainw_stop(uint uiEventCode,ToolboxEvent *pxEvent,
> IdBlock *IdBlock,void *vHandle) {
> displayfield_set_value(0,main_window,C_MAINW_INFO,"Stop clicked");
Try:
displayfield_set_value(0, IdBlock->self_id, C_MAINW_INFO, "Stop clicked");
If you are creating a window in ResEd which is auto-created by the Toolbox,
but main_window is the handle returned by toolbox_create_object() then you
will probably(*) be dealing with two different windows, clicking in the open
one and then updating the displafield in the closed one.
As has been wrongly suggested elsewhere in this thread, you do *not* need to
mess around with redrawing the gadget - the Toolbox/Wimp handle that.
Refering to the original topic, you would probably do well to look at the
source code of software to see how things are done. Socketeer springs to
mind (http://www.fruit.ukgateway.net/), as it is GPL (ie source is available)
and it uses the Toolbox.
I personally I think that code for the Acorn libraries look nicer (I'm
thinking of constants, e.g. toolbox_POSITION_AT_POINTER vs
Toolbox_ShowObject_AtPointer), but if you are starting out it will probably
be more hassle free using the OSLib veneers, mainly because it'll save
headaches when using OSLib elsewhere in the program.
(*) Unless the shared bit is set in the object flags
--
Geoff Youngs, Technical Director
// solutions.web - Internet Consultants
\\ Tel. +44 (0) 23 9241 2340
// Web : http://www.solutionsweb.co.uk/
Robert Richards
> Robert Richards <epy...@unix.ccc.nottingham.ac.uk> wrote:
>
> > I don't think the Acorn libraries will be all that bad once I understand
> > them. However, if we're both learners then perhaps it would make sense if
> > I tried OSLib and we could swap notes?
>
> Could do. That is, if you are happy to install OSLib and get the example
> Toolbox application built. I had to hack the Makefile about!
Ah well, practice makes perfect :-)
>
> > > I have a minimal application (using OSLib) up and running, and have
> > > managed to assign some events to buttons etc., but they don't do what I
> > > want! :-( If I can't solve this, I'll be making another posting! :-)
> >
> > I've got as far as having various windows open and close by clicking on
> > buttons, and quitting the application by clicking on buttons. Trying to
> > work out how to use writable icons - they work fine in !ResTest, but
> > something funny is going on when the actual compiled program runs; nothing
> > appears in them when I type.
>
> I had that problem. Now... what was the solution?... erm... I think it was
> a flag in ResEd that I hadn't set. Heck... I can't remember! :-(
>
Yes, the input mask buffer size (or words to that effect). What's
strange is that it works fine in !ResTest, but when the window is
opened by the program it doesn't work anymore. I'll have to have
another go, maybe start again as I was trying all sort of strange
things to get it working.
> I'm currently unable to set values in display fields or sliders. That's
> highly annoying. I've followed the advice in the OSLib example and the
> Toolbox manual, and even looked for help in this very group (using Google's
> archives). :-(
>
Well my task for tonight is to dig out the Nutshell CD and search see
if the Toolbox articles it contains shed any more light on the
situation. I'll report back OK.
> > Perhaps we should take this to email - it all seems a bit elementary for
> > csa.p :-)
>
> Maybe, but there isn't much traffic here at the moment. I say let the
> experts suffer! :-)
Agreed ;-)
I should really be writing all this down in some kind of diary. Might
be useful for others if I stuck it on my website. There seems to be
quite a bit of support for novice WIMP programmers, but a lot less for
absolute beginners.
TTFN!!
Robert
Geoff Youngs
Paul F. Johnson <paulf....@ukonline.co.uk> wrote:
> Hiya,
> In message <2f7238e34...@riscpc.ntlworld.com>
> Richard Walker <runny...@mindless.com> wrote:
> > > Second, you more than likely need a redraw over the gadget.
> > Hmm... The Acorn/OSLib examples don't mention this. I'll have a delve
> > into the Toolbox manual (which is a right pain in the bum - these HTML
> > manuals are *awful*).
> Why should they? The manuals tell you how to operate them, not how they
> work.
Page 355 of the manual entitled 'User Interface Toolbox', which accompanies
Acorn C/C++ V5, states (with regard to the use of displayfield_set_value()):
The method sets the text string shown in a display field. The
change is immediately visible if the parent dialogue box is
currently on the screen.
> If you have a bog standard icon with some text in it and change the text,
> what do you get - a mess on the icon until you do a redraw.
Could you possibly elucidate this for me?
Does the sentence 'The change is immediately visible if the parent dialogue
box is currently on the screen.' really mean 'The change becomes visible
after you've manually redrawn the dialogue box in question.'?
It's funny, because I thought that this means that even if you're not
multitasking and you call this, it will update the screen.
Consider the following:
#include <stdio.h>
#include "wimplib.h"
#include "gadgets.h"
#include "swis.h"
static int escape_pressed(void) {
int i;
_swi(OS_Byte, _INR(0,2)|_OUT(1), 129, 112 ^ 255, 255, &i);
return i;
}
int main() {
WimpPollBlock poll_block;
IdBlock id_block;
MessagesFD mbl;
ObjectId id=0;
int e_code=0, time=0, otime=0;
char buf[12]="";
toolbox_initialise(0, 310, 0, 0, "<Test$Dir>", &mbl, &id_block,0,0,0);
toolbox_create_object(0,"Win",&id);
toolbox_show_object(0, id, 3, 0, 0, 0);
wimp_pollidle(0, &poll_block, 0, 0, &e_code);
while (!escape_pressed()) {
_swi(OS_ReadMonotonicTime,_OUT(0),&time);
time=time/100;
if (time>oldtime) {
sprintf(buf,"%i",time);
displayfield_set_value(0,id,0,buf);
oldtime=time;
}
}
}
It doesn't even poll, but it still updates the text in the displayfield
every second. Could you possibly point me to the code which stops me from
getting the 'mess on the icon'?
> Looking back on the code though, it seems you don't have the correct
> ObjectId plus the event_register_toolbox_handler doesn't seem right.
^^^^^^^^
This is the most likely cause, given the evidence currently available.
> According to the manual
> _kernel_oserror *event_register_toolbox_handler (
> ObjectId object_id,
> int event_code,
> ToolboxEventHandler *hand,
> void *handle
> );
> whereas the code you've posted doesn't indicate this at all.
At all?
object_id = event_ANY
Defined as ((toolbox_o) -1), he should technically be using toolbox_ALL,
but both end up with the same value; no problem here.
event_code = EVENT_MAINW_STOP
User defined event - assuming that it doesn't clash with the Toolbox
reserved range there will be no problem here.
hand = event_mainw_stop
Function to handle event - no problem here.
handle = NULL
Null value for user defined value to pass to handler function: no
problem here.
If, on the other hand, you were referring to the event handler definition,
assuming that he is including the relevant headers for OSLib,
typedef bool event_toolbox_handler (bits event_code,
toolbox_action *action, toolbox_block *id_block,
void *handle);
bits == unsigned int
toolbox_action == ToolBoxEvent
toolbox_block == IdBlock
So no problem there.
It seems that OSLib disagrees with the Acorn libs as to whether event codes
should be signed or not, but as Richard is using OSLib, he can hardly be
blamed for following its version of events :)
> I'm not sure why you're using an unsigned int for the EventCode when it's
> an int.
Check the OSLib headers. It won't make any difference in the example because
it's not even being used.
> These may help.....
... or may not as the case may be.
HTH,
Richard Walker
nico ter haar <ni...@neptune.demon.nl> wrote:
> In message <07aa30e34...@riscpc.ntlworld.com>
> Richard Walker <runny...@mindless.com> wrote:
>
[ snip ]
> > When you click this 'stop' button (a button in the same window with the
> > event code EVENT_MAINW_STOP) the os_bell() executes OK (you can hear the
> > computer beep!) but the display field remains blank.
> >
> > I can't see anything wrong with the above.
>
> You haven't got the right windowID !
> You have to set the object to be 'shared', inside the resource window
> click MENU over the window and set the shared flag.
AARRGGHH!!! fsck!!! How on earth did I miss that?!
Thank you kind sir - you are a genious!
I love the Toolbox again! :-)
Richard Walker
Geoff Youngs <ge...@solutionsweb.co.uk> wrote:
[ big snip ]
> It seems that OSLib disagrees with the Acorn libs as to whether event
> codes should be signed or not, but as Richard is using OSLib, he can
> hardly be blamed for following its version of events :)
Phew! :-) I am indeed using OSLib, as I think (hope!) I said.
Thanks for the dialogue everyone. Anything is helpful, even if they might
be stabs in the dark. It all helps get my mind working in the right mode!
--
Richard.
"Tell me why you cried, and why you lied to me."
Richard Walker
Geoff Youngs <ge...@solutionsweb.co.uk> wrote:
> Try:
> displayfield_set_value(0, IdBlock->self_id, C_MAINW_INFO, "Stop clicked");
>
> If you are creating a window in ResEd which is auto-created by the
> Toolbox, but main_window is the handle returned by toolbox_create_object()
> then you will probably(*) be dealing with two different windows, clicking
> in the open one and then updating the displafield in the closed one.
Ah... so that's the alternative to the 'shared' bit. I see! Thankyou.
> Refering to the original topic, you would probably do well to look at the
> source code of software to see how things are done. Socketeer springs to
> mind (http://www.fruit.ukgateway.net/), as it is GPL (ie source is
> available) and it uses the Toolbox.
Great. I've been looking for example programs, and getting nowhere. Of
course, I should have remembered good ol' Socketeer!
--
Richard.
"It was twenty years ago today. Sargeant Pepper taught the band to play."
Richard Walker
epy...@nottingham.ac.uk (Robert Richards) wrote:
> Richard Walker <runny...@mindless.com> wrote in message news:<4f91c5e24...@riscpc.ntlworld.com>...
>
> Well my task for tonight is to dig out the Nutshell CD and search see if
> the Toolbox articles it contains shed any more light on the situation.
> I'll report back OK.
Cool.
If I can polish up my own little Toolbox test application, then you are
welcome to have a look at it. But please don't laugh! ;-)
> I should really be writing all this down in some kind of diary. Might be
> useful for others if I stuck it on my website. There seems to be quite a
> bit of support for novice WIMP programmers, but a lot less for absolute
> beginners.
Maybe. I think there is a definate gap in the documentation/tutorial area
here. Just pop over to, say, developer.kde.org (or ask Google about Java)
and you'll get *zillions* of helpful tutorials etc.
--
Richard.
"I need a fix 'cause I'm going down. Down to the bits that I left uptown."
Colin Granville
There isn't anything wrong if:
1) main_window is the ObjectId of the window containing the
display field
2) C_MAINW_INFO is the ComponentId of the display field
3) EVENT_MAINW_STOP is the event generated by the stop button
4) You dont have another event handler for EVENT_MAINW_STOP -
registered after event_mainw_stop - which also claims the
event and does an os_bell(). In this case it wouldn't be
event_mainw_stop that was causing the bell.
Note: The display field does not require redrawing when it is
changed - the toolbox does it for you.
--
Colin
Colin Granville
>In message <091c4de3...@solutionsweb.co.uk>
> Geoff Youngs <ge...@solutionsweb.co.uk> wrote:
>
>> Try:
>> displayfield_set_value(0, IdBlock->self_id, C_MAINW_INFO, "Stop clicked");
>>
>> If you are creating a window in ResEd which is auto-created by the
>> Toolbox, but main_window is the handle returned by toolbox_create_object()
>> then you will probably(*) be dealing with two different windows, clicking
>> in the open one and then updating the displafield in the closed one.
>
>Ah... so that's the alternative to the 'shared' bit. I see! Thankyou.
As far as shared/ancestor/autocreate are concerned this is my
strategy for using them:
* I never use autocreate as you do you have to jump through hoops
to read the objects ObjectId much easier to use
toolbox_create_object().
* I make the main window unshared and an ancestor object.
* I make the menu tree and all objects hanging off it shared.
So you if you are doing an editor for example you could have
typedef struct Editor
{
ObjectId mainWindow;
ObjectId mainMenu;
ObjectId subMenu;
....
};
void Editor_construct(Editor*)
{
/*create objects, set up handlers and show main*/
}
void Editor_destroy(Editor*)
{
/*don't forget to destroy objects/handlers
when finished with them */
}
Editor editor1
Editor_construct(&editor1);
Editor editor2;
Editor_construct(&editor1);
Each ObjectId is created with toolbox_create_object(). If you create
2 Editors the mainWindow in each will have a unique ID because it
is not shared, the other ObjectIds will be the same in both
versions of Editor because they are shared.
Note the menu IDs are only required if you want to modify the menu
(eg tick an item - which you would do on an about_to_be_shown
event)
To handle the events that you have on menus do something like the
following for each event.
event_register_toolbox_handler(event_ANY, A_MENU_EVENT,
a_menu_event_handler,&editor1);
Note you don't register the handler with the menu object. This gives
you the ability to move menu items around the menu tree (eg move it
to a submenu or even trigger the event with a keypress) without
modifying any code.
static bool event_mainw_stop(uint uiEventCode,ToolboxEvent
*pxEvent,IdBlock *idBlock,void *vHandle)
{
Editor* self = (Editor*)vHandle;
if (! (idBlock->ancestorId==self->mainWindow ||
idBlock->selfId==self->mainWindow)) return FALSE;
/*handle event*/
return TRUE;
}
Anyway I've probably wittered on long enough - hope it helps
--
Colin
Robert Richards
> In message <7499ac35.0112...@posting.google.com>
> epy...@nottingham.ac.uk (Robert Richards) wrote:
>
> > Richard Walker <runny...@mindless.com> wrote in message news:<4f91c5e24...@riscpc.ntlworld.com>...
> >
> > Well my task for tonight is to dig out the Nutshell CD and search see if
> > the Toolbox articles it contains shed any more light on the situation.
> > I'll report back OK.
>
> Cool.
>
<rummage>
Aha! Here it is! Now chuck clothes/boxes/printer back in cupboard...
</rummage>
Coo! There's loads of stuff about the toolbox on it. There are 2
introductory articles by Tony Howat, and later on a series which teaches
you how to construct a simple application (tone dialler and phonebook) and
write the code that hooks into the toolbox created stuff.
There are also various other articles about the toolbox - it was 1am,
didn't have much time to search through it all.
I think I've solved my wriatble icon not writing bug, which cheered me up
:-)).
> If I can polish up my own little Toolbox test application, then you are
> welcome to have a look at it. But please don't laugh! ;-)
>
I am in *no* position to laugh at anybody else efforts! :-)
I'd definately like to have a look at it, feel free to mail it to me when
it's in a state you think worthy of perusal.
> > I should really be writing all this down in some kind of diary. Might be
> > useful for others if I stuck it on my website. There seems to be quite a
> > bit of support for novice WIMP programmers, but a lot less for absolute
> > beginners.
>
> Maybe. I think there is a definate gap in the documentation/tutorial area
> here. Just pop over to, say, developer.kde.org (or ask Google about Java)
> and you'll get *zillions* of helpful tutorials etc.
Yeah. I guess it's an indication of the number of people using RISC
OS. The other thing that struck me from the Nutshell CD was pictures of
Acorn World shows. Stands as far as the eye could see, some very
impressive, but every square foot filled with thousands of people queing
at every stand.
To be honest, I don't think we're in a position to moan - those with the
knowledge do their best to help us out, but there are only so many hours
in the day.
TTFN!!
Robert
Richard Walker
Colin Granville <colin.g...@gmx.co.uk> wrote:
> Richard Walker <runny...@mindless.com> wrote:
>
> > Ah... so that's the alternative to the 'shared' bit. I see! Thankyou.
>
> As far as shared/ancestor/autocreate are concerned this is my
> strategy for using them:
[ snip ]
Thanks. I've filed that!
--
Richard.
"The magical mystery tour is coming to take you away."
VinceH (real address)
I have a vague recollection of Rosemary Miskin
talking about putting a Toolbox tutorial on her
website. IIRC, she did say it would be a BASIC
tutorial, but language differences aside, the
principles will stand.
http://www.argonet.co.uk/users/miskin/
VinceH
--
WebChange 2 for RISC OS: 15ukp - see http://www.softrock.co.uk/webchange/
Oh and there's also a crappy Windows95/98 version for 6.50ukp there, too.
druck
> It seems that OSLib disagrees with the Acorn libs as to whether event codes
> should be signed or not, but as Richard is using OSLib, he can hardly be
> blamed for following its version of events :)
The OSLib policy is that any integer value that it is not appropriate to
perform artimetic on (such as handles, opaque codes and flags) should be
unsigned.
---druck
--
The ARM Club * http://www.armclub.org.uk/
Geoff Youngs
druck <ne...@druck.freeuk.com> wrote:
> On 4 Dec 2001 Geoff Youngs <ge...@solutionsweb.co.uk> wrote:
> > It seems that OSLib disagrees with the Acorn libs as to whether event
> > codes should be signed or not, but as Richard is using OSLib, he can
> > hardly be blamed for following its version of events :)
> The OSLib policy is that any integer value that it is not appropriate to
> perform artimetic on (such as handles, opaque codes and flags) should be
> unsigned.
Which, IMHO, is not helpful in this instance as negative values are of
special significance to the Toolbox. But in practice it's unlikely to cause
anything more than a bit of confusion between programmers using different
libraries.
Yours,
druck
> In message <0d9cc7e3...@druck.freeuk.net>
> druck <ne...@druck.freeuk.com> wrote:
>
> > On 4 Dec 2001 Geoff Youngs <ge...@solutionsweb.co.uk> wrote:
> > > It seems that OSLib disagrees with the Acorn libs as to whether event
> > > codes should be signed or not, but as Richard is using OSLib, he can
> > > hardly be blamed for following its version of events :)
>
> > The OSLib policy is that any integer value that it is not appropriate to
> > perform artimetic on (such as handles, opaque codes and flags) should be
> > unsigned.
>
> Which, IMHO, is not helpful in this instance as negative values are of
> special significance to the Toolbox. But in practice it's unlikely to
> cause anything more than a bit of confusion between programmers using
> different libraries.
Then suggest it to the OSLib maintainers, they will only be to happy to look
in to it, as they have done with several other occurrences.
Richard Walker
"VinceH (real address)" <vin...@SPAMsoftrock.co.uk> wrote:
> http://www.argonet.co.uk/users/miskin/
Thanks. That could indeed be useful.
Tony van der Hoff
druck <ne...@druck.freeuk.com> wrote:
Thank you, Druck :-)
I didn't chip in before, because I didn't understand the problem, as I'm
unaware of negative values of special significance to the toolbox.
To confirm Dave's earlier statement, but looking from the opposite end,
OSLib defines a |bits| type, which itself is defined as an |unsigned int|.
This type is used wherever a bitfield is passed by / returned from OSLib. An
|int| will, in general, only (and always) be used for a value which will
potentially take part in an arithmetic operation.
OSLib provides manifest constants against which bit values can be tested,
masked, rotated, etc. I don't believe that signedness should ever become an
issue anywhere in the API, which is naturally unsigned; with values simply
passed in registers.
Having, with due consideration, established our policy towards signedness,
its implementation has, at times, been open to the interpretation of
individual developers, sometimes incorrectly. This has in the past resulted
in some lively discussion, and, where necessary, the interface has
been corrected.
Sometimes |int|s are returned, when maybe the extra bit gained from an
|unsigned| would be considered useful. However, returning an |unsigned| would
make arithmetic hard. File position indexes, which are |ints|, neatly fall
into this category. The monotonic time, |os_t|, which is an |int|, recently
had a bit of an airing in this context on the OSLib-users M/L. It remained
unchanged, despite the the fact that it could never go negative, and it could
potentially have gained an extra significant bit. (TBH, it was I who wanted
to change it, but was strongly siscouraged by users :-)
I can't instantly think of instances of the type of problem you refer to,
where |bits| are used where signed values are required, but I'd certainly be
happy to hear your views, and make the necessary changes if appropriate.
Certainly, where |int|s are required by the toolbox, for instance in
slider_set_value, an |int| is used for the value. Anywhere else, i.e. flags,
handles, etc., |bits| are (IMHO correctly) used.
I wonder if you're not using the term "negative values", where you really
mean "bit 31 set". I do not believe that the Acorn toolbox manual is
semantically correct in this regard, and it is certainly not consistent.
OSLib tries to impose some order in this chaos. Whether or not this is to
everyone's taste is doubtful, given human nature.
For instance, Acorn talks of a "null" object ID being -1, but IMHO this
should be an opaque value; no-one should be doing arithmetic on an object
ID, so the value -1 is meaningless. What they really mean is that the
toolbox returns the value 0xffffffff in a register, which, when cast into an
|int| yields the value -1. But what justifies such a cast in the first
place? OSLib does not attempt the cast, and instead provides the constant
toolbox_NULL_COMPONENT (which evaluates to 0xffffffffu) to test for a null
component, so the actual value can remain opaque to users.
Finally, I must acknowledge a minor problem, but which is easily overcome, in
that whilst OSLib defines most of the constants used by the API, there are
still some missing. Let me know if you find any, and I'll make sure they're
put in.
--
Tony van der Hoff | MailTo:to...@mk-net.demon.co.uk
| MailTo:avand...@iee.org
Buckinghamshire, England | http:www.mk-net.demon.co.uk
druck
> For instance, Acorn talks of a "null" object ID being -1, but IMHO this
> should be an opaque value; no-one should be doing arithmetic on an object
> ID, so the value -1 is meaningless. What they really mean is that the
> toolbox returns the value 0xffffffff in a register, which, when cast into
> an |int| yields the value -1. But what justifies such a cast in the first
> place? OSLib does not attempt the cast, and instead provides the constant
> toolbox_NULL_COMPONENT (which evaluates to 0xffffffffu) to test for a null
> component, so the actual value can remain opaque to users.
This is a very good point, I have seen on many occations on this an other
platforms, people believing that a test of equality with the specific value
of -1 is equivalent to a signed comarison with less than zero. This of course
leaves the program wide open to future breakage if other bit 31 set values
are used to signify other conditions. By defining the return value as
unsigned and the constant as 0xffffffffu, the compiler will pickup up the
problem. e.g, Norcroft gives the lovely "odd unsigned comparison with 0: '<'"
Geoff Youngs
druck <ne...@druck.freeuk.com> wrote:
Um. Valid as these points are, they seemingly don't impinge upon the
original which was not a technical critique, simply an observation that the
Acorn libraries doing one thing and OSLib doing something else can confuse
programmers using different libraries, particularly given that OSLibSupport
only goes 99% of the way to providing a Acorn libs compatible interface.
This thread has demonstrated how this can cause confusion, given that pretty
much all the other types are the same and OSLib differs from the Acorn
documentation. I wasn't suggesting that either side had got it right, simply
making an observation with regard to a comment by PFJ who queried some code
which was /almost/ the same as it would have been for use with the Acorn
libs.
But, just to play Devil's Advocate, given that all valid ObjectIds are signed
integers >0 (i.e. both -1 and 0 are special values), is there not the
/potential/ for a situation where a signed comparison of ObjectIds to check
validity might be of use for, say, a library adding higher level event
support to the Toolbox?
Tony van der Hoff
Geoff Youngs <ge...@solutionsweb.co.uk> wrote:
Yes, Geoff, that was understood. And this was certainly not intended as an
attack on you or anyone else. You were pointing out a difference, and I was
trying to explain, to the NG in general, because not everybody has the level
of understanding that you have, how this situation came about.
In that quoted paragraph in particular, I tried to explain the background to
the difference between OSLib's and Acorn's toolbox veneers. People are, of
course, free to choose which they prefer, although mixing the two interfaces
is fraught with danger for the unaware.
As for the compatibility bits in OSLibSupport, they're only intended to help
migration, anyone developing new toolbox code using OSLib would surely use
the native types.
> This thread has demonstrated how this can cause confusion, given that
> pretty much all the other types are the same and OSLib differs from the
> Acorn documentation.
Not really; I said the Acorn documentation is inconsistent. On page 6 of the
toolbox manual, they state that an object id is a 32 bit integer. This would
imply that it's unsigned. On page 7 they go as far as stating that a null
component id is 0xffffffff, which is certainly an unsigned value. OSLib takes
its cue from this ddocumentation. Acorn themselves broke thir own rules by
using signed ints in their veneers.
The confusion is entirely of Acorn's making. In the current context, I felt
it was necessary to inform the denizens of csap of this situation, in the
hope that people who don't properly understand these things won't make the
mistake of
>I wasn't suggesting that either side had got it right, simply making an
>observation with regard to a comment by PFJ who queried some code which was
>/almost/ the same as it would have been for use with the Acorn libs.
>
Nobody was suggesting you were, Geoff. This was merely a technical rationale
of why things are the way they are. As I said, I'm quite prepared to consider
reasons why they should change.
> But, just to play Devil's Advocate, given that all valid ObjectIds are
> signed integers >0 (i.e. both -1 and 0 are special values), is there not
> the /potential/ for a situation where a signed comparison of ObjectIds to
> check validity might be of use for, say, a library adding higher level
> event support to the Toolbox?
>
Well, IMHO, your "given" data is incorrect. They are *not* signed integers;
my whole point was that they are opaque handles. From Acorn's documentation,
in the case of an object id, 0 is special; all other values are legitimate;
whereas in the case of component ids, 0xffffffff is special; a component id
between 0 and 0xffffffd is legitimate for menus; and between 0 and 0x7fffff
is legitimate for windows. Other values are reserved, so I would say that any
signed comparison is not generally useful, and is potentially dangerous.
I have here a C++ library in quite an advanced state of development
which abstracts toolbox events at a very high level. It sits on top of
OSLib, and I have not had any cause to consider using signed comparisons.
Steve Drain
> Tony van der Hoff wrote:
> > For instance, Acorn talks of a "null" object ID being -1, but IMHO this
> > should be an opaque value; no-one should be doing arithmetic on an object
> This is a very good point, ...
The manual (the API) is quite specific that 'no object' is
represented by 0 and 'no component' by -1, so there are hiccups
here. ;-)
--
; ,', Steve Drain. Kappa http://www.users.zetnet.co.uk/kappa/
;,'
;',
,; ',,
Tony van der Hoff
Steve Drain <steve...@kappa.zetnet.co.uk> wrote:
> druck wrote:
> > Tony van der Hoff wrote:
> > > For instance, Acorn talks of a "null" object ID being -1, but IMHO this
> > > should be an opaque value; no-one should be doing arithmetic on an
> > > object ID, so the value -1 is meaningless. ...
> > This is a very good point, ...
>
> The manual (the API) is quite specific that 'no object' is
> represented by 0 and 'no component' by -1, so there are hiccups
> here. ;-)
>
Where did you find that, Steve? My Toolbox manual (on page 7, first
paaragraph) is indeed quite specific: "0xffffffff is used to indicate 'no
component'." :-)
As I said elsewhere, it's not consistent.
Steve Drain
> > druck wrote:
> > > Tony van der Hoff wrote:
> > > > For instance, Acorn talks of a "null" object ID being -1, but IMHO this
> > > > should be an opaque value; no-one should be doing arithmetic on an
> > > > object ID, so the value -1 is meaningless. ...
> > > This is a very good point, ...
> > The manual (the API) is quite specific that 'no object' is
> > represented by 0 and 'no component' by -1, so there are hiccups
> > here. ;-)
> Where did you find that, Steve? My Toolbox manual (on page 7, first
> paaragraph) is indeed quite specific: "0xffffffff is used to indicate 'no
> component'." :-)
> As I said elsewhere, it's not consistent.
Both are mentioned on page 14, but the 'no object' id is also on page
6. There is an inconsistencey between 'no object' and ' no
component', and I think you may have conflated them. I have not done
anything with the Toolbox for some time, but I remember this got me too.
;-)
To expand slightly, the Toolbox has a SWI interface available to all
languages, and deals specifically with integers [1]. Although a library
may use a 'NULL' conceptually, it cannot abstract it away from the
underlying definition. One step further and I will be out of my depth.
[1] My reading of the manual is that object ids cannot be interpreted
as numbers, but component ids are essentially unsigned, and the
client program that assigns them can presumably do anything it wants
with them. The manual is again inconsistent in being specific about
&FFFFFFFF (unsigned) and then referring later to -1.
Richard Walker
Tony van der Hoff <to...@mk-net.demon.co.uk> wrote:
> I have here a C++ library in quite an advanced state of development which
> abstracts toolbox events at a very high level.
Wwwwwwoooooo! Would you like to tell us all a bit more about that?
--
Richard.
"Help, I need somebody, help, not just anybody, help."
Tony van der Hoff
Richard Walker <runny...@mindless.com> wrote:
> In message <f33ca2e...@mk-net.demon.co.uk>
> Tony van der Hoff <to...@mk-net.demon.co.uk> wrote:
>
> > I have here a C++ library in quite an advanced state of development which
> > abstracts toolbox events at a very high level.
>
> Wwwwwwoooooo! Would you like to tell us all a bit more about that?
>
Not much to tell, really. I have abstracted the whole toolbox API, plus other
necessary bits of the OS API, into a set of C++ classes, including the event
handling.
I thus have a WimpApp class, which registers the application, looks after
polling, and dispatches any events to the appropriate classes. I can thus
derive a user Application from that, which, for instance, creates an Iconbar
object, which in turn is derived from an IconbarIcon object. IconbarIcon
registers itself for click events which are passed to a default
IconbarIconClickProc() handler which is overridden in the derived Iconbar
object to handle as it chooses.
This is currently part of my resource file editor, REd, and it works very
well, so far. My plan is, that once REd is finally released, I will tidy up
WimpClassLib, document it, and release it as open source.
Note, That will happen at the appropriate time. I do not expect to be
badgered for it.
Stewart Brodie
"Geoff Youngs" <ge...@solutionsweb.co.uk> wrote in message
news:7cbd95e4...@solutionsweb.co.uk...
> But, just to play Devil's Advocate, given that all valid ObjectIds are
signed
> integers >0 (i.e. both -1 and 0 are special values), is there not the
> /potential/ for a situation where a signed comparison of ObjectIds to
check
> validity might be of use for, say, a library adding higher level event
> support to the Toolbox?
Your assertion is incorrect - valid ObjectIds are opaque 32-bit integers.
In actuality, they are a combination of address bits and serial numbers
combined in such a way that object IDs are *highly unlikely* to ever be
reused (and hence making them definitively "unsigned"? :-)
In either case, the confusion arises because you are looking at the C
language bindings (in the Acorn library) for the Toolbox. It is hard to
derive language bindings correctly, particularly given that ARM (integer
arithmetic) registers can behave as both signed and unsigned simultaneously.
Furthermore, given that we are talking about C implementations which use a
binary representation which matches ARM register layout, it is actually
irrelevant whether the IDs are signed or unsigned - except for the purposes
of interface design where you need to pass a pointer to an ID. In any case,
the binary interface (ABI) is identical: all pointers have the same
representation.
It used to be the case that multiple object IDs could map to the same
internal object. because with 8 serial number bits being ignored, you had
256 different object IDs containing the same address bits). This used to
cause a problem because if you deleted an object and then created another
object, it would likely to allocated from the same address, and object IDs
tend to exist for a while after deletion (in undelivered *HasBeenClosed
messages or whatever). At some version of the Toolbox module when Browse
updates were being produced, I added a cross-check in the object ID
validation code to verify that the ID specified by the user was that
generated when the object was created. This cross-check code is what
generates the "Invalid object ID (xxxx) (xxxx) (2)" error messages. A final
(1) means something else - like the derived pointer didn't pass an
OS_ValidateAddress check.
--
Stewart Brodie, Senior Software Engineer
Pace Micro Technology plc.
645 Newmarket Road,
Cambridge, CB4 2NL, UK WWW: http://www.pace.co.uk
Geoff Youngs
"Stewart Brodie" <stewart...@pace.co.uk> wrote:
> "Geoff Youngs" <ge...@solutionsweb.co.uk> wrote in message
> news:7cbd95e4...@solutionsweb.co.uk...
> > But, just to play Devil's Advocate, given that all valid ObjectIds are
> > signed integers >0 (i.e. both -1 and 0 are special values), is there not
> > the /potential/ for a situation where a signed comparison of ObjectIds to
> > check validity might be of use for, say, a library adding higher level
> > event support to the Toolbox?
> Your assertion is incorrect - valid ObjectIds are opaque 32-bit integers.
> In actuality, they are a combination of address bits and serial numbers
> combined in such a way that object IDs are *highly unlikely* to ever be
> reused (and hence making them definitively "unsigned"? :-)
I wasn't thinking of genuine ObjectIds - they obviously shouldn't be relied
on to provide any meaningful information, but rather of a library like the
event library which takes a variety of special values as well as genuine
ObjectIds. In such a situation (if the assumption that ObjectId won't use
the top bit is correct) a signed comparison could be used to check whether
the item in question was a genuine ObjectId or a special value.
OTOH and IMHO a rewrite of the event library would do better to use a flags
field instead of special ObjectId values.
Kevin Bracey
Geoff Youngs <ge...@solutionsweb.co.uk> wrote:
> In message <9v0os6$sq4$1...@nh.pace.co.uk>
> "Stewart Brodie" <stewart...@pace.co.uk> wrote:
> > Your assertion is incorrect - valid ObjectIds are opaque 32-bit integers.
> > In actuality, they are a combination of address bits and serial numbers
> > combined in such a way that object IDs are *highly unlikely* to ever be
> > reused (and hence making them definitively "unsigned"? :-)
>
> I wasn't thinking of genuine ObjectIds - they obviously shouldn't be relied
> on to provide any meaningful information, but rather of a library like the
> event library which takes a variety of special values as well as genuine
> ObjectIds. In such a situation (if the assumption that ObjectId won't use
> the top bit is correct) a signed comparison could be used to check whether
> the item in question was a genuine ObjectId or a special value.
Er, no. That's the point. I for one cannot see anything that says that
Object IDs are positive signed numbers. The manual says "an object ID is
a 32-bit integer, which should not be interpreted by the client application.
An abject id of 0 is used to indiate 'no object'."
So a 'negative' number could be a valid object id. Part of the point of
making the type unsigned is to discourage people from making invalid signed
comparisons with 0.
The event library's use of -1 is dubious, given the documentation, but as
long as it only tests for -1 exactly, it's far less likely to cause harm than
rejecting all negative numbers.
--
Kevin Bracey, Principal Software Engineer
Pace Micro Technology plc Tel: +44 (0) 1223 518566
645 Newmarket Road Fax: +44 (0) 1223 518526
Cambridge, CB5 8PB, United Kingdom WWW: http://www.pace.co.uk/
Stewart Brodie
Kevin Bracey <kevin....@pace.co.uk> wrote:
Plus of course that -1 is a valid unsigned constant (in C) :-) [*]
[*] Yes, really!
--
Stewart Brodie, Senior Software Engineer (Views expressed are my own and
Pace Micro Technology PLC not those of my employer)
645 Newmarket Road
Cambridge, CB5 8PB, United Kingdom WWW: http://www.pacemicro.com/
Kevin Bracey
> An abject id of 0 is used to indiate 'no object'."
^^
Of course, I meant "object id". One of the advantages of using a Dvorak
keyboard layout is that you get totally different typos to everyone else.
Nemo
> One of the advantages of using a Dvorak keyboard layout...
Now you're just showing off ;-)
Well I'm typing in PDFDocEnc (alphabet 95), so there 8^)
--
Nemo ne...@20000.org