Wimp_ReportError replacement

The Wimp_ReportError wiki entry states:

The use of this call should be avoided where possible, due to the non-multitasking nature of these error boxes

Excuse my ignorance, but shouldn’t that statement be removed and the Error Flags have a multi-tasking flag option added so the error handler creates a multi-tasking safe window?

Alternative is setting bit 5 (Return immedately) multi-tasking safe?

have a multi-task flag option so the error handler creates a multi-tasking safe window?

The thing is that normally an error box blocks until the user dismisses it.

There is a lot of additional work involved in making errors multitask. Effectively the rest of the application needs to be locked out in such a way that no behaviour causes changes that could affect whatever the error was about, until such time as the error is dealt with (consider “unable to save file, disc full” and while that’s on screen, trying to save again or even quit the app).

Granted, the RISC OS way of blocking the entire machine isn’t ideal, but the underlying mechanism isn’t that different to a modal messagebox in Windows (where doing anything with the rest of the app will result in Bong!).

Alternative is setting bit 5 (Return immedately) multi-tasking safe?

I believe that was added at the behest of the ADFS filer (or maybe FileSwitch?) in order that it could pop up the “Please insert disc ‘x’” message, and loop polling the drive so that it could automatically dismiss itself when the correct disc was inserted. Back in the days of the A5000, this was pretty nifty.

I thought an A5000 came with a HD, the A3xx and A30x0 machines didn’t.

There is a lot of additional work involved in making errors multitask.

Isn’t the error logging system in RO4.3x a multitasker though?
SysLog based and more concerned with putting an error into a file than blocking the GUI. Knowing the error details at a later date seems more useful than putting a blocking message on a GUI (that you might not be looking at, and probably has too little detail anyway when you are looking)

I’m pretty sure there’s a thread or two round here covering discussions of SysLog, mentions of WimpLog and other elements in the threads too.
and IIRC Julie was part way through a syslog implementation with things like network aware logging.

Isn’t the error logging system in RO4.3x a multitasker though?

Error logging on any version of RISC OS is, but that’s not at all relevant to the question here.

We’re talking about the message boxes used to report errors to the user, which are “modal” for ease of application development. That is, a developer can call Wimp_ReportError and expect it to return the user’s response immediately. To do this, the Wimp can’t poll the application at all in the background whilst the user considers their response, as the application is blocked waiting for Wimp_ReportError to return.

To make this work safely without a lot of effort, RISC OS brings the entire Wimp multitasking to a stop. This avoids awkward questions like “what happens if another application tries to send a message to a paused application”. As Rick says, fixing this is a lot of work.

The other solution is to have the box return immediately and leave the application to handle the pause until the user responds. This is how the ROM applications do it, along with many others. It is, however, a very different program structure for any question where the user has two or more options. Tasks have to be split up into self-contained chunks which can retain state across Wimp polls, and the application itself has to ensure that the user can’t re-enter anything which might affect, or be affected by, the open question. And if the question could affect screen redraw of open documents, there’s another level of fun to consider as well.

normally an error box blocks until the user dismisses it

Hence why I said “Error Flags have a multi-tasking flag option” as the app needs to support a multi-tasking style error.

consider “unable to save file, disc full”

That’s a perfect example of where non-blocking is useful as it would allow the user to do something about it before retrying.

fixing this is a lot of work.

Only if you’re trying to fix existing apps, I’m more concerned with current apps being multi-taking safe.

The other solution is to have the box return immediately and leave the application to handle the pause until the user responds

That was my first thought and why I raised the point as I feel the Wiki should possibly make it clear that setting bit 5 is the preferred method, with the app handling the consequences. An example of how that’s implemented would also be useful.

I feel the Wiki should possibly make it clear that setting bit 5 is the preferred method, with the app handling the consequences

I’m not sure it is the preferred method, though. Non-blocking error dialogues should probably match the ones defined in the Style Guide, which means not using Wimp_ReportError at all.

I thought an A5000 came with a HD

They did, but it wasn’t particularly big, and some annoying software still insisted on being run from disc.

Knowing the error details at a later date seems more useful than putting a blocking message on a GUI

That’s the idea behind my NoErrors module (around here, IIRC?). It will log the error message to DADebug, and then dismiss the error after five seconds by faking the user pressing Escape. On properly written applications, this should invoke the “safe” (or, rather, non-destructive) option.

My main machine runs a server. It’s not useful to have the entire system blocked by a message box.

which means not using Wimp_ReportError at all.

Just to toss a spanner in the works, the PRM states that the Wimp should not be reentered when the error box is open. So, really, it shouldn’t be used for any sort of multitasking.

Also, consider, what happens if you multitask with ReportError open, and something else calls ReportError…