Wimp_ReportError enhancements

Two suggestions that probably aren’t that hard to implement (<cough!> famous last words…).

In this day and age, some white-space in a message box or error report helps to make messages clearer and less squished-up.

So my first suggestion is to permit newlines in messages. Because control codes don’t pass the error messages, I would suggest the sequence " "+CHR$(127) be used (actually, CHR$127 for the newline). This is because it, with a leading space, will pass transparently on older systems (just tried). Thus, given that the backspace is unlikely to appear in a real message, a simple search and replace for 127→newline would make this work.

My second suggestion is to have an override bit to switch alignment to the left (it looks more professional). Possibly also a bit to align to the top as well. This will allow messages without the default centred style. And without the flags (or a system that doesn’t support them), it’ll just revert to traditional style.

I hope the appropriate person will consider these enhancements. I believe that these simple modifications will allow for clearer messages and more professional looking results.

Where would the switch for alignment live? Although I agree left-aligned looks more sensible, it’d be awful to have a conflicting mix of them in the UI, if the flag was left up to the programmer.

(The CHR$127 → “\n” replace wouldn’t quite work – you’d have to remove the space too (if still centre aligned) to avoid odd looking offsets when the words wrapped)

Where would the switch for alignment live?

It should be a global switch, (controlled as part of a future theme system.)

I agree that the addition of white space would make errors clearer to understand.

you’d have to remove the space too (if still centre aligned)

How does the current centre alignment work? Aren’t trailing spaces stripped?

Where would the switch for alignment live?

Either in the Wimp_ReportError flags, or as part of a global setting as suggested by Jess.

it’d be awful to have a conflicting mix of them in the UI, if the flag was left up to the programmer.

The thing is, some messages might look better formatted centrally – consider “Disc not formatted” or some other short message.

Therefore, maybe the alternative, if we pick left-aligned then a flag to force centred? I think both would have their place.
[although, if not, left-aligned would be the better option – the centred stuff hasn’t changed since Arthur!]

(The CHR$127 → “\n” replace wouldn’t quite work – you’d have to remove the space too (if still centre aligned) to avoid odd looking offsets when the words wrapped)

Good point. I originally thought up the space so it would revert safely on older systems (instead of: “There are zombies. Lots of zombies.Would you like to panic?”). I’ll need to fiddle around with some example texts to see if things look acceptable with the additional space – I don’t think the impact would be that great in an outline font…

Wimp_ReportError is single-tasking and will hold up the desktop. I am with those that say it should be deprecated. I suggest that no effort whatever should go into changing it. Any messages should be brief and diagnostic, essentially reporting a failure of the program.

I will just note that Basalt does provide WIMP REPORT and WIMP ERROR, but I would only ever use them during the initialisation of an application, before entering a Wimp_Poll loop.

Wimp_ReportError is single-tasking and will hold up the desktop. I am with those that say it should be deprecated. I suggest that no effort whatever should go into changing it.

Kindly point to a system-provided alternative.

Oh, wait, there isn’t one. We either have to use some sort of library that provides a multitasking error box, or write our own. Why? Why can’t a sane/safe way to report an error be something the operating system can cater for? Well, at the moment it single-tasks. Not perfect, and I’m sure somebody will look at alternatives. It’s just there’s a lot of stuff that is probably judged as more important. A RaspberryPi port, perhaps?

Plus we just have to remember that due to our heritage, some things tie up the system awhile (printing, for instance).

You know, this is a lot like those who slam Flash for all it sucks at and all their misconceptions without being able to point to a viable alternative.

It’s the same here.

When the Wimp is able to provide a multitasking error box, then we can talk about deprecating Wimp_ReportError.

Toolbox Quit: a system-provided alternative

Yes, I know, it is not universally available, but that was not the question. ;-)

Why can’t a sane/safe way to report an error be something the operating system can cater for?

It could, and should, but it doesn’t, so:

We either have to use some sort of library that provides a multitasking error box, or write our own.

And that is it, in a nutshell.

I recognise that this is a losing position, but I still stand by the need not to divert effort into minor improvements of Wimp_ReportError.

Even when we get a multitasking error box, I would like it to confine the pointer to it’s window. Apart from stopping the multitasking, I liked that an error got the user’s undivided attention by caging in the pointer.

The text in the middle of a Wimp error box is actually just a standard multi-line text icon. The implementation is actually kept as simple as possible, with few external dependencies, and trying not to use any extra memory – after all, the error box needs to work when you’re out of memory: the last thing you want is an error to happen while you’re drawing the error box.

Because it’s just a set of standard icons, it’s actually fairly easy to “theme” on a global basis, by installing different templates. In fact, the NC and STB versions of RISC OS did change the layout of error boxes quite a bit, to suit their rather different-looking user interfaces. Changing the alignment would simply be a case of changing the icon flags for the central icon. Though personally I think it looks very odd when left-aligned…

