>>I'm still unclear about part of this. OK - using the Focus scope makes it easy to identify the element with focus so you could, say, put 'Button2.CommandTarget = FocusManager.GetFocusedElement(this)' in the button click to set the CommandTarget in code. But this isn't neccessary since something has already performed the operation. What I haven't found is any info on where the logic that does this is located.
>>Any clues?
>>Regards,
>>Viv
>
>I looked through these yesterday:
>
>http://msdn2.microsoft.com/en-us/library/aa969768.aspx
>http://msdn2.microsoft.com/en-us/library/system.windows.input.focusmanager.aspx
>http://msdn2.microsoft.com/en-us/library/system.windows.input.focusmanager.isfocusscope.aspx

Thx. I think I'd read these before but re-reading them together helps a bit.

>
>I always seem to find Microsoft documentation to be clear as mud. I especially liked this line:
>
>"A focus scope is a container element that keeps track of the FocusManager.FocusedElement within [sic] the its scope."
>
>I can live with the typo, but I think a better way to have put that would have been:
>
>A focus scope is an element on a container that keeps track of the FocusManager.FocusedElement for that container's descendants."
>
>or
>
>A focus scope is an attached property for a container that keeps track of the FocusManager.FocusedElement for that container and it's descendants. It isolates the containers logical focus from the logical focus of it's ancestors."
>
>I "might" have understood those.
>
>Then... we get into the commanding overview and we have "the element with keyboard focus will be used as the command target"

It actually says
"If the command target is not defined, the element with keyboard focus will be used as the command target" - which isn't quite the same. But may still be wrong :={

>http://msdn2.microsoft.com/en-us/library/ms752308.aspx
>
>Based on what we've seen, that is not correct. Per the "FocusManager Class"
>
>"There can be only one element with keyboard focus" and that would be the button when we click it wouldn't it?
>
>So I think the correct answer would be:
>
>The element within the "windows" focus scope that has logical focus will be used as the command target.
>
>BTW the FocusManager does appear to be all static. I used mole to check and no focus objects appear to be injected into either the logical or visual trees.
>
>HTH (And hope I actually answered the question)
>
>At least I "THINK" I understand this now? <g>

It's becoming clearer. But I'm afraid I still don't 'get' what bit of the Commanding infrastructure actually sets the CommandTarget value if it is not specifically defined. I also don't see 'when' it gets set.
I'm also wondering what happens when a window has multiple focus scopes holding potential command targets? Presumably the window element with the logical focus will be the element with logical focus in the most recently accessed focus scope? (Must be a clearer way of expressing this but it eludes me :={)

On an unrelated note I just stumbled across the UIElement.SnapToDevicePixels property that I was not aware off and that would have answered Rick's criticism that it was not possible to disable anti-aliasing :=}

Regards,
Viv