Toolbox help

Hi all, I have been trying to get my head around using the toolbox, I wish to use the TextGadget as a built in editor so I do not need to code my own.

My problem is I can program in BASIC and all the info I can find is very confusing. Is there a comprehensive tutorial on how to get going, I am struggling to work out how everything fits together I have created a RES file and it loads and I can click buttons that open menus and other windows but I can not work out how to get data to and from the various icons and windows.

For a start how do you find the id of a window so you can then interact with it?

Thanks
Graham

Hi Graham, I think the following ROL link should be a helpful resource. link

I don’t know how helpful this site is to you, but it contains older Acorn versions of the relevant manuals as PDFs link

AppBasic may be of interest.

You have my sympathies. There is a lot to digest to get going with the toolbox. For one thing, a lot of the programming is actually done by creating an appropriate Resource file using !ResEd, while the !RunImage file is just used for setting up the wimp task and how that communicates with the toolbox – defining handlers for user actions.

I know that your query was about BASIC, but you might be interested in looking at the minimal toolbox example, !Justquit, in the Examples directory for RiscLua. Its !RunImage file looks like this:

#! lua
local riscos = require "riscos"
local $ in riscos
local toolbox = require "wimp.toolbox"
local @ = toolbox:spawn "JustQuit" -- Create toolbox task.
_ENV = @                           -- From here on global vars looked up in @.
$[resdir] = "<JustQuit$Dir>" -- Tell the toolbox where to find res file.
init (@, { }, { })           -- All wimp, all toolbox events signify.
mask = 257                   -- No null or kbd events wanted.
run (@)                      -- This has to be last.

There are a couple of ways to get the ID of the object.

If the object is set to auto create in the res file then you can use the ObjectAutoCreated event to capture the ID.

If you create the object yourself then the ID is passed back to you.

You can watch for the Window_AboutToBeShown event an get the ID.

You can send your own event when the object is about to be shown and get the ID.

Each type of object/gadget has its own SWI’s/Method to interact with them. For example, the Display Field gadget is written to by using Toolbox_ObjectMiscOp with R0 as flags (usually 0), R1 as the window ID, R2 = 448 (the gadgets method), R3 is the gadget number and R4 is a pointer to the string to send.

Personally any app I create I always use the Toolbox.

Here is a quick example I created many years ago..

The Toolbox stronghelp manual is useful.

Thank for all the help so far, I have managed to get a window open and have put some text into it. I am now trying to save the text out as a text file. I must be misunderstanding some area of this as its not as easy as I was expecting.

Hi All,

I have managed to get the TextGadget in a window and I can load text into it and edit the text but.

I have tried my best to save out the text from the TextGadget but every time I get the ’No readable memory at this location" error.

I have sent the request for the location and used the returned result, so I am stuck now, can some kind sole post some code for me to modify for my needs.

Thanks

Can you post the code you’ve written? You need to call TextArea_GetTextSize, DIM some memory, and then TextArea_GetText into that DIMmed block.

Well, I have done this, but my code is either assembler in Basalt or in a rather complex library, so not easy to extract meaningfully.

I assume Julie means call TextArea_GetText with R4=0 to get the size in R5.

One thing that has caught me out using SYS with the Toolbox SWIs is forgetting to include flags, usually 0, in R0. This puts all the other registers out of position and is nonsense.

To return a BASIC string I think I would do:

SYS"Toolbox_ObjectMiscOp",0,window%,&401B,gadget%,&8200,256 TO ,,,,string$

This uses the BASIC INPUT buffer, but you could use your own block%. This is off the top of my head, so treat accordingly.

Edit: made block explicitly a variable

Here is the save procedure I have so far.

   10:
   20 DIM temp% 10000
   30
   40 DEF PROCsave_data(file$,type$)
   50 LOCAL size%,at%
   60 SYS &44EC6,0,winid%,16411,0 TO ,,,,,size%
   70 SYS &44EC6,0,winid%,16411,0,temp%,size% TO ,,,,at%
   80 SYS "OS_File",10,file$,type$,0,at%,size%
   90 SYS "XOS_CLI","SETTYPE " + file$ + " " + type$
 100 ENDPROC
 110:

&8200 … the BASIC INPUT buffer

shudder

What is temp%? For this to work it would have to point to a block of memory of at least size%. As it is, at% has the same value as temp%

I think you have missed the point that you have to transfer the text to a block of memory in your own program before further processing. The Toolbox does not give you access to the internal pointers.

shudder

Why particularly?

It is not officially documented ¹, but it has been fixed in BASIC for nearly 40 years and unless someone at ROOL decides to make fundamental change for no reason, it will stay that way.

Or do you not like using it as a buffer at all? Note that there is a 256 byte buffer at &8300 that is not touched by BASIC after it has loaded the program. Basalt uses that for its arguments.

