Shortcut for "Edit/Context Menu Flyout/Divide" has no effect

Hi.

My OS: macOS Catalina, SU 2020

I declared a short cut for the command “Edit/Context Menu Flyout/Divide”.

I used a simple single key: “u”

When I mark a line, that shortcut has no effect.

I have the same problem with another context menu command:
Edit/Context Menu Flyout/Text Position/Outside End

I tried different types of shortcuts: without success.

Can someone reproduce that behaviour?

Do you know a workaround to get a working shortcut for those two commands? Thanks.

‘u’ will only set the divide going. You would still need to type 5 Enter, or whatever number you want to divide it by.

The outside end worked for me ok. I used ‘j’, for no particular reason. You do have a dimension selected at the time?

Yea, it works fine on Windows also. However as most context commands are, a single edge must be selected. When the command begins, the VCB is ready for input (ie, “Segments”,) but the mouse needs to move before the display is updated to show the dividing nodes and tooltip.

Thanks for checking it, Colin.

Did you tested it on macOS or Windows, please?

When I mark a line and press “u” and than move the mouse nothing happens.

When I mark a line and press “u” and press “5” nothing happens too.

The outside end:
Yes, I have a dimension selected. And the standard selection tool is active.

In both cases the context menu command works. But the shortcut has no effect.

I’m on Mac, and you would have had to type 5 Return, then click on the line to see that it is divided.

Now I restarted SU. Now the shortcuts work.

Thanks for your test!

One other thing I can report:
When I use the search field in “preferences > shortcuts” that does not show results for context menu commands.
For other non context menu commands the search field works fine.

They don’t show up unless you have something selected that will enable the relevant context menu.

1 Like

@Box
Thanks!

Is that behaviour intended?

Yes, because the context menus are built “on-the-fly” according to what the editing context is.

But shouldn’t preferences be completely independent of the context?

What is the advantage for the user please, when he cannot see all context menu commands in the preferences always?

They cannot be. This is not a lazy decision by Trimble, or Google before them or the @Last guys before them. It is the way that the computer programming frameworks work.

Menu commands have ID numbers that are only valid when that menu is active. So you must create the context that activates the menu, so that the Shortcuts command list can see those commands when it enumerates the list (in the dialog.)

I’m not a Mac guy, but on MS Windows the command IDs are reused for only context menu commands, during other edit contexts. There are only so many integer IDs available and this reuse keeps the count down. (Could be this is leftover from the old days of 16 bit memory spaces?)

1 Like

Thanks for the explanation! I didn’t expect such a restriction at all.

For the usability it is a disadvantage. I hope in the future the frameworks will behave different and each context menu command will have a permanent id.

Let’s hope not. Now the computer filters out irrelevant options that you don’t have to go through each time.
You only need to remember to make a selection in advance to see the other options.

1 Like

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.