Zugg MASTER

Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Thu Jan 29, 2009 6:21 pm |
Yep, that is actually done by design. It's just one of those "learning curve" issues. I found that people wanted Ctrl-F to execute the new Find dialog within the script editor. And yet I didn't want to change the Ctrl-F for opening the search toolbar for finding settings.
It is not unusual for shortcuts to be context dependent like this. For another example, look at Copy/Paste (Ctrl-C and Ctrl-V). If you are in a text box, the Copy/Paste will copy or paste the text selected in the text box. But if the Tree View has the keyboard focus, then Copy/Paste will copy and paste entire settings. So it's the same idea. Many operations depend upon the type of "control" that has the keyboard focus.
All Ctrl-F does is execute the menu item associated with it. Same for Copy/Paste. So it's also normal that both the keyboard and menu command are context sensitive.
You actually don't even need to click on the Tree first. If *any* control other than the main Script field has the keyboard focus, then it will execute the old Ctrl-F function. It's only when the script editor field itself has the focus that Ctrl-F changes (along with many other keyboard commands). As another example, think of the Tab key. When the script editor has focus, the Tab key indents the line in the editor. But if some other edit box or button has the keyboard focus, the Tab key moves to the next control on the form.
Just saying that context shortcuts, especially when dealing with an editor box that has a *lot* of it's own keyboard shortcuts, it very common. |
|