i think that there are some presentational advantages to using a fixed address rather than a user-defined block%.

Now let me introduce END as a pointer to an unlimited [temporary] block of memory. ;-)

¹ The string accumulator (STRACC] immediately below it is so documented.

Edit: added “temporary”

Another problem would appear to be that you’re passing a size parameter to OS_File(10) not an end address to OS_File(10). I’d change

80 SYS "OS_File",10,file$,type$,0,at%,size%

80 SYS "OS_File",10,file$,type%,0,temp%,temp%+size%

Why particularly?

Just the whole idea of using memory your program hasn’t explicitly allocated and therefore doesn’t have control over.

You’re right that it’s never going to change now, there will have to be backward compatible versions of BASIC, even if newer ones allow for, say, practically unlimited length strings.

It’s not the sort of thing anyone should be exposing to novice (apologies, Graham if you’re not) programmers, imo.

I really think that no-one should be advocating the use of undocumented things. No-one.

Of course, now it’s open source, and so is the documentation, it could be documented.

That’s me told, then. ;-(

I will accept ‘advocating’ and not do it again. ;-)

It is documented – I did it in my StrongHelp BASIC manual many, many moons ago and we all now have access to the source code. Does that count?

Where would we be if no-one ever poked around to exploit things? I think Reporter would be less handy if it did not, for instance.

What about the use of END (FSA) I mentioned? That is officially documented, but you have to know how the BASIC heap works to avoid pitfalls.

How about the 32k RISC OS scrap space at &4000? That is obscure, but documented.

OK, the best practice is to DIM LOCAL usually, and there is oodles of memory these days, but my inclination is to save where I can, so indulge me. ;-)

That’s me told, then. ;-(

All for the want of around five instructions to make your own RMA claim…

but it has been fixed in BASIC for nearly 40 years and unless someone at ROOL decides to make fundamental change for no reason, it will stay that way.

What, like the VDU workspace that nemo was getting upset about just the other day?

it could be documented.

Wrong answer.
The correct answer is to expose an API to obtain the information. Otherwise it risks stuff being immovable in the future.

Where would we be if no-one ever poked around to exploit things?

I think the storm in the teacup is not so much that you’re poking around (let’s face it, us programmers, we’ve all done it at some point), but that it was given as an example of “the way to do it”.

How about the 32k RISC OS scrap space at &4000? That is obscure, but documented.

If I recall, it is documented in the context of “don’t rely on this as FileSwitch may well jump up and down on top of you”.

That free for all workspace is an awful hack due to the lack of available memory pages back in the early days (my version of Arthur 0.30 treats the machine as having half a megabyte of 32K pages!).
These days, best to quietly retire it and mark the memory range as inexistent.

That free for all workspace is an awful hack due to the lack of available memory pages back in the early days

Actually it was due to the largest page size on Archimedes systems being 32KB, so we had to reserve 32KB below the application space for zero page stuff even when the page size was smaller for lower memory systems. On the grounds that we couldn’t immediately find anything worthwhile to occupy the upper 16KB of that space, several of us started to use it as ScratchSpace – isn’t there a comment in the kernel header saying that your use of it needed to be documented there?

I think the storm in the teacup is not so much that you’re poking around […], but that it was given as an example of “the way to do it”.

To return a BASIC string I think I would do […] This uses the BASIC INPUT buffer, but you could use your own block%.

Put an emphasis on “I” and I think I am covered. ;-)

All for the want of around five instructions to make your own RMA claim

You are surely not advocating using the RMA in BASIC for such a purpose? Now that is really not something you should be giving as an example of “the way to do it” to a beginner. ;-)

Here is the ‘proper’ heirarchy as I see it:

• DIM a fixed block
• DIM LOCAL a temporary block
• Claim from a heap created above HIMEM for a flexible block
• Claim a dynamic area if application space is too small

Is that about right?

But that is boring when you can claim flexible memory from the String Allocation Table (SAT).

WOW, that got out of hand, LOL

Thank you Stuart, I am passing “&FFF” in the type$ so I was thinking that would work. I will change the temp%+size% as I see now that is not correct.

Steve, I am no wiser where I have gone wrong, I have a DIM temp% 10000 that I thought was my buffer to put the text in and the at% was the returned position of the text in my buffer. Am I not understanding how this works and where am I going wrong.

The text I am editing is several thousand bytes long.

Thank you.

Problem solved, thanks for the help, I just need to work out how to do the rest of the project now.

using the RMA in BASIC for such a purpose?

I was thinking about Basalt. It’s a module.

In BASIC, what’s wrong with DIM meh% <number> ?

Edit, deleted some stuff:

Problem solved, thanks for the help

Wrote that while I was writing mine. No big. Glad you got it sorted.