Error trapping in AppBasic

I need to add an error trapping routine to an AppBasic program called !Writable

Using:

IF Text$ = “0” THEN PROCUtils_Alert_0("_TaskName) will display a warning window reporting Writable when O is typed into a Writable icon. This is as expected.

If I add “Err_Test:This is a test error” without quotes to the Messages file and change PROCUtils_Alert_0(“Err_Test”) I get:

Message token Err_Test not found in UTILS>LIBRARY but why?

It should work. Check that there’s no typos in there, eg Err_Text instead of Err_Test. Make sure the line in the messages file is terminated with a newline.

Is there a place were we can put calls to procedures that will be repeated (the calls) automatically every x seconds?

The easiest way would be to add a null event handler, ‘handlers’ icon → Wimp → General → Null event. Then use Wimp_PollIdle with a suitable delay.

You can force the use of Wimp_PollIdle by calling PROCUtils_PollIdleOn and PROCUtils_SetPollIdleTime in your Initial event handler. In the Null event handler you call PROCUtils_IncrementPollIdleTime(x) to set the next poll time.

Make sure the line in the messages file is terminated with a newline.

That has caught me out in the past. It is very easy to add a new token to the end of the Messages file and forget to press Return before saving.

Is there a place were we can put calls to procedures that will be repeated (the calls) automatically every x seconds?

The easiest way would be to add a null event handler,

The only official way, I think. However, you could use my Call module. This sends the task timed Wimp messages, which can be dealt with by AppBasic in the normal way. It uses SWIs OS_CallAfter and OS_CallEvery and this might not be an appropriate use for them. I am ambivalent and happy to set up a Wimp_PollIdle event timer as an alternative.

Both good solutions. Thanks!

Nota: what could be very cool, as on RealBasic, is a gadget for Toolbox that would fire an event every xxx sec. A sprite/2DSurface would be great too (but not essential).

Done by JF years ago:

http://www.riscos.com/support/developers/riscos6/toolbox/toolboxtimers.html

A black hole as far as RO5 is concerned, I’m afraid. ;-(

Great, but it needs to change the Toolbox itself. My idea is (probably) simpler: a gadget that fires en event every xxxx s. So it’s not a change of the Toolbox, but ‘simply’ a new gadget. Toolbox could be used for a lot of new cases (timer, serversocket, taskwindow,etc.). In fact, everything that fires an event. I should really learn to make toolbox gadgets :)

Steve, since you’re here, I have a question a bit of topic (but still linked to AppBasic). When I link a sprite to a gadget, can I modify it from my program? The idea would be to use it as a surface for graphics, and to write to it with classic redirection call. I’m not sure if it’s a good idea (or if I’m clear).

What is the difference between a null event every 50cs and a toolbox event every 50cs?

When I link a sprite to a gadget, can I modify it from my program? The idea would be to use it as a surface for graphics, and to write to it with classic redirection call.

That terminology is a bit confusing. Some gadgets – which are composite items – involve sprites. For some of those gadgets a sprite name is an attribute, which can be changed as part of the Toolbox. You can decompose all gadgets into their seperate icons and hence operate on them in the Wimp. So I expect that you could redirect to such a sprite and I have thought about it, but never done it. The Button gadget type would be the likely candidate.

It would be far more in the spirit of the Toolbox to invent a new gadget that did this.

What is the difference between a null event every 50cs and a toolbox event every 50cs?

Not a lot. But, if I understand Toolbox timers, they are more flexible than that. Especially, they return the object and gadget ids. On the other hand, I have never used any of the wonderful improvements to the Toolbox that JF made, because they are only for RO4/6. ;-(

When I link a sprite to a gadget, can I modify it from my program?

The Button gadget type would be the likely candidate.

Agreed. Some objects (draw file, jpeg) don’t even need a sprite. You can plot them directly using the coordinates of the button gadget to work where to plot and what scale factors to use.

It would be far more in the spirit of the Toolbox to invent a new gadget that did this.

JF already did that too, as I’m sure you’ll know. :-)

A black hole as far as RO5 is concerned, I’m afraid. ;-(

It’s indeed a gap in the RO5 armoury but the black hole (lack of vision) is elsewhere IMO. Very frustrating. :-(

According to the riscos 6 documentation the timers are an extension to the gadget library which is used to write gadgets. It also points out:

Although applications can use Toolbox Timers it is recommended that they perform their own timing operations as this will be more efficient than the messaging method used by Toolbox.

Some objects (draw file, jpeg) don’t even need a sprite.

I was thinking of redirected VDU output. I am not sure what David had in mind.

JF already did that too, as I’m sure you’ll know. :-)

I assume you are referring to the ImageFile gadget, but that was tightly connected to the other changes to the OS.

Although applications can use Toolbox Timers it is recommended that they perform their own timing operations …

I read that as advice not to use TB timers for general application timing. Emulating what TB timers could do using Wimp_PollIdle would require more thought and code and not work as well. There is some background at:

http://gerph.org/riscos/ramble/toolbox-gadgetfeatures.html#Gadgettimers

Anyway, this is all water under the bridge now.

Yes it is academic but interesting all the same. I still don’t see how it helps applications.

If I want to create an animated gadget in an application – as opposed to inside a toolbox module – I can only be informed of timed events through wimp poll. Adding a new message or event telling you that a timer has timed out just changes the priority of the notification. If you want the timed events at lowest priority – which would be the case for most animated icons – then you want wimp_poll/poll_idle don’t you? Your application can just dynamically change the return time from poll idle to return when the first time in a sorted list of timed functions needs triggering. You don’t need to be told the window/component because the handle to your private data that you pass when you register the timed function would contain that info.

If you replace that with an event which tells you the window and component you need a wimp poll for every event triggered at a particular time and still have to go through the list of windowid/componentid pairs to find the function in your application that the event triggers.

If this is meant for application space then I’m obviously missing something – JF wouldn’t do this for nothing. It would be interesting to see a working example/api documentation to see what problem it solves

It would be interesting to see a working example/api documentation to see what problem it solves

Did you read the rambles? JF shows a couple of demonstations of what might be done, with gadgets that act on timed events but do not require any response from the application.

I agree that, superficially, returning periodic events for the application to deal with, even if the gadget information is supplied, does not seem like a great advantage, but I am not sure there is enough detail to judge what TB timers might be capable of. David made a comparison with RealBasic. What can that do?

If you want the timed events at lowest priority – which would be the case for most animated icons – then you want wimp_poll/poll_idle don’t you?

I stand to be corrected, but I think Wimp messages take priority over Wimp events.

What is the difference between a null event every 50cs and a toolbox event every 50cs?

For AppBasic or other similar RAD tools? Simplicity.
But yes, I agree, it’s redundant with existing features.

It would be far more in the spirit of the Toolbox to invent a new gadget that did this.

I understand, and I agree too :)

Some objects (draw file, jpeg) don’t even need a sprite. You can plot them directly using the coordinates of the button gadget to work where to plot and what scale factors to use.

I know… I tried AppBasic a few days ago. Very cool product. I hope it’ll be Open Source or updated soon. Graphics were a problem for the conversion of the Chapeau benchmark, were several seconds are needed to generate the graphic. I’m not on GUI things, but I remembered that sprite indirection is a solution. Need to dig in PRM to define Sprite, print to it, when to manage the refreshes. Good solution would be a toolbox component. You put it in a window, then you use a simple command to say “print inside it”, then AppBasic will manage all refresh problems.

I was thinking of redirected VDU output. I am not sure what David had in mind.

Redirection of VDU output :)

