>>>Hi,
>>>Thanks. That explains the behaviour. I'd tried setting Focusable=true but, alone, that didn't help....
>>>
>>>But the problem I have with the solution is that the KeyDown on the ScrollViewer doesn't now get handled. Well, I'll re-phrase that - the event does fire and gets marked as handled by the ScrollViewer but it doesn't perform any action (e.g. downarrow doesn't actually scroll down).....
>>>
>>>Maybe I need to rethink the approach. All I really need is for the ScrollViewer to handle it's navigation keys normally but for the 'inner' Canvas to handle (a limited number) of other keys.
>>>
>>>Any ideas?
>>
>>I would just handle the key events on the ScrollViewer instead of the canvas. It's a lot simpler that way.
>
>As is usually the case I'm afraid my example was an over-simplification. In reality elements of different types will be added to the 'inner' Canvas at runtime. The ScrollViewer itself will have no understanding of these objects or how they are supposed to behave in response to specific key presses.
>
>And, to complicate the explanation further, the 'outer' Canvas in my test is not, in reality, a Canvas at all but a UserControl and the 'inner' Canvas is actually sub-classed with a lot of app specific logic. The XAML guys who are doing the front end may or may not, depending on the circumstances, choose to stick a ScrollViewer between these two elements. But the 'outer' and 'inner' bits do communicate regardless of whether there's an intervening ScrollViewer so I may be able to catch the events in the 'outer' and pass them directly to the 'inner' - in effect leap-frogging the ScrollViewer if it's present......
Hope that made sense..