Toolbox

I’ve come very late to the Toolbox. I’ve ony just started writing my first and second Toolbox apps about a week ago.

It prompts me to ask: who else writes new apps using the Toolbox? (Is it a popular thing?)

And a technical question has just cropped up. I see that the app registers Wimp message handlers in one place. Does this mean that I can call event_poll () from more than one place in my code and still have everything working? It looks like a way to allow different sections of the code to multi-task without building a complex state machine in one place to handle everything. My example is that it looks like I can call a function to resolve a host, or to connect to a host (either of which might take several seconds) and the functions can permit multi-tasking but only return once, after they have finished. If this is true, it looks like quite a powerful benefit.

It prompts me to ask: who else writes new apps using the Toolbox? (Is it a popular thing?)

I am writing my applications toolbox based since around 1996. However my programs are not popular (or better not so popular as I would like to see it ;-) )

In general it is always possible to put evaluation of a Wimp poll into a function and I think so you can call a poll not only in the top most loop.

However the limitations in general are staying. Polling inside a redraw loop isn’t a good idea AFAIR. And there is always the danger of loosing the overview about the dependencies.

Yes the toolbox is installing handlers and calls them in the right moment. Nice is that you can register the handlers for certain objects and pass an individual information word to it. This simplify eg. redrawing a lot as you must not spent any efforts in finding out which window shall be redrawn.
Also a good feature in my eyes is the possibility to pass ancestor object id and components.

The toolbox can be programmed in various ways. It is up to you to choose the best way for you to solve your problem.

The toolbox has also disadvantages. You can’t live without classical SWIs for more complex operations.
Sometimes setting a single option or flag accidentally in a wrong way inside the resources will grant you “joy” for hours to find the reason why nothing happens. And last not least the documentation looks fine but indeed some important details are missing. In most cases it helps to have a look into the libraries.

AppBASIC is a fine development tool which helps to avoid trouble.

However AFAIR some months ago I searched for one operation and at the end I found the solution by trial and error. Ok since source is open you can in last consequence find out everything.

Also nested windows are a class of its own regarding the object ids.

Despite of all this I am using the toolbox for my C and in conjunction with AppBASIC for my BASIC program developments meanwhile for decades.

Thanks, Thomas.

I wasn’t thinking so much about how big the user base is for apps created with the Toolbox; rather I’m interested to know how popular use of the Toolbox is among developers.

But your smiley suggests you understood that very well :-)

For what it’s worth, I’ve used the Toolbox for everything, and never learned how to do things the ‘old way’. Like Thomas said, you can sometimes find yourself scratching your head if you miss something, and in many cases the samples provided with the DDE are more useful than the actual documentation.

I’ve printed a decent chunk of the docs and written all over it :)

I too use the Toolbox for all my applications. In C and C++ with DDE.

Also a good feature in my eyes is the possibility to pass ancestor object id and components.

The object approach is interesting, that’s why I use C++, for example each window is a class with its methods including handlers and its attributes.
Oslib provides a good interface for programming, and together with the StrongHelp manual, the help is very valuable.

The Toolbox is the programming part of the OS which can encourage programmers from other systems to develop applications for RISC OS. This is the main tool found in Borland and Microsoft, certainly Android.

Thanks, all of you, for your replies. Clearly I’m not alone.

Nor am I alone in thinking that the documentation is a bit lacking…

An updated manual is on the to-do list once the active bounty has been completed, but I have no information around how extensive this update will be.

I made a start on a Toolbox library for Python, and find the two work well together. Of course stuff like life has stopped me making as much progress as I’d have liked on it.

I have discovered that the Toolbox manual makes no mention of textarea gadgets. I take it these must have been a later addition to the Toolbox?

Does the Toolbox provide any way to display text, that is settable programmatically, is not editable by the user, and word wraps?

“Display” gadgets display text that is settable programmatically and cannot be edited by the user, but AFAICS does not naturally word wrap. “Textarea” gadgets display text that is settable programmatically and word wraps, but is editable by the user.

What I’m trying to achieve is display of status or non-fatal error messages, in a way that doesn’t stop the whole machine. The text may need to wrap over more than one line in order to avoid having an icon with silly and uncomfortable proportions (very wide, one line high).

It’s closely related to a topic that has come up before in these fora: multi-tasking error boxes.

Hi Dave,
I hope the manual will be completed, same with TreeView and Tabs and I hope others.
Do you program in Basic or C?
For Basic program, AppBasic StrongHelp Manual is nice.
For C program, I use Oslib.
I use the TextArea for my programs, very practical to display on several lines.
If you program in C, OSLib support provides very useful functions in the err.h file that do the job.(fatal or non fatal error)
extract:

	

		
Description: Display a system error message in a pop-up dialogue box.
		
Assumes Application Name to be that registered by
		
wimp_initialise; application sprite name to be that name
		
