I can't override the bindkey Shift<Key>3. It seems permanently set to hiToggleAnchorMagnifier.
Like many companies, ours adopted a set of metal viewing shortcuts in our bindkeys, <Key1> displays metal1, Ctrl<Key>2 removes metal2 from display, Shift<Key>3 adds metal3.
As you can see, Shift<Key>3 being tied to hiToggleAnchorMagnifier is a problem. Moreover I have no idea and probably don't even care what this is.
Can anyone shed any light as to why I can't change the binding?
I saw the same problem. It is because Cadence has a bindkey set for '#' (which is what you get with a shift-3). Basically the '#' bindkey trumps the Shift<Key>3 bindkey. You can either redefine your bindkey as '#', or undefine '#' and your key will work again.
hiSetBindkey("Layout" "<Key>#" "")
In reply to dmay:
The idea is that the specific key names have higher priority than the Shift-Number keys - this is to allow keys to be bound to a named character, and is particularly useful when that key moves around the keyboard in different locations.
For example, on a US-English keyboard, the "#" key is on shift-3, but for me (with a UK-English keyboard), shift-3 is the £ symbol (which corresponds to <Key>sterling), and the "#" key is unshifted and to the left of the enter key. So your keyboard may vary...
When the magnifier was added, we tried to come up with some keys that weren't used in the "default" bindkeys, so we had to look for the same key being free in both the schematic and layout bindkeys. So for example you can hit the "." key to turn on the magnifier, and the magnifier follows the mouse (offset by a little). The "#" key will anchor the magnifier in the location it was when you press the key. You can also toggle the magnifier on and off by using View->Magnifier, and control it via Options->Magnifier. Shift-Ctrl-Scrollwheel alters the magnification level. Shift-Ctrl-Up/Down does the same thing. And Shift-Ctrl left mouse zooms to the magnifier zoom level, and Shift-Ctrl middle mouse zooms out.
As of IC615, the "default" bindkeys are loaded at startup (in the past you had to explicitly load bindkeys to get anything other than a very small number of built-ins), so that's another reason why you're seeing them defined.
Awesome! Thank you.
In reply to Andrew Beckett:
This explains some other odd key things that have been showing up.