Vista - Xaml KeyBinding problem

This markup:

<ToolBarTray Margin="0" >
<ToolBar>
<ToolBar.InputBindings>
<KeyBinding Key="N" Modifiers="Control" />
</ToolBar.InputBindings>
<Button>Hello</Button>
</ToolBar>
<ToolBar>
<Button>Other</Button>
</ToolBar>
</ToolBarTray>

ends up generating this error:

Error at element 'KeyBinding' in markup file '' : Cannot assign value 'N' to
property 'System.Windows.Input.KeyBinding.Key'. Line 45 Position 31.

Do I really need to do some explicit cast to a Key type?

Thanks for finding this. What's happening is in our quest to validate
parameters, we went overboard and made the attribute order significant.
Reversing the action the order works as expected:
<KeyBinding Modifiers="Control" Key="N"/>

I am curious though why you aren't seeing the full exception message:
..... Given Key and Modifier combination 'None+N' is not supported for
KeyGesture. ...

-Nick Kramer [MSFT]
http://blogs.msdn.com/nickkramer

---
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"CSkinner" <cwskinner_no_sppaaam@comcast.net> wrote in message
news:ul2Hunf$FHA.504@TK2MSFTNGP12.phx.gbl...
> This markup:
>
> <ToolBarTray Margin="0" >
> <ToolBar>
> <ToolBar.InputBindings>
> <KeyBinding Key="N" Modifiers="Control" />
> </ToolBar.InputBindings>
> <Button>Hello</Button>
> </ToolBar>
> <ToolBar>
> <Button>Other</Button>
> </ToolBar>
> </ToolBarTray>
>
> ends up generating this error:
>
> Error at element 'KeyBinding' in markup file '' : Cannot assign value 'N'
> to property 'System.Windows.Input.KeyBinding.Key'. Line 45 Position 31.
>
> Do I really need to do some explicit cast to a Key type?
>

I actually encountered this validation while making a ComboGesture class
that would allow commands to be hooked up to multiple UI gestures, Visual
Studio-style. I wrote a simple InputGesture class that implemented the
Match() method by walking through a list of other InputGestures that had
been associated with it and calling Match() on them in turn until it gets to
the end of the list. This works great with things like "Ctrl+U, Ctrl+X" and
such, or even "Ctrl+U, Alt+RightClick", but I couldn't create something like
the default binding Visual Studio uses for the various watch windows, which
is "Ctrl+Alt+W, 1" for the first one, etc. I agree that key gestures with no
modifiers aren't *generally* useful, but this seems like a compelling
scenario for them -- and anyway, I'm not sure I see a good reason to
disallow it. Could you possibly shed some light on why this validation is in
there in the first place? Thanks!

-- Ryan Milligan

"Nick Kramer [MSFT]" <nkramer@ms.spam> wrote in message
news:eP$VtOp$FHA.328@TK2MSFTNGP14.phx.gbl...
> Thanks for finding this. What's happening is in our quest to validate
> parameters, we went overboard and made the attribute order significant.
> Reversing the action the order works as expected:
> <KeyBinding Modifiers="Control" Key="N"/>
>
> I am curious though why you aren't seeing the full exception message:
> .... Given Key and Modifier combination 'None+N' is not supported for
> KeyGesture. ...
>
> -Nick Kramer [MSFT]
> http://blogs.msdn.com/nickkramer
>
> ---
> This posting is provided "AS IS" with no warranties, and confers no
> rights. Use of included script samples are subject to the terms specified
> at http://www.microsoft.com/info/cpyright.htm
>
>
> "CSkinner" <cwskinner_no_sppaaam@comcast.net> wrote in message
> news:ul2Hunf$FHA.504@TK2MSFTNGP12.phx.gbl...
>> This markup:
>>
>> <ToolBarTray Margin="0" >
>> <ToolBar>
>> <ToolBar.InputBindings>
>> <KeyBinding Key="N" Modifiers="Control" />
>> </ToolBar.InputBindings>
>> <Button>Hello</Button>
>> </ToolBar>
>> <ToolBar>
>> <Button>Other</Button>
>> </ToolBar>
>> </ToolBarTray>
>>
>> ends up generating this error:
>>
>> Error at element 'KeyBinding' in markup file '' : Cannot assign value 'N'
>> to property 'System.Windows.Input.KeyBinding.Key'. Line 45 Position 31.
>>
>> Do I really need to do some explicit cast to a Key type?
>>
>
>