The other implication of the fact that it’s a multi-line icon is that it would be just as easy to add the line-break feature to icons in general as it would be to restrict it to error boxes. The greatest challenge, as you have identified, is making it degrade nicely on older systems, otherwise very few authors will use it. Well done for spotting the CHR$127 behaviour, but I think I’d prefer something else: for one thing, it’s not extensible (if someone wanted to be able to add other types of markup in future) and for another, this sort of text should be ultimately sourced from a Messages file to enable internationalisation, and I expect there are probably text editors out there that wouldn’t like having CHR$127 in the middle of the text.

Regarding the blocking nature of Wimp_ReportError: it’s not that unusual on other OSes for calls to block the execution of the current thread of execution – the only difference with RISC OS is that it’s cooperatively multitasked, which means that this blocks all other tasks as well. I think it’s really this latter effect that irritates people, rather than the fact that you can’t do anything with the task that’s reporting the error. Having other tasks be blocked as well isn’t going to change unless/until we get preemptive multitasking.

The thing is, from the application author’s point of view, a blocking call is the only sensible way to deal with unexpected errors – if you weren’t expecting it, then by definition it’s impossible to guard against it happening again as soon as you yield execution again, which could lead to an infinite number of error boxes being opened – definitely not an improvement on the status quo!

By contrast, I would encourage application authors not to use Wimp_ReportError for user dialogues that happen in normal execution, because it’s not very friendly to the user. If there’s a general need for something like a multi-tasking version of an error box, one could relatively easily be based on the Toolbox’s Discard/Cancel/Save object.

Changing the alignment would simply be a case of changing the icon flags for the central icon.

Can you do that now? My PRM and SH manual say that a multi-line icon must be centered both vertically and horizontally.

… this blocks all other tasks as well. I think it’s really this latter effect that irritates people

This has been discussed and argued over for at least 20 years. The examplar case is a machine running a server of some kind that has a another application generate a Wimp error and everything grinds to a halt. I know that could happen with the Level4 econet server. I cannot remember specifics, but ISTR that there have been attempts to provide multitasking error boxes before, and Wimp_Error monitors to provide an escape route.

Having other tasks be blocked as well isn’t going to change unless/until we get preemptive multitasking.

I am sure there are many ways to do multi-tasking error reports without a pre-emptive OS, think of Throwback and Reporter. I can conceive of the OS running a dedicated error reporting application that waits for an error message to display, cf Help. You will still need a single-tasking fallback, of course.

There’s MultiError – it’s a partial solution. And previous discussion of it in the ROOL forums here.

My PRM and SH manual say that a multi-line icon must be centered both vertically and horizontally.

It still seems to override the H/V centred flags and force itself to be centred. Maybe a future version…?

This has been discussed and argued over for at least 20 years.

Indeed it has.

The examplar case is a machine running a server of some kind that has a another application generate a Wimp error and everything grinds to a halt.

Which is why my BBS used the NoError module, that would trap the error, report what it said, and “okay” it after a couple of seconds.

I am sure there are many ways to do multi-tasking error reports without a pre-emptive OS

Agreed. The main thing is that we need to consider how to handle other application activities (window redraws, for instance) during the time the error is being displayed. This can be complicated if it was the redraw itself that failed!

Having said that – it seems a fair few apps on XP that report using MessageBox work by simply blocking the app. Windows may or may not be redrawn (depends if autoredraw I think), you can’t minimise or move them, every click in the app that isn’t the MessageBox makes a “bing!”, as if to say “eyeball the message, dumbass”.

[interesting aside: Yes/No are the RISC OS 2 way around in XP]

Perhaps such an approach would work with RISC OS, to continue the multitasker during an error, but simply block the offending application. Until such time as the user dismisses the error message, the application is trapped by the Wimp only as far as to detect clicks and bring the message to the front with and equally patronising beep. It won’t be polled.
The difference? Other stuff keeps on running.

1. DEL is an abomination and should not be used. How do you type it in?! Use TAB instead (and there is some precedent)
2. I’ve implemented a local-task-only blocking error display before, but there are unusual repercussions that aren’t immediately obvious:

If a task is blocked by its error window but others can continue, then the blocked task (or some entity on its behalf) will continue to receive messages which must be dealt with to some extent.

For example, if the user attempts to move a window belonging to the task displaying the error window, what happens? Is that ignored (hence preventing the user accessing what they were trying to – they do know best you know)? Or does the entity move the window on the the blocked task’s behalf? The problem with that approach is that multi-pane windows will usually break into pieces in the process.

