Toolbox Classes

Another random question, what are the integer values for each of the current toolbox classes? I can’t seem find them recorded anywhere.

Looking through the header files, are the class numbers just the same as the swi chunk base for each prototype?

Hi,
I did not find it in the ToolBox manual, maybe an error from me?

I use OsLib and in the StrongEd ​​manual, each gadget has its well defined class, very useful.
Example:
class_ACTION_BUTTON = 0×80

Thanks for this, but I’ve never used OSLib, I do have a download though which is probably very old. However, I think I’ve found my answer by delving into the !TboxCalc example by looking into main, there I’ve found where toolbox events are registered dynamically for both window and menu objects when they are automatically created. The switch statement uses the objects class value for the case statements, going back to the includes for both toolbox window and menu prototypes the values relate to their individual prototype toolbox SWI base numbers.

I do find this difficult describing the toolbox library using the words class and object when there is no object orientated programming involved such as C++ (as in using CFront), but that’s just me.

You are right about the object classes.

I followed the same route as you when I bought the DDE, I used these examples with their libraries to program.
For me, I prefer OSlib + OsLibSupport which replaces eventlib, tboxlib and wimplib and offers more functions, see StrongEd manuals.
I tend to convert old programs to the OsLib version that I’m starting to know better. (I hope the OsLib update continues…)

I do find this difficult describing the toolbox library using the words class and object when there is no object orientated programming involved such as C++

Good question: gadgets are built by inheritance from base classes.
Objects have flags such as ancestor object or shared object or some form of hierarchy.

While waiting for the update of the ToolBox, it can be used, even in C++ with the DDE (It will be easier if CFront is also updated.).

If I have time I will put on my site, two examples of !ToolBoxCalc, one in C with Oslib and the other in C++ which also uses Oslib.
I feel there are going to be criticisms, but it’s not easy to choose a way to program for RISC OS.

Looking through the header files, are the class numbers just the same as the swi chunk base for each prototype?

From the Appnote 280 (1995), on writing Toolbox modules:

“IMPORTANT NOTE: In the current implementation, the Class SWI Number and the Object Class Number must be the same.”

“Each Object Class has its own Class Number. These numbers are centrally allocated by Acorn; in fact a Class Number is the Class SWI of the Object Module which implements Objects of that Class.”

“Note that a single Object Module may implement more than one Class, by registering more than one Class SWI from its chunk with the Toolbox, for example the DCS Module implements both the DCS and Quit objects”

“Toolbox Events should also be based on the Class Number.”

So, you can determine an Object Class Number by looking at the number of the first specified event for that class. ;-)

If you allow that Gadget Types are actually classes, then it is slightly more complicated, I think.

The original types provided by the Window module are specified in the Toolbox manual, but the extensions such as Tabs have a SWI chunk allocation, which determines the event numbers. However, Gadget type numbers have to be a half-word, so the first and last hex digits are omitted, ie: &1402C0 becomes &402C. I could not find this specified, but it implicit in Appnote 281 on Gadgets.

The way I use the Toolbox requires the Class name from the Class number, which is not provided for. So I have a MessageTrans file to do this, which you might find helpful:

# Oobi Toolbox numbers to names

# Classes

44EC0:Desktop
829C0:ColourDbox
82980:ColourMenu
82A80:DCSDbox
82AC0:FileInfo
82A00:FontDbox
82A40:FontMenu
82900:Iconbar
828C0:Menu
82B00:PrintDbox
82B40:ProgInfo
82A90:QuitDbox
82BC0:SaveAs
82C00:ScaleDbox
82880:Window

# Gadgets

40:Generic
80:ActionButton
C0:OptionButton
300:AdjusterArrows
3C0:Button
1C0:DisplayField
280:Draggable
100:LabelledBox
140:Label
340:NumberRange
2C0:PopUp
180:RadioButton
240:Slider
380:StringSet
200:Writable
4014:ToolAction
4018:TextArea
401A:ScrollList
401B:ScrollBar
402C:Tabs
4028:TreeView

Note thet the names are not exactly the same as the manual.

I do find this difficult describing the toolbox library using the words class and object when there is no object orientated programming involved such as C++ (as in using CFront), but that’s just me.

I am a dilettante, but I find that OOP is a state of mind, so it does not require a particular language to do it and I am happy pootling away with BASIC. The Toolbox is definitely Class-oriented, even if its API is individual SWIs.

