Hide menu entry

When using Res files you have defined menu entries for menus.
Is there a way to hide entries when not used?
I mean not only gray them out but make them dissapear.

I don’t know the answer to your question, but that’s not normally how applications behave: the inactive items being greyed out can help the user understand what features are available when the circumstances are right.

(You may have good reasons to do this, of course.)

I’m not sure RISC OS understands the concept of a hidden menu entry. You’d need to use SWI Toolbox_ObjectMiscOp with method codes Menu-AddEntry & Menu_RemoveEntry to add & remove entries from your menus.

The RISC OS Style Guide states quite clearly If a menu item is not available because of the context in which the user has displayed the menu, it must be greyed out (not omitted).

I think the Res file just provides what is acceptable.

Having menus that change their ordering or positions of items is a bad user experience – it means that the automatic behaviour of ‘this menu, 3rd item down’ is not reliable. The style guide is very clear about this. Whilst it might be appropriate for a user-configurable menu (which, of course, you’d build up as needed), or a menu that is expected to show dynamic content (like a list of recent files, or the currently open documents), in general you just shouldn’t do it.

There are times when it makes sense to do this – a rarely used set of operations that can be context sensitive, or a list that changes based on the system state spring to mind. The former might be used for something like a ‘Special’ menu whose submenu options change based on the type of object selected – if a text region is selected, it offers options like spell and grammar checking; but if a graphic is selected, the options change to offer options to emboss or extrude the graphic. Not completely sure that makes sense, now I offer it as an example (such an option would have to be Selection→Special→Spell check or something…

The latter might be something like having a menu that contains a list of known discs, or configured servers, or even a dynamic list that showed you the recently selected options. These sorts of menu items are commonly used for submenus on iconbar icons, or info+menu icons in dialogue boxes. Using a recent example I’ve been working on, the Hexen front end dialogue box offers a dynamic menu that contains a list of the screen resolutions that are available. Whilst the menu is dynamic, it’s not going to change in a given invocation because the modes available on the system won’t be changing in general – actually it will change if you switch between 8 bit colour and 24 bit colour, as there are different modes available for each, but in general it’ll look the same on a given system. That means that the user experience remains the same from run to run.

It also follows that changing a menu between releases is discouraged, because it also destroys that muscle-memory and induces frustration in the user as learnt behaviour has changed. Sometimes it’s unavoidable, as that’s how it is with development. This muscle-memory and user reaction to change is also why the style guide encourages a common ordering of menus so that between applications there is a similar feel for how things work – there isn’t a jolt or a need to learn ‘in this application the thing I want is over /here/’ with each application.

You also need to remember that a menu would normally stay open if the user clicks with Adjust. If the menu needs to be changed to unhide an option because of what the user has just chosen, that could cause some difficulties.

Thanks for the feedback but there is a good reason why I would like to show that menu entry as there is no good text it could display as grayed out.
I want to implement a feature in CLFiler that would solve one problem I encountered often in RISC OS apps:
Selected items in RISC OS develope often unexpected behaviour of the app.
For example in Paint when you have multiple sprites in the sprite file and you have one of the sprites selected and then drag over another image into the sprite list then the selected sprite is replaced without warning.
This behaviour makes of course sense when you are aware that a sprite is selected but when you are not then your work of hours can go to hell by a mouse release as Paint has no undo feature…
The context related menues and function of RISC OS programs make the software more powerful but need also higher skills or knowledge of the users.

Well coming back to my “problem” with CLFiler. I want to offer an additional menu entry if in the filer folder display there are selected files but I open the menu over a file that is not part of that selection.
Often you just have an idea to do something with a file and don’t recognize that you have selected files.
So I want to show menu entry:
1. Selected files > submenu
2. Mouse hover file > submenu
So what can be a meaningfull grayed out menu entry for the “mouse hover file”? or maybe put a seperator then “-———” to not confuse users with useless text?

This behaviour makes of course sense

We’ll have to agree to disagree on that.

I feel very strongly that Paint’s behaviour here is extremely broken.

1, It’s not at all good to replace something without prompting.
2, If something is replaced, it should only be something of the same name (like the filer).
3, Given this behaviour, things should never be automatically selected.

By way of easy demonstration – create an empty sprite in Paint, then choose a number of sprites on disc. Drag those sprites into Paint at the same time.
Then marvel at the astonishing amount of wrongness you observe.

I’m not sure when it was changed, but 3.7 works as expected. And yes, I filed a bug report.

then your work of hours can go to hell by a mouse release

Which is why it’s broken…

Often you just have an idea to do something with a file and don’t recognize that you have selected files.

I’m at work so not near RISC OS, but doesn’t the Filer already handle this by changing the menu item that says something like “File ‘xyzzy’ →” to “Selection →”?

I can’t help but think that having menus behave in unexpected ways would be more likely to confuse the user.

but doesn’t the Filer already handle this by changing the menu item that says something like “File ‘xyzzy’ →” to “Selection →”?

Yes. Exactly that.
It greys out the file selection option only if you click ‘Menu’ over a different filer window, and if you click over a file in another window, it deselects the files in the first window.

Filer behaves as expected.
What, possibly erroneous, actions CLFiler makes I could not say.

For example in Paint when you have multiple sprites in the sprite file and you have one of the sprites selected and then drag over another image into the sprite list then the selected sprite is replaced without warning.

a) That’s insane behaviour. It doesn’t match with expectations. It doesn’t match with what happens if you have a selected item present and you drop a file on to a filer window. It doesn’t match with what happens if you have a selected item present in !Draw and you drop a new object on to it (not that you should use !Draw as an example of how you should do things really). It doesn’t match the behaviour if you have selected text in !Edit and you drop a file on to it. It doesn’t match with the behaviour if you drop a Res file into ResEd.

b) That doesn’t have anything to do with menus changing shape according to their context?

Well coming back to my “problem” with CLFiler. I want to offer an additional menu entry if in the filer folder display there are selected files but I open the menu over a file that is not part of that selection.

…

So what can be a meaningfull grayed out menu entry for the “mouse hover file”?

Then you’re creating a behaviour that is non-standard and different to what the user will expect. When you have a selection, you expect to operate on the selected object, using the ‘Selection’ submenu tree. That you have difficulty even describing the behaviour, and how to represent it, indicates that a user will have difficulty with the behaviour as well.

Going back to my earlier description of why you don’t want menus to have non-standard or changing behaviour, so that users don’t have a jolting experience, this holds even more strongly for a core component like the Filer. If you want special extra behaviour like this then I guess you could have it, but place it behind a configuration option and don’t make it the default, so as to allow users to transition more easily.