Actually Nick, I ran into this while working inside XamlPad. This was the
error reported in the status bar area.

CS


"Nick Kramer [MSFT]" <nkramer@ms.spam> wrote in message
news:eP$VtOp$FHA.328@TK2MSFTNGP14.phx.gbl...
> Thanks for finding this. What's happening is in our quest to validate
> parameters, we went overboard and made the attribute order significant.
> Reversing the action the order works as expected:
> <KeyBinding Modifiers="Control" Key="N"/>
>
> I am curious though why you aren't seeing the full exception message:
> .... Given Key and Modifier combination 'None+N' is not supported for
> KeyGesture. ...
>
> -Nick Kramer [MSFT]
> http://blogs.msdn.com/nickkramer
>
> ---
> This posting is provided "AS IS" with no warranties, and confers no
> rights. Use of included script samples are subject to the terms specified
> at http://www.microsoft.com/info/cpyright.htm
>
>
> "CSkinner" <cwskinner_no_sppaaam@comcast.net> wrote in message
> news:ul2Hunf$FHA.504@TK2MSFTNGP12.phx.gbl...
>> This markup:
>>
>> <ToolBarTray Margin="0" >
>> <ToolBar>
>> <ToolBar.InputBindings>
>> <KeyBinding Key="N" Modifiers="Control" />
>> </ToolBar.InputBindings>
>> <Button>Hello</Button>
>> </ToolBar>
>> <ToolBar>
>> <Button>Other</Button>
>> </ToolBar>
>> </ToolBarTray>
>>
>> ends up generating this error:
>>
>> Error at element 'KeyBinding' in markup file '' : Cannot assign value 'N'
>> to property 'System.Windows.Input.KeyBinding.Key'. Line 45 Position 31.
>>
>> Do I really need to do some explicit cast to a Key type?
>>
>
>

We put the restriction in there because we thought people could do more harm
than good using modifier-less key bindings. You can use them to do all
sorts of poor designs that have a bad user experience, don't localize well
(KeyDown vs. TextInput event), screw up access key vs. accelerator, etc.
But on the other hand, we didn't appreciate how hard it would be to validate
order-independent, so we may need to re-evaluate.

Supporting Ctrl+U, Ctrl+X (chorded key sequences) wasn't really something we
intended to support in v1, it's a neat scenario but we had to draw the line
somewhere. I'd always thought people who wanted chorded keys would avoid
InputBinding completely (just listen to KeyDown and raise your favorite
command that way), but using Match() is another interesting approach.

-Nick Kramer [MSFT]
http://blogs.msdn.com/nickkramer

---
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"Ryan Milligan" <ceiled@hotmail.com> wrote in message
news:MJadne7_eqrSBwHeRVn-uA@comcast.com...
>I actually encountered this validation while making a ComboGesture class
>that would allow commands to be hooked up to multiple UI gestures, Visual
>Studio-style. I wrote a simple InputGesture class that implemented the
>Match() method by walking through a list of other InputGestures that had
>been associated with it and calling Match() on them in turn until it gets
>to the end of the list. This works great with things like "Ctrl+U, Ctrl+X"
>and such, or even "Ctrl+U, Alt+RightClick", but I couldn't create something
>like the default binding Visual Studio uses for the various watch windows,
>which is "Ctrl+Alt+W, 1" for the first one, etc. I agree that key gestures
>with no modifiers aren't *generally* useful, but this seems like a
>compelling scenario for them -- and anyway, I'm not sure I see a good
>reason to disallow it. Could you possibly shed some light on why this
>validation is in there in the first place? Thanks!
>
> -- Ryan Milligan
>
> "Nick Kramer [MSFT]" <nkramer@ms.spam> wrote in message
> news:eP$VtOp$FHA.328@TK2MSFTNGP14.phx.gbl...
>> Thanks for finding this. What's happening is in our quest to validate
>> parameters, we went overboard and made the attribute order significant.
>> Reversing the action the order works as expected:
>> <KeyBinding Modifiers="Control" Key="N"/>
>>
>> I am curious though why you aren't seeing the full exception message:
>> .... Given Key and Modifier combination 'None+N' is not supported for
>> KeyGesture. ...
>>
>> -Nick Kramer [MSFT]
>> http://blogs.msdn.com/nickkramer
>>
>> ---
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights. Use of included script samples are subject to the terms specified
>> at http://www.microsoft.com/info/cpyright.htm
>>
>>
>> "CSkinner" <cwskinner_no_sppaaam@comcast.net> wrote in message
>> news:ul2Hunf$FHA.504@TK2MSFTNGP12.phx.gbl...
>>> This markup:
>>>
>>> <ToolBarTray Margin="0" >
>>> <ToolBar>
>>> <ToolBar.InputBindings>
>>> <KeyBinding Key="N" Modifiers="Control" />
>>> </ToolBar.InputBindings>
>>> <Button>Hello</Button>
>>> </ToolBar>
>>> <ToolBar>
>>> <Button>Other</Button>
>>> </ToolBar>
>>> </ToolBarTray>
>>>
>>> ends up generating this error:
>>>
>>> Error at element 'KeyBinding' in markup file '' : Cannot assign value
>>> 'N' to property 'System.Windows.Input.KeyBinding.Key'. Line 45 Position
>>> 31.
>>>
>>> Do I really need to do some explicit cast to a Key type?
>>>
>>
>>
>
>

