Simon Ayers' YouTube RISC OS programming

I came across a couple of videos on YouTube from Simon Ayers:

https://www.youtube.com/playlist?list=PLVJalZPhgpY9K4lXhrxBLNr69FOuQMMjq

Simon is a professional C++ programmer and returned to RISC OS after a long period away. He has an interesting perspective on what he found familiar and what caught him out. While it’s not a tutorial, he seems to have made good progress returning to RISC OS development and developing in C++. His (ongoing) goal: write a text editor that’s familiar to someone used to VS Code, rather than quirky RISC OS editors.

Dear Theo,
thanks for sharing and I had a look at the videos. It’s great to see people trying to learn (or re-learn) coding on RISC OS, but Simon’s video clearly show the need for proper – Coding on RISC OS Tutorials -. However still great to see that there is also more material on the internet about coding on RISC OS, in the end everything helps.

What Simon Ayers needs to look at for non-blocking error boxes in RISC OS is Adam Richardson’s MultiError application . Instead of having his own application go through the business of opening windows he should simply start up a separate wimp task, such as MultiError, to do the job. It can be used from any language that can access the commandline. See the definition of alert in lib.wimp.task in RiscLua:

local alert = \ (self, err, template)
-- use your own template maybe
  local m = 'rluabin:ME.MultiError -t %s -e "%s"\0'
-- taskhandle of ancillary task
  => sys (0x400de, m:format (template or "rluabin:ME.Template", err))
end -- function

Instead of having his own application go through the business of opening windows he should simply start up a separate wimp task

I cannot see how farming a simple error window out to a separate WIMP task with all its annoying problems (when does it stop? how does it report an error? how to kill if my own app goes down?) can be regarded as the simpler solution compared to “open a window” (which your average WIMP app will have plenty of anyway).

You may well be right. The window provided by MultiError has a button to close it, of course.