It would be interesting to see a working example/api documentation to see what problem it solves

I don’t think it solves problems. It is just potentially simpler to exploit. With the same code used for the management of other gadgets events.
RB/Xojo is really an example of what can be done in the GUI world. With it, you can make a GUI app with almost no learning step from CLI software.
AppBasic seems to be a step in the right direction, but many new things could be included inside it to make things become even easier to use.

And if it’s easier, will have more applications.

What can that do?

In the graphic designer → put a timer → set it to ‘once’ or ‘repeat’ → ask to call a function. No code. Problem of management of timer events solved.
The same for socket → put a socket server → it will call a function when data is available. Nothing else to do.

Of course you can make it by hand in the event manager. The good point is that in RB there is no event manager, no skeleton for you app, just the code linked to each possible event. For example, on a change to ‘writablebox’ I can call the function VAT: writablebox2.text=writable.box.text*1,20. Application done, for a lower price. Customer happy. More business. Very good for all of us :)

Did you read the rambles? JF shows a couple of demonstations of what might be done, with gadgets that act on timed events but do not require any response from the application.

Yes I did and as you say the examples were for animated gadgets which don’t inform the application ie the application has no part in making them work dynamically it’s all done in the gadget module.

I don’t think it solves problems.

:-) in my simplified view of the world all functions are solutions to problems. If there is a function in a library that I don’t understand I tend to think what problem was the author trying to solve. In the case of a timed event from the toolbox for you to modify an animated gadget in application space I just see it as a duplication of wimp_poll_idle and don’t see how it makes the programming of an application space animated sprite any easier.

ask to call a function

Thats the bit that is no more difficult now than it would be if you have a toolbox timer event you still have to write the code in application space to map the event to a function.

I think Wimp messages take priority over Wimp events

Messages are just wimp events. Pollword_NonZero has the highest priority followed by message events then wimp_redraw_request I forget the rest but the Null event is called when there are no other events pending. So too many messages can stop the desktop as you don’t get mouse clicks or window redraws acted on until there are no messages to send.

Thats the bit that is no more difficult now than it would be if you have a toolbox timer event you still have to write the code in application space to map the event to a function.

Yep, but AppBasic manage events coming from toolbox components.

This question has generated a lot more interest than I expected.

Make sure the line in the messages file is terminated with a newline.

You hit the nail on the head Fred – lines must end in carriage return in Messages files and confirmed by Steve.

How stupid I am :-(( I knew it had to be something like this. I did get it to work one time but could not understand why. Isn’t it simple when you know. Using a Messages file is an excellent way to display errors and keeps the basic code cleaner.

Many thanks for your helpful responses.