"First letter" shortcuts no longer work in V8 for component inputs

I was thrilled in V7 when I discoverd I could change the wire display by simply right-clicking on a component input and type “W” for “Wire display”, then either “D”, “F” or “H” for the wire style.
This (plus all the other possible shortcuts) doesn’t work here in V8.

1 Like

That was never part of the code, so it must have worked just because Windows makes it work. @curtisw is it possible that we changed something somewhere which would prevent Windows from running menus this way?

I did some googling and maybe it is the ‘mnemonics’ feature? So maybe that can be forced in the menus.

ChatGPT told me (don’t know if the advice is any good):
The behavior you’re describing in Windows software, where you can open a menu and then press keys like ‘M’ or ‘D’ to select something from the list, is part of the standard user interface design pattern known as “mnemonics” or "keyboard accelerators.

Mnemonics are shortcuts that facilitate keyboard navigation and are intended to improve accessibility and efficiency by allowing users to perform actions without relying on a mouse. In the context of Windows and many other GUI (Graphical User Interface) systems, a mnemonic is usually indicated by an underlined character in the menu item’s name. Pressing the Alt key in combination with the mnemonic letter triggers the associated action or opens a submenu.

For example, in many applications, you can press Alt to highlight the menu bar, and then pressing a specific letter (like ‘F’ for ‘File’ or ‘E’ for ‘Edit’) will open the corresponding menu. Once the menu is open, pressing another letter that corresponds to a menu item (like ‘S’ for ‘Save’) will execute that action.

This behavior is deeply integrated into the Windows operating system’s UI guidelines and is supported by its underlying APIs, such as the Win32 API for traditional desktop applications. Modern Windows applications developed with frameworks like Windows Forms, WPF (Windows Presentation Foundation), or UWP (Universal Windows Platform) also support mnemonics, with mechanisms in place for developers to define these shortcuts in their applications.

In terms of implementation, when a developer is creating a menu in a Windows application, they can specify mnemonics by prefixing the desired accelerator character with an ampersand (&) in the menu item’s text. For example, setting a menu item’s text to “&File” designates ‘F’ as the mnemonic, allowing the user to open the File menu by pressing Alt+F.

This design principle is not unique to Windows; it’s used in various operating systems and applications to support efficient keyboard navigation, adhering to the broader principles of accessibility and usability in software design.

Hi David !
How about adding some smart features to manage wire styles more easily ?
Maybe some kind of “brush” tool that one could swipe the wires with to make them faint or invisible ?
I find that I spend a considerable amount of time managing this in my definitions to prevent them from looking like, well, you know.

Hi Olivier -

Thanks, we have this on the list as RH-57216 Grasshopper: Parameter input keyboard shortcuts required enter or space to complete
-wim

@wim1 Well, it is related, but in my case, it’s not a Win vs Mac issue.
Rather, it’s a V7 vs V8 issue !

Yes -


-wim

This seems to have been fixed in the latest 8.5 Service Release.

Thank you so much! What was the key to getting it working?
@wim @DavidRutten

Hi Tuomas -

It still doesn’t work on my system and RH-57216 is still open.

It sounds like that’s a question we need to be asking you?
-wim

Yesterday, I was running the latest Rhino 8 Service Release Candidate. This morning, I installed the latest Rhino 8 Service Release. I noticed the change in the shortcuts now working, because that’s one of the first things I always try after installing a new version.

I was running Rhino 8 in .NET Framework mode, so SetDotNetRuntime was set to Framework. If I set it to .NET Core, the shortcuts fail to work. I cannot tell if running the SR Candidate in .NET Framework mode was working before this morning or not.

So definitely something to do with the .NET runtime selection.

2 Likes

I can confirm that at least one other user besides me got it working by running Rhino 8 in .NET Framework mode.

Hi.
I see this is still open. Please fix this asap, it’s a killer feature and a big step back if you can’t do it.


… what is that? Can I do that too?
There are disadvantages doing that? Why should I not do that?

Hi Riccardo -

‘SetDotNetRuntime’ is a built-in Rhino command.

If you are running a plugin that targets functions that only exist in .NET Core, that plugin will not work.
-wim

1 Like