Ignoring other desktop messages will have (potentially) surprising results – certain protocols will break (desktop save and taskwindow for example). New copies of the same program could be run by the Filer when the original doesn’t respond, possibly resulting in multiple copies of a program that normally prevents multiple invocation.

etc etc. This is a simpler problem than the cooperative multitasking problem, but is related.

DEL is an abomination and should not be used. How do you type it in?! Use TAB instead (and there is some precedent)

Really? There is precedent? I just tried, and Tab finishes the message, so a message using Tab to indicate a linebreak would not be backwardly compatible. [do you not think I tried that?]

As for typing it in – CHR$(127) or \x7F depending on language. It’s the only SAFE way, for using Tab characters in an editor may be stripped out on a whim (for example, all of my editors replace tabs with spaces as it annoys the hell out of me when a tab is 2, 4, 8 characters with little standardisation – at least 1 space is 1 space).

If a task is blocked by its error window but others can continue, then the blocked task (or some entity on its behalf) will continue to receive messages which must be dealt with to some extent.

Certainly. I thought about this too. We will have to accept that the Wimp will do what the Wimp can do (which may fail for panes, as you point out) but that many limitations exist. The solution is either to reimplement how the Wimp works, or to put up with a number of limitations.

I will point out, on XP, I have seen “maximised” tasks with an error on-screen refusing to budge. Pretty much the only way to get them off-screen is to click the “Show desktop” quick-link (if you have it) which removes ALL windows from screen. Then it is 50-50 as to whether you’ll ever see the error box again (some programs reappear with the error first, then the frozen window on top, ho ho).

For example, if the user attempts to move a window belonging to the task displaying the error window, what happens?

Like Windows, it probably ought to “bing!” and pop the error box to the top for any action the Wimp cannot handle by ITSELF (which means move/resize/stack-order-change okay, but don’t expect redraws). The Wimp should refuse to allow the window to be closed. Once the error is dismissed, a task’s open windows should get a WindowOpen message to get it up to date.

The problem with that approach is that multi-pane windows will usually break into pieces in the process.

Thought of that too. The answer is “too bad”. Sorry, but there’s only so much we can do without drastic changes. It might be possible for more association to be remembered and auto-handled if nested windows are in use; but for stuff like !Draw’s toolbar, too bad.

Let’s face it, the four criteria we are working to here would be:

1. Errors no longer tie up the system.
2. The solution is provided by the OS, not every program for itself.
3. Must be fairly simple to implement. Rewriting the Wimp is not an option!
4. Needs to be backwardly compatible.

I accept that it is not an ideal solution, but then neither is a system freeze while a mediocre message (“can’t do blah”) is displayed.

Those buttons should be “Panic” and “Keep calm”. Won’t somebody think of the Style Guide?!

;-)

(BTW, my 2p on aesthetics – left aligned is interesting, but balance the white space. Too much of a good thing in the proposed screenshots, especially for the line break between the two pieces of text).

There is precedent? I just tried, and Tab finishes the message

Certainly there’s precedent (checks)… in things I wrote (checks further)… that rely on Tab terminating the text. OK, TAB (on its own) was a bad idea.

so a message using Tab to indicate a linebreak would not be backwardly compatible. [do you not think I tried that?]

I didn’t think about you at all as it happens. Mea culpa. However, the backwards-compatible thing is a problem as whatever you stick in the string can be visible on older Wimps. Character 127 has special meaning at some times, but is an ordinary visible character as far as fonts are concerned. Many don’t have anything defined for that codepoint. Some do.

It’s the only SAFE way

There are many many safer ways. One technique I’ve used in the past is to employ hard spaces – the only real spaces are the line breaks. In ye olden days this was trivial thanks to the monospaced BFont, but a more elegant backwards-compatible solution is to preformat the string to fit the desired icon, swapping 32<>160 as required. This is entirely backwards compatible and requires no change to the Wimp at all being done within the application.

I could even knock up a little module to do so if you like.

We will have to accept that the Wimp will do what the Wimp can do (which may fail for panes, as you point out) but that many limitations exist. The solution is either to reimplement how the Wimp works, or to put up with a number of limitations.

Or to do something else. The method I previously used was to disappear all the windows belonging to the blocked task (by closing them in a filter so the task never heard about it) and restore them later. This avoids the moving and redrawing difficulties.

I will point out, on XP, I have seen “maximised” tasks with an error on-screen refusing to budge.

Windows is hindered by the same co-operative protocols that RISC OS is limited by (though they are well hidden these days). However, as you say, error conditions or other interruptions like Visual Studio breakpoints can stall Windows. However, that’s not an excuse for not dealing with the problem under RISC OS (where it is much worse!).

Anyway, this has all been discussed before, here: http://www.riscosopen.org/forum/forums/2/topics/31

> The problem with that approach is that multi-pane windows will usually break into pieces in the process.
Thought of that too. The answer is “too bad”. Sorry, but there’s only so much we can do without drastic changes. It might be possible for more association to be remembered and auto-handled if nested windows are in use; but for stuff like !Draw’s toolbar, too bad.

If nested windows are employed then that problem doesn’t exist, but nested windows aren’t usually employed because of backwards compatibility. Having paned windows break apart is not acceptable (and certainly isn’t limited to Draw losing its toolbar).

I accept that it is not an ideal solution, but then neither is a system freeze while a mediocre message (“can’t do blah”) is displayed.

1. We must do something
2. This is something!
3. Therefore we must do this?

I’m with you up to step 3.

There are many many safer ways. One technique I’ve used in the past is to employ hard spaces – the only real spaces are the line breaks. In ye olden days this was trivial thanks to the monospaced BFont, but a more elegant backwards-compatible solution is to preformat the string to fit the desired icon, swapping 32<>160 as required. This is entirely backwards compatible and requires no change to the Wimp at all being done within the application. I could even knock up a little module to do so if you like.

Easily done with Basalt:

report$=“There are zombies. Lots of zombies”+CHR13+"Do you wish to panic?"
SWAP$ report$,32,160;13,32
WIMP REPORT report$,4 TO button%

I accept that it is not an ideal solution, but then neither is a system freeze while a mediocre message (“can’t do blah”) is displayed.

IMHO a message like that should be handled by the application in a multi-tasking way. It is a cop-out by the programmer if a Wimp_Error box is used. I have done it, but I have seen the light.

SWAP$ report$,32,160;13,32

It would be nice if it were that simple (and elegant!), but one would have to leave some spaces in to allow paragraphs to wrap correctly (in general).

But yes, that’s the idea, and it would work in any version of RO.

That is how it is using Basalt. ;-)

That line swaps spaces (32) for hard spaces (160) and CR (13) for space. AFAIK Basalt does work with any version of RO, but it is only for BASIC and does not help with other languages.

Because it was easy and fun, I have put that functionality directly into WIMP REPORT. If it is flagged, it swaps hard and normal spaces, which seems to be a simple way to do things.

You miss my point Steve – if the text is intended to consist of two paragraphs separated by a newline then the above is probably not enough (I haven’t checked, but I have imagined).

Replacing all the original spaces with hard spaces turns the two paragraphs into extremely long single words, and the Wimp is unlikely to be smart enough to break lines at hard spaces when it can’t find a space to wrap at – see what I mean?

What I meant to suggest is to take account of the width of the icon, then format the text to fit by replacing all spaces by hard spaces except those required to ensure word-wrapping within a paragraph.

Note that this approach isn’t perfect, as it can only simulate line breaks for paragraphs that are longer than half the width of the icon, if you see what I mean.

Replacing all the original spaces with hard spaces turns the two paragraphs into extremely long single words,

Indeed, hence my <127><32> suggestion at, and only at, the point of a desired linebreak. Yes, it could be that <127> might have something mapped in at that code point, but you’d need to look damn hard in the sources to see if that matters (in other words, if it is either ignored by the Wimp or handled as a VDU backspace then it won’t get as far as being a “maybe this font will show something”).

Actually, in thinking, I would say “<32><127>” is better, so in worst case scenario, you’d see two words with no space. Though, note AGAIN, it is Wimp_ReportError so the only text I have yet to do is check its behaviour with the system font enabled.

I don’t imagine it would play too much havoc with line formatting – the ReportError box isn’t smart enough to resize itself, so there’s only so many linebreaks possible.

Is there a specific reason why an auto-wrapped icon self-centres? Were Acorn just being lazy here? It seems a bit daft to enforce this when there are flags to indicate this behaviour. Personally, I think we need a new “auto-wrapped” icon that doesn’t. With a new indirection operator (for I suspect ‘fixing’ the current one may mess up a lot of stuff built with this expectation in mind).

Hehehe… I wanna have a hack around with the Wimp (well, start by wallpapering my room with printouts of the code!) but as I’m now working daytime hours (thank god!), my pay is less. One day I’ll get that compiler/source bundle. Maybe for Christmas, eh?
Hmmm, you know, I feel like a character in a horror flick where I’m running my heart out and the bad guy is sorta shuffling, and he’s gaining on me¹… (^_^)

¹ I’m thinking of Dr. Giggles, but there are many examples.

You miss my point Steve …

I do understand your point about fully formatting the text in the Wimp_ReportError text icon, but I was thinking of a solution to a simpler problem, one that could be used by a programmer to split text without too much trouble.

Pretty well all the messages I have seen have been short. Assuming a 12pt desktop font, a programmer can construct the string to appear in the desired way, using padding if necessary. A form of automatic formatting is much more fundamental, and I do not think Wimp_ReportError deserves that attention.