A long while ago I wrote a faily extensive section in my Basalt StrongHelp manual about how to view the Toolbox this way. You might search it out or I could extract it in a more convenient form.

Thanks Steve, a useful list.

I’ve gradually been getting back to programming for RiscOS, my RiscPC currently sits in my attic so I’m using a mixture of Raspberry Pi and RPCEmu. For a long time I’ve been programming in Java so thought I would see if I could translate that mindset of OO on RiscOS. I’ve used the DDE back years ago on the RiscPC for assembler and C and more recently on the Raspberry Pi, but never really tried the C++/CFront so I thought I would have a go, I know there are limitations, hopefully sometime it will be updated. I’m currently in the process, for my own amusement, in creating an OO library for the toolbox, using the DDE C++.

There seems to be a core of toolbox SWI calls which could be set as static in a single class and others which could be placed in a separate class and used as a base class for the various prototype classes.

To test the STL with the DDE and CFront I used a book: Java and C++ en // by JB Boichat (French) especially for the Object Oriented approach:that works fine.

Note: Alexander Thoukydides built an OO library for the ToolBox.Alexander has developed his application !PsiFS in C++.

There seems to be a core of toolbox SWI calls which could be set as static in a single class and others which could be placed in a separate class and used as a base class for the various prototype classes.

I had to declare static the toolbox events handler in the myclass.h class declaration.

For example,I build a small application in C++ that I put on my site, there is also the source for information.
download

I looked at Alexander Thoukydides GitHub content but was unable to spot an OO DDE toolbox library. There are classes for various gadgets, not sure how they relate to the DDE toolbox. What was very different and took a bit of time to twig, the header files contained the code for the methods, not just the class definition. The C++ files just contained an include for the associated header file. A very different style to my own. Haven’t dowloaded and looked at your event handlers yet but yes I can understand they would need be declared static, haven’t looked at event handlers yet so I might steal some ideas.

I looked at Alexander Thoukydides GitHub content but was unable to spot an OO DDE toolbox library.

It is a good example. Alas the Visual Component Library (Borland), does not exist for RISC OS

There are classes for various gadgets, not sure how they relate to the DDE toolbox.

What was very different and took a bit of time to twig, the header files contained the code for the methods, not just the class definition. The C++ files just contained an include for the associated header file.

Not all… and using inline functions is fine, DDE allows it

Haven’t dowloaded and looked at your event handlers yet but yes I can understand they would need be declared static, haven’t looked at event handlers yet so I might steal some ideas.

Waiting for an updated version of CFront!
We also lack the visual design tool VCL like or RAD/EDI

Waiting for an updated version of CFront!

CFront hasn’t been updated since the early 90’s when everyone moved to native compilers. It is not a lot of use to anyone who doesn’t still write C++ in Latin.

Alan of PackMan fame has TBX, a Toolbox library written in C++:
https://sites.google.com/site/alansriscosstuff/tbx
https://github.com/alanbu/tbx
https://github.com/alanbu/tbxexamples

(given the aforesaid CFront antiquity, it requires GCC. Which is really the only maintained RISC OS C++ toolchain these days)

I’m sure there are other Toolbox/C++ libraries around, but can’t think of any at the moment.

It is not a lot of use to anyone who doesn’t still write C++ in Latin.

Ite missa est DDE :-)
I agree with you, CFront is an antiquity, but I don’t know if ROOL will be able to provide us with a real C++ compiler.
I have to explore TBX.
I tried to compile the examples, but the compilation starts but there is a problem.
The makefiles must need to be updated (2011) to be adapted to the libraries, I think?
Any help on this would be appreciated, thanks.

I have to explore TBX.
I tried to compile the examples, but the compilation starts but there is a problem.
The makefiles must need to be updated (2011) to be adapted to the libraries, I think?
Any help on this would be appreciated, thanks.

A quick explore shows that the TBX examples do build with gcc4.7.4 rel6 but do require a 24MB WimpSlot, only 16MB is called for in MakeAll.

CleanAll uses the rm utility which can be found in CoreUtils from PackMan.

HTH.

Added I thought there was something familiar about this. See here for a bit more detail.

Thank David for these explanations.
I modified MakeAll to have a 24 kB WimpSlot, I also installed !CoreUtils.
CleanAll works.
Make may work, but bugs after building the first example.
I try to run it but it only shows me an error message:
Fatal signal received: Segmentation fault
I have GGC 4.7.4 release 6.
ARMX6 RISC OS 5.29 01/02/2022

