Keyboard Shortcuts continued

Thank you all for your feedback on the previous post.  I spoke to a few others offline and appreciate the responses.  A few cases were identified asking for access to specific UI items:

• Project Browser Show/Hide
• View Range

The first of these has an underlying command ID (ID_VIEW_PROJECTEXPLORER).  The second is a dialog control and lacks a top level command ID.  Its ID is: Dialog_Essentials_PlanViewRange.  In general dialog controls are accessed via tab, arrow keys and other dialog navigation methods.  In this case the control accesses an important dialog so a solution is needed.

Here are a few other dialogs accessed from dialogs:

Model Graphics:                                 Dialog_Revit_ModelGraphicsStyle
View Clipping:                                     Dialog_Revit_DepthClippingDialog

In some cases the dialog is accessible from two places, one of which is a command, and therefore keyboard accessible.

Home>Room Area>Color Schemes:     ID_SETTINGS_COLORFILLSCHEMES
View Properties:                                 Dialog_RoomAreaPlan_ColorFill

View Frame>Shadows>GD Options:    ID_GRAPHIC_DISPLAY_OPTIONS
View Properties>GD Options:              Dialog_Revit_ModelGraphicsStyle

These command IDs and control IDs can be read from in the journal files.  This is the reason why the Options Bar has never been accessible.  The implementation is an assembled strip of small dialogs thus all commands in the option bar are dialog controls.  A potential solution is to create command IDs for the ones that lack them so they can be assigned shortcuts.  This of course would be behind the scenes but I am explaining it here for the curious.

One additional question?  Is it still a requirement to have multiple shortcuts assigned to the same command?  Its possible now yet adds complexity to any design.

_erik

Comments

[iru69]

We *really* like the ability to have multiple shortcuts assigned to the same command. The reason is that we can keep all our users happy with a single shortcuts text file.

For example, to get to view properties, I like the standard VP because it's easy for me to remember, but we also have assigned PO because others like the close proximity of the keys. I can sit down at any computer and still use the shortcuts I'm familiar with while allowing others to customize what they like. So we keep all the OOTB ones and then agree as a group on alternatives as requested.

When a new release of Revit comes out, one person in the office can update the shortcuts file and distribute it rather than everyone in the office updating their own individually (and avoids the headaches of users either needing help or messing it up).

[Anthony Hauck]

I see. It would make the upgrade/Import process simpler. The existing and new file could be merged. 100% Duplicate entries could be tossed.

[Chad]

"A few cases were identified asking for access to specific UI items:
Project Browser Show/Hide"

Unless I'm missing something, this can already be done. I have mine assigned to F4.

One thing I would like to see is cascading keyboardshortcuts.txt files.
It would be good to be able to have a master office shortcuts file, and then allow the users to create their own additional shortcuts, but only as long as they don't clash with the office ones.

So the process could be to load the user file first, and then the master office file second.

[x-p]

When you load a family into a project, the dialog box that asks 'do you want to overwrite?' does not have focus. This means you can't hit return to accept it.

On the subject of dialog boxes, the new 2010 ones must be using non-standard UI code, because nvidia's nview multi-monitor tool won't pick them up and center them on the screen. Very annoying. The old-school dialogs (that still use standard windows UI components) work just fine.

If I might ramble on a bit more - this use of non-standard UI code seems to be at the root of the poor performance of the ribbon UI. Windows has very fast, built-in routines for drawing buttons and dropdowns. Revit seems to be using its own custom routines that are very very slow in comparison.

[Robert]

I like the idea of cascading shortcuts. This would make deployment and management in a large firm easier. We struggle with best approaches to deploying Revit, particularly if the keyboard shortcut file that comes with Revit is updated because of new tools or whatever. People don't want to loose their customizations, but we do need to be able to provide updates. Easier methods of customization would likely be welcomed by our user base. User's custom shortcuts should be stored as part of the user profile, that way they potentially can switch workstations too, depending on how a firm's infrastructure is configured, location should be modifiable at an ini level by IT, but probably not user.

-R

[Joel Osburn]

For us, multiple shortcuts per command is not a big deal. Cascading shortcut definition files would be great, though. After a simpler definitions file, what I'd like to see most, is direct access to a much broader set of commands, inclusive of command variants. An alternative would be to expose access to command options via the keyboard, like Autocad does, so that R-space-B-space might start the rotate command, and B would indicate (re)locating the basepoint.

I'm trying to understand why it's so difficult to expose object controls to the keyboard. Dialog boxes should simply be invoking object method calls, no? So couldn't there simply be a command with appropriate command ID that allows direct access to object methods (via a sanitizing routine of some sort)? If there is access via the new API (and I assume that there is), then why not via an in program handler?

Makes me lament the loss of command lines, and the compatibility with which requires the assignment of user accessible commands for every new feature.

And now the non-programmer who knows not whereof he speaks will shut up;)