I completely understand not providing this functionality out of the box --
the ComboGesture was actually pretty simple to implement, and it acts
entirely as a composite of other input gestures. I like that approach,
because it means that input chords can easily incorporate future gesture
types that may be developed, like stylus gestures, voice gestures, etc. All
it's missing is a centralized repository of InputGesture implementation
types (such as the CodeDomProviders enjoy) to be able to transparently
incorporate any type of input that may be added in the future...I just
hard-coded an array of types for now. I even chained the type converters
together so you can specify your bindings like "Ctrl+F, Alt+C,
Shift-RightClick" which, even though it's an astoundingly bad user
experience, I still think is pretty cool.

The only problem I ran into while putting it together (over the course of
maybe an hour) was the validation issue mentioned in this thread. I agree
that modifier-less gestures can be abused, but so can any feature of any
product. I don't like the idea of having to drop input gestures entirely (or
worse, reinvent the KeyGesture) just because I need this scenario. Would you
like me to file a Ladybug suggestion for removing this validation, or is it
far enough on the table that it's likely to happen regardless? Thanks!

-- Ryan Milligan

"Nick Kramer [MSFT]" <nkramer@ms.spam> wrote in message
news:efDReXDAGHA.2708@TK2MSFTNGP12.phx.gbl...
> We put the restriction in there because we thought people could do more
> harm than good using modifier-less key bindings. You can use them to do
> all sorts of poor designs that have a bad user experience, don't localize
> well (KeyDown vs. TextInput event), screw up access key vs. accelerator,
> etc. But on the other hand, we didn't appreciate how hard it would be to
> validate order-independent, so we may need to re-evaluate.
>
> Supporting Ctrl+U, Ctrl+X (chorded key sequences) wasn't really something
> we intended to support in v1, it's a neat scenario but we had to draw the
> line somewhere. I'd always thought people who wanted chorded keys would
> avoid InputBinding completely (just listen to KeyDown and raise your
> favorite command that way), but using Match() is another interesting
> approach.
>
> -Nick Kramer [MSFT]
> http://blogs.msdn.com/nickkramer
>
> ---
> This posting is provided "AS IS" with no warranties, and confers no
> rights. Use of included script samples are subject to the terms specified
> at http://www.microsoft.com/info/cpyright.htm
>
>
> "Ryan Milligan" <ceiled@hotmail.com> wrote in message
> news:MJadne7_eqrSBwHeRVn-uA@comcast.com...
>>I actually encountered this validation while making a ComboGesture class
>>that would allow commands to be hooked up to multiple UI gestures, Visual
>>Studio-style. I wrote a simple InputGesture class that implemented the
>>Match() method by walking through a list of other InputGestures that had
>>been associated with it and calling Match() on them in turn until it gets
>>to the end of the list. This works great with things like "Ctrl+U, Ctrl+X"
>>and such, or even "Ctrl+U, Alt+RightClick", but I couldn't create
>>something like the default binding Visual Studio uses for the various
>>watch windows, which is "Ctrl+Alt+W, 1" for the first one, etc. I agree
>>that key gestures with no modifiers aren't *generally* useful, but this
>>seems like a compelling scenario for them -- and anyway, I'm not sure I
>>see a good reason to disallow it. Could you possibly shed some light on
>>why this validation is in there in the first place? Thanks!
>>
>> -- Ryan Milligan
>>
>> "Nick Kramer [MSFT]" <nkramer@ms.spam> wrote in message
>> news:eP$VtOp$FHA.328@TK2MSFTNGP14.phx.gbl...
>>> Thanks for finding this. What's happening is in our quest to validate
>>> parameters, we went overboard and made the attribute order significant.
>>> Reversing the action the order works as expected:
>>> <KeyBinding Modifiers="Control" Key="N"/>
>>>
>>> I am curious though why you aren't seeing the full exception message:
>>> .... Given Key and Modifier combination 'None+N' is not supported for
>>> KeyGesture. ...
>>>
>>> -Nick Kramer [MSFT]
>>> http://blogs.msdn.com/nickkramer
>>>
>>> ---
>>> This posting is provided "AS IS" with no warranties, and confers no
>>> rights. Use of included script samples are subject to the terms
>>> specified at http://www.microsoft.com/info/cpyright.htm
>>>
>>>
>>> "CSkinner" <cwskinner_no_sppaaam@comcast.net> wrote in message
>>> news:ul2Hunf$FHA.504@TK2MSFTNGP12.phx.gbl...
>>>> This markup:
>>>>
>>>> <ToolBarTray Margin="0" >
>>>> <ToolBar>
>>>> <ToolBar.InputBindings>
>>>> <KeyBinding Key="N" Modifiers="Control" />
>>>> </ToolBar.InputBindings>
>>>> <Button>Hello</Button>
>>>> </ToolBar>
>>>> <ToolBar>
>>>> <Button>Other</Button>
>>>> </ToolBar>
>>>> </ToolBarTray>
>>>>
>>>> ends up generating this error:
>>>>
>>>> Error at element 'KeyBinding' in markup file '' : Cannot assign value
>>>> 'N' to property 'System.Windows.Input.KeyBinding.Key'. Line 45 Position
>>>> 31.
>>>>
>>>> Do I really need to do some explicit cast to a Key type?
>>>>
>>>
>>>
>>
>>
>
>