Is this a problem with SharedLibs?
GCC configuration ?
If you have any idea, thank you

Make may work, but bugs after building the first example.
I try to run it but it only shows me an error message:
Fatal signal received: Segmentation fault
I have GGC 4.7.4 release 6.
ARMX6 RISC OS 5.29 01/02/2022

I do not see that on either the Titanium or RPi400.

Is this a problem with SharedLibs?

The SharedLibs that comes with GCC 4.7.4 rel. 6 are fine.

If you have any idea, thank you

Is there an Iris installation present, that can interfere with SharedLibs and other dependencies, but I would be surprised if that would mess up GCC. To avoid that reboot, don’t go anywhere near Iris and ensure that GCC’s SharedLibs is the one in use.

Sorry for the delay in replying, I missed the post in amongst the forum noise.

Afterthought It is the right version of make from PackMan?

*make --version
GNU Make 4.2.1

David, thank you for your answer, no problem for the delay, due to “forum noise” :-)
Toolbox and C++ topic is interesting, I think it’s the right way to build apps, (my opinion).
Alas, whitn !TBX and GCC I tried with the example, but not conclusive. Only one works, it’s !IconView.
I have the correct version of Make, and the GCC examples compile and work.
I tried adding the -mlibscl suffix in the Makefile, but it’s no better.
In !Boot there is a resource !SharedLibs
I think it is seen before !GCC?
SharedLibs$Dir : SCSI::SSD.$.SharedLibs
SharedLibs$Path : SCSI::SSD.$.SharedLibs.

Thank for your help.

Try running MakeAll in a TaskWindow to capture the errors. This is what that looks like here.

*ADFS::Titan4.$.Work.Proj.TBX.TbxExamples.MakeAll
make: Entering directory '/ADFS::Titan4.$/Work/Proj/TBX/TbxExamples/!Graphics/src'
g++ -O2 -Wall -mpoke-function-name -mthrowback -ITBX:   -c -o GraphicsWnd.o GraphicsWnd.cc
g++ -O2 -Wall -mpoke-function-name -mthrowback -ITBX:   -c -o SaveAsSprite.o SaveAsSprite.cc
g++ -O2 -Wall -mpoke-function-name -mthrowback -ITBX:   -c -o main.o main.cc
g++ -LTBX: -ltbx -lstdc++ -static -o !RunImage,e1f GraphicsWnd.o SaveAsSprite.o main.o
elf2aif !RunImage,e1f ^.!RunImage
make: Leaving directory '/ADFS::Titan4.$/Work/Proj/TBX/TbxExamples/!Graphics/src'
make: Entering directory '/ADFS::Titan4.$/Work/Proj/TBX/TbxExamples/!IconView/src'
g++ -O2 -ITBX: -mthrowback   -c -o main.o main.cc
g++ -O2 -ITBX: -mthrowback   -c -o iconviewer.o iconviewer.cc
g++ -LTBX: -ltbx -static main.o iconviewer.o -o iconview
elf2aif iconview ^.!RunImage
make: Leaving directory '/ADFS::Titan4.$/Work/Proj/TBX/TbxExamples/!IconView/src'
make: Entering directory '/ADFS::Titan4.$/Work/Proj/TBX/TbxExamples/!Reverse/src'
g++ -O2 -ITBX: -mthrowback   -c -o main.o main.cc
g++ -O2 -ITBX: -mthrowback   -c -o reverser.o reverser.cc
g++ -LTBX: -ltbx -static main.o reverser.o -o reverse
elf2aif reverse ^.!RunImage
make: Leaving directory '/ADFS::Titan4.$/Work/Proj/TBX/TbxExamples/!Reverse/src'
make: Entering directory '/ADFS::Titan4.$/Work/Proj/TBX/TbxExamples/!StopWatch/src'
g++ -O2 -Wall -mpoke-function-name -mthrowback -ITBX:   -c -o main.o main.cc
g++ -O2 -Wall -mpoke-function-name -mthrowback -ITBX:   -c -o StopWatchWnd.o StopWatchWnd.cc
g++ -LTBX: -ltbx -lstdc++ -static -o !RunImage,e1f main.o StopWatchWnd.o
elf2aif !RunImage,e1f ^.!RunImage
make: Leaving directory '/ADFS::Titan4.$/Work/Proj/TBX/TbxExamples/!StopWatch/src'
make: Entering directory '/ADFS::Titan4.$/Work/Proj/TBX/TbxExamples/!TbxDocEx/src'
g++ -O2 -Wall -mpoke-function-name -mthrowback -ITBX:   -c -o TbxExWnd.o TbxExWnd.cc
g++ -O2 -Wall -mpoke-function-name -mthrowback -ITBX:   -c -o TbxExDoc.o TbxExDoc.cc
g++ -O2 -Wall -mpoke-function-name -mthrowback -ITBX:   -c -o main.o main.cc
g++ -LTBX: -ltbx -lstdc++ -static -o !RunImage,e1f TbxExWnd.o TbxExDoc.o main.o
elf2aif !RunImage,e1f ^.!RunImage
make: Leaving directory '/ADFS::Titan4.$/Work/Proj/TBX/TbxExamples/!TbxDocEx/src'
make: Entering directory '/ADFS::Titan4.$/Work/Proj/TBX/TbxExamples/!TbxMin/src'
g++ -O2 -ITBX:   -c -o tbxmin.o tbxmin.cc
g++ -LTBX: -ltbx -static tbxmin.o -o tbxmin
elf2aif tbxmin ^.!RunImage
make: Leaving directory '/ADFS::Titan4.$/Work/Proj/TBX/TbxExamples/!TbxMin/src'
make: Entering directory '/ADFS::Titan4.$/Work/Proj/TBX/TbxExamples/!TbxClip/src'
g++ -O2 -Wall -mpoke-function-name -mthrowback -ITBX:   -c -o TbxClipWnd.o TbxClipWnd.cc
g++ -O2 -Wall -mpoke-function-name -mthrowback -ITBX:   -c -o main.o main.cc
g++ -O2 -Wall -mpoke-function-name -mthrowback -ITBX:   -c -o Loaders.o Loaders.cc
g++ -O2 -Wall -mpoke-function-name -mthrowback -ITBX:   -c -o BuildSpriteData.o BuildSpriteData.cc
g++ -LTBX: -ltbx -lstdc++ -static -o !RunImageE1f TbxClipWnd.o main.o Loaders.o BuildSpriteData.o
elf2aif !RunImageE1f ^.!RunImage
make: Leaving directory '/ADFS::Titan4.$/Work/Proj/TBX/TbxExamples/!TbxClip/src'
*

The StopWatch app will be useful, I have been using the iPhone for timing RISC OS activities!!

With TimerMod RISC OS can time itself. http://www.armclub.org.uk/free

Bonjour,
I’m only compiling the first example for now. I get exactly the same display as you, the !Runimage (aif) file is indeed in the application’s directory, but as soon as I launch it there is a debugging window which opens with a faulty segmentation …
I don’t run !Iris, only !GCC. I keep searching. I am a lost fear with the libraries in SharedLibs (Resources) and those of !GCC

TimerMod works nice, I use it.

@Druck: There’s a missing l in “Windows can be paced in separate workspaces”, and maybe it’s time to update DRAWMAP (1984) to accept that Germany is now united again! :)

Cool tool.

the !Runimage (aif) file is indeed in the application’s directory, but as soon as I launch it there is a debugging window which opens with a faulty segmentation

The !RunImage AIF, and the intermediate ELF, are static and not dependent on SharedLibs, SharedLibs is only required during the build and that is being satisfactorily completed. I have no good answers but as long shots, is TBX at the latest version as on PackMan or maybe it is something specific the ARMX6.

@Druck: There’s a missing l in “Windows can be paced in separate workspaces”,

Thanks!

and maybe it’s time to update DRAWMAP (1984) to accept that Germany is now united again! :)

Please feel free to delve in to those data statements.

@David
I had downloaded !TBX the latest version some time ago, but it was not installed. :-(
I was using the 2018 version.
It works…almost except one app: !Stopwatch

make: Entering directory ‘/SCSI::SSD.$/AcornDev/DevC++/AlanTbox/TbxExamples/!StopWatch/src’

g++ -O2 -Wall -mpoke-function-name -mthrowback -ITBX:   -c -o main.o main.cc

g++ -O2 -Wall -mpoke-function-name -mthrowback -ITBX:   -c -o StopWatchWnd.o StopWatchWnd.cc

g++ -LTBX: -ltbx -lstdc++ -static -o !RunImage,e1f main.o StopWatchWnd.o

Too long

make: * [Makefile:17: !RunImage,e1f] Error 1

make: Leaving directory ‘/SCSI::SSD.$/AcornDev/DevC++/AlanTbox/TbxExamples/!StopWatch/src’