prefixed by !.
		
Useful for wrapping up kernel function calls which may fail

Used in conjunction with try and catch also from OslibSupport, this makes it a good tool for debugging.
It’s as useful as Basic’s on error report.

Sorry I have problem with Post editing :-(

I almost forgot the TextArea gadget has an option: Faded/Display Only.

Dave – have a look at the ‘Button’ gadget. This is essentially a generic wimp icon. You can use the (in oslib parlance) button_set_validation() to set it to a multiline display icon and then use button_set_value() to set the text at any point.

ResEd allows the validation string to be set at creation if it is not going to change.

What I’m trying to achieve is display of status or non-fatal error messages, in a way that doesn’t stop the whole machine.

With RiscLua this can be achieved using the wimp.task.alert method which fires off Adam Snowstone’s MultiError BASIC application.

Does the Toolbox provide any way to display text, that is settable programmatically, is not editable by the user, and word wraps?

ResEd provides Flags WordWrap and Faded/Display Only for TextAreas. tboxlibs.h.TextArea provides all required functions and it has quite well remarks. However my only idea how to find out the size of the text was to set the cursor to end and back again. Perhaps anyone has better ideas.

My thanks to all of you who replied.

I’m working in C with the DDE.

I’ve set the textarea to be faded/displayonly. It works, but it looks rubbish; the caret can be clicked in there but no editing can take place. The background is darker than it should be, and I can’t lose the border. I was surprised that the default font was not the same as the desktop font, but a bit of head-scratching and research turned up Wimp_ReadSysInfo 8 and Font_ReadDefn, which gave me the right information to put into textarea_set_font() to make the textarea display like the desktop.

I’m going to have to scratch my head considerably more to understand how to use the Button gadget as Chris Johnson has suggested, but I’ll have a go when I can point myself at the computer for a good undisturbed session.

I’m not sure I’ve ever used OSLib, but that’s another one for me to look at.

It is not necessary to use oslib, of course. However, it does provide wrappings for all the toolbox SYS calls, which makes things much easier. In earlier days when first starting to use the toolbox (in Basic and C) I wrote my own functions to make calling the numerous toolbox SYS easier. However, oslib is a much better solution.

I have used textareas in some of my apps, but for what you have outlined, textareas are a bit of a sledgehammer.

If you want to display a multi-tasking warning message then a Button gadget with L validation seems to be the simplest.

Once you have cracked that, you might look at using a DCS object with an alternative Window rather than a special Window object of your own. This simplifies the handling that is necessary.

I have standard Warning and Error objects like this in a separate, library Res file loaded after Initialise.

I’ve printed a decent chunk of the docs and written all over it :)

My very ancient paper manual has a multitude of pencil notes, some for errors and others for missing info.

These days my primary reference is a much modified version of the Toolbox section of my Basalt¹ manual. This is, of course, oriented to BASIC and a genuine OOP approach. I admire the AppBasic documentation, but it is not OO.

The modifications include the Tabs and Treeview modules and comprehensive summaries of all the flags, which are a bit tricky to check through from the manual.

¹ Basalt still provides an OO interface to the Toolbox for BASIC, but it is no longer maintained, I am afraid, and I personally use BASIC on its own.

If you want to display a multi-tasking warning message then a Button gadget with L validation seems to be the simplest.

Thanks, Steve, that seems to work perfectly. I’ve given the Button gadget a max. length of 512 (which seems plenty!), and a validation string of “R2;L”, which slabs it in so it looks the same as a Display gadget, and permits the line to split. And a button type of Never, of course.

Now, if you can implement that as part of an alternative DCS object you might find it even easier.

There are just two attributes – title and message – and up to three events to monitor for the buttons, and that is it. ;-)

The bizarre thing is that the Button makes a better Display gadget than the real Display gadget! All it would take is for the Display gadget to have a tick box for “multi-line” and we’d be where we want to be, via the most obvious route.

And while we’re at it, I find it even more bizarre that the Text area gadget can be set to read only (i.e. not editable), but the user can still click it, and the I-beam appears there. It can’t be moved, so yes the area is read only – but surely it shouldn’t be possible to put the input focus there? That looks like a bug to me.

Personally I’m in favour of being able to click into an error message so that I can copy and paste it into an internet search, or a forum report for example. Some long Windows errors have to be typed in to do the same thing, because you can’t copy the text.

http://heyrick.ddns.net/files/errorcancel.txt

This will automatically cancel an error, after a timeout.

It will also, if you have DADebug running, remember the error text so it can be referred to later.

It is supplied in ObjAsm assembler source, so feel free to mix and match the parts as required. I don’t expect it would be too difficult to change it to use Reporter instead, for instance.

“Nightwish” is misspelled. Completely unusable.

:)

Completely unusable.

If that’s all I got wrong, then that’s good. ;)