> Would you like me to file a Ladybug suggestion for removing this
> validation, or is it far enough on the table that it's likely to happen
> regardless? Thanks!

Yes, please file a suggestion, I can't promise we'll change it but at least
we'll know someone in the real world cares about the issue.

-Nick Kramer [MSFT]
http://blogs.msdn.com/nickkramer

---
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"Ryan Milligan" <ceiled@hotmail.com> wrote in message
news:Pd2dnYtPcIZWJwLenZ2dnUVZ_tGdnZ2d@comcast.com...
>I completely understand not providing this functionality out of the box --
>the ComboGesture was actually pretty simple to implement, and it acts
>entirely as a composite of other input gestures. I like that approach,
>because it means that input chords can easily incorporate future gesture
>types that may be developed, like stylus gestures, voice gestures, etc. All
>it's missing is a centralized repository of InputGesture implementation
>types (such as the CodeDomProviders enjoy) to be able to transparently
>incorporate any type of input that may be added in the future...I just
>hard-coded an array of types for now. I even chained the type converters
>together so you can specify your bindings like "Ctrl+F, Alt+C,
>Shift-RightClick" which, even though it's an astoundingly bad user
>experience, I still think is pretty cool.
>
> The only problem I ran into while putting it together (over the course of
> maybe an hour) was the validation issue mentioned in this thread. I agree
> that modifier-less gestures can be abused, but so can any feature of any
> product. I don't like the idea of having to drop input gestures entirely
> (or worse, reinvent the KeyGesture) just because I need this scenario.
> Would you like me to file a Ladybug suggestion for removing this
> validation, or is it far enough on the table that it's likely to happen
> regardless? Thanks!
>
> -- Ryan Milligan
>
> "Nick Kramer [MSFT]" <nkramer@ms.spam> wrote in message
> news:efDReXDAGHA.2708@TK2MSFTNGP12.phx.gbl...
>> We put the restriction in there because we thought people could do more
>> harm than good using modifier-less key bindings. You can use them to do
>> all sorts of poor designs that have a bad user experience, don't localize
>> well (KeyDown vs. TextInput event), screw up access key vs. accelerator,
>> etc. But on the other hand, we didn't appreciate how hard it would be to
>> validate order-independent, so we may need to re-evaluate.
>>
>> Supporting Ctrl+U, Ctrl+X (chorded key sequences) wasn't really something
>> we intended to support in v1, it's a neat scenario but we had to draw the
>> line somewhere. I'd always thought people who wanted chorded keys would
>> avoid InputBinding completely (just listen to KeyDown and raise your
>> favorite command that way), but using Match() is another interesting
>> approach.
>>
>> -Nick Kramer [MSFT]
>> http://blogs.msdn.com/nickkramer
>>
>> ---
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights. Use of included script samples are subject to the terms specified
>> at http://www.microsoft.com/info/cpyright.htm
>>
>>
>> "Ryan Milligan" <ceiled@hotmail.com> wrote in message
>> news:MJadne7_eqrSBwHeRVn-uA@comcast.com...
>>>I actually encountered this validation while making a ComboGesture class
>>>that would allow commands to be hooked up to multiple UI gestures, Visual
>>>Studio-style. I wrote a simple InputGesture class that implemented the
>>>Match() method by walking through a list of other InputGestures that had
>>>been associated with it and calling Match() on them in turn until it gets
>>>to the end of the list. This works great with things like "Ctrl+U,
>>>Ctrl+X" and such, or even "Ctrl+U, Alt+RightClick", but I couldn't create
>>>something like the default binding Visual Studio uses for the various
>>>watch windows, which is "Ctrl+Alt+W, 1" for the first one, etc. I agree
>>>that key gestures with no modifiers aren't *generally* useful, but this
>>>seems like a compelling scenario for them -- and anyway, I'm not sure I
>>>see a good reason to disallow it. Could you possibly shed some light on
>>>why this validation is in there in the first place? Thanks!
>>>
>>> -- Ryan Milligan
>>>
>>> "Nick Kramer [MSFT]" <nkramer@ms.spam> wrote in message
>>> news:eP$VtOp$FHA.328@TK2MSFTNGP14.phx.gbl...
>>>> Thanks for finding this. What's happening is in our quest to validate
>>>> parameters, we went overboard and made the attribute order significant.
>>>> Reversing the action the order works as expected:
>>>> <KeyBinding Modifiers="Control" Key="N"/>
>>>>
>>>> I am curious though why you aren't seeing the full exception message:
>>>> .... Given Key and Modifier combination 'None+N' is not supported for
>>>> KeyGesture. ...
>>>>
>>>> -Nick Kramer [MSFT]
>>>> http://blogs.msdn.com/nickkramer
>>>>
>>>> ---
>>>> This posting is provided "AS IS" with no warranties, and confers no
>>>> rights. Use of included script samples are subject to the terms
>>>> specified at http://www.microsoft.com/info/cpyright.htm
>>>>
>>>>
>>>> "CSkinner" <cwskinner_no_sppaaam@comcast.net> wrote in message
>>>> news:ul2Hunf$FHA.504@TK2MSFTNGP12.phx.gbl...
>>>>> This markup:
>>>>>
>>>>> <ToolBarTray Margin="0" >
>>>>> <ToolBar>
>>>>> <ToolBar.InputBindings>
>>>>> <KeyBinding Key="N" Modifiers="Control" />
>>>>> </ToolBar.InputBindings>
>>>>> <Button>Hello</Button>
>>>>> </ToolBar>
>>>>> <ToolBar>
>>>>> <Button>Other</Button>
>>>>> </ToolBar>
>>>>> </ToolBarTray>
>>>>>
>>>>> ends up generating this error:
>>>>>
>>>>> Error at element 'KeyBinding' in markup file '' : Cannot assign value
>>>>> 'N' to property 'System.Windows.Input.KeyBinding.Key'. Line 45
>>>>> Position 31.
>>>>>
>>>>> Do I really need to do some explicit cast to a Key type?
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>