Writable Icons in Windows

While investigating something else, I came across the following anomalies associated with the handling of Writable Icons…

1. The 1992 RISC OS 3 PRM says on page 3-104, when describing the actions for the K validation command, that the action taken for Kr is:

- If the icon is not the last icon in the window, pressing Return in the icon will move the caret to the beginning of the next writable icon in the window.
- If the icon is the last writable icon in the window then Return (code 13) will be passed to the application.

The current online ROOL PRM is in agreement, although is more cryptic, as it just says:
- Return moves caret to next writable icon

From my observations, the current Wimp reacts as the PRM states when Return is pressed in a Writable icon which includes Ktar validation, except that it puts the caret at the end. No key is passed back to the application unless it is in the last writable icon. If the validation includes Ktarn, then all keys are passed back.

2. The new Style Guide says on page 109 for Writable icons in Dialogue boxes that they should have Validation strings of “Ktar;Pptr_write”, and that pressing Return after giving input to a writable field should activate the default action button, not move the caret to the next field.

The Style Guide also says on page 53 that when the Return key is pressed, an application should implement the current settings and remove the dialogue from the screen.

3. The PRM also claims that pressing Tab/Shift-Tab will move to the beginning if the next/previous writable icon. However, the Style Guide says that it should move to the end of the text – which agrees with what happens in practice – identical to what is happens with the Ka action and the down/up keys.

Note that the terms ‘next’, ‘previous’, first’ and ‘last’ refer to the sequence of icon numbers, and not their appearance in the dialogue, although I have found nowhere that is defined.

4. In August 2014 RISC_OSLib v5.83 was changed from using a default of Kar to Ktar, which makes dialogues without any K validation behave exactly as defined in the PRM for Ktar.

Thus to me the Style Guide and PRMs seem to be contradicting each other, but the PRMs agree with what happens currently in the native Wimp (except for the caret position), and using RISC_OSLib. Is there a ‘bug’ in the Style Guide or elsewhere?

I believe that the Style Guide guidance is correct, but that the example validation string is a typo. That is, pressing Return should activate the default action button whenever pressed, and Tab should be used to navigate between writable fields. The correct validation string, despite the documentation, would therefore be Kta;Pptr_write

That system certainly makes logical sense to me, at any rate.

Kta;Pptr_write

Sorry, but that does not make sense to me! It would mean the return key is never passed back to the application. And why was RISC_OSLib changed to act as if Ktar was always specified for writable icons?

Sorry, but that does not make sense to me! It would mean the return key is never passed back to the application.

Surely Kta does exactly what the Style Guide requires: Tab and arrow keys are handled by the Wimp and not seen by the application, whilst Return isn’t claimed and is passed on to the keypress handler?

This is no answer, but I recollect that this discrepancy has been discussed before, here and elsewhere, and going back some while.

The Toolbox seems to take charge of this. The pointer is automatically changed. [Shift]-Tab and Up/Down move between writeable gadgets, but these have to be specified. Return always does the default action.

This complies with the Style Guide, I think.

It would mean the return key is never passed back to the application.

As Steve says, the K command doesn’t pass keypresses to application, it handles them itself. So omitting it gives the app the chance to respond to Return being pressed, and perform as the Style Guide recommends. In my view, the ‘r’ command should probably be considered obsolete for most purposes, a piece of RISC OS 2 behaviour that was superseded when clearly marked Default action buttons became widely used.

And why was RISC_OSLib changed to act as if Ktar was always specified for writable icons?

That I don’t know. As the other Steve says, this has been a confused topic for a while, due to incompatible guidance hanging around. I wonder if someone added the Tab behaviour without giving thought to whether the Return behaviour ought to the changed too?

The Toolbox seems to take charge of this.

I was careful not to stray into Toolbox territory … I was talking only about the Style Guide, the PRM, and the current Wimp. But I have a simple Toolbox app here that has two writable fields, and [Shift-]Tab and Up/Down have no effect – because the validation is Kn. It is not very obvious if it needs specifying in ResEd in Allowed characters: Other.

the K command doesn’t pass keypresses to application, it handles them itself.

But it certainly affects what keypresses are passed to an application, even if the Wimp handles them as well.

Surely Kta does exactly what the Style Guide requires

My current understanding is:
Kta does indeed seem to be the correct value to use to abide by the actions documented in the Style Guide: ie Tab/BackTab/Down/Up cycle through the writable icons, and Return is always passed to the application so it can simulate the default button being pressed.

Ktan may be used if the application needs to receive all keypresses made in the icon (not just Return), but note that this also includes Tab/BackTab/Down/Up as well as Return.

Ktar (as documented in the Style Guide) should not be used, as it means that the Return key is passed to the application ONLY when in the last icon. The new RO3 Style Guide is the same as the RO3 one in this area.

Ktarn should not be used, as the Wimp will move down to the next icon, although the app will get the Return and should then close the window.

Which means that the ‘r’ action is (as Chris suggested) redundant.

The RO3 PRM is wrong on page 3-104 when it refers to moving to the beginning of a writable icon, because it always moves to the end.

Without a K command, Tab/BackTab/Down/Up and Return are passed to the application, with no movement. This is not Style Guide compliant, and cannot be specified any other way.

I have not yet checked the Toolbox and RISC_OSLib.

I was careful not to stray into Toolbox territory …

I just wanted to point out that there is another indication that the style guide should be followed.

[Shift-]Tab and Up/Down have no effect – because the validation is Kn.

As I said: “The Toolbox seems to take charge of this” – it is actioning the keypresses itself. You have to specify the previous and next gadgets to move to. The order of the actual icons is not important, so this is not a Wimp action.

Stirring the mud a bit, are ESG group restrictions mentioned on p3-104 implemented yet? ;-)

Toolbox…

So the Toolbox does not follow the Style Guide automatically – it only enables the developer to follow the it. Just like Templates!

Stirring the mud a bit, are ESG group restrictions mentioned on p3-104 implemented yet? ;-)

No mud here … it works a treat here with Wimp 5.29. Depending where the cursor starts, all movements are confined to the ESG group. Though whether that would comply with the Style Guide is another matter!?

Though whether that would comply with the Style Guide is another matter!?

This kind of thing comes up regularly and I believe the question should be asked:

Do the general users of RO want any amendments of the material in the style guide to define the look and feel in a manner that reflects normal user expectations and if the style guide is to remain set in stone then should the various development tools be updated to prevent any non-style guide compliant implementations?
I presume ROOL have an opinion on this, but that may simply be that they will review after user comments.

No mud here … [ESG] works a treat here with Wimp 5.29.

I only asked because I have not written a Wimp program without using the Toolbox since the turn of the millenium. Before that, I had an OOP skeleton written in BASIC that mimicked the Toolbox, and even extended it beyond the Wimp. Aah, those were the days. ;-)

I take your point, that the Toolbox does not enforce the Style Guide in respect of Writeable gadgets. As for Steve’s question:

should the various development tools be updated to prevent any non-style guide compliant implementations?

I think that would be a bit draconian. It is a Guide, after all.