> The Idea is that rather then setting an attached property to every element
> you want to control you just set it once and find that element by using WPF
> Namescopes.

> Attached is a prototype... yet I just built this now... did not test it...
> and probably I have bugs all over the place.,... I just did it to show you
> what I mean

> Regards
> Marlon
> WPF Blog - http://marlongrech.wordpress.com/
> Microsoft MVP for Client App

> On Mon, Mar 15, 2010 at 5:50 PM, Josh Smith <flappleja...@gmail.com>wrote:

>> What do you have in mind?

>> On Mon, Mar 15, 2010 at 10:46 AM, Marlon Grech <marlongr...@gmail.com>wrote:

>>> mmm... interesting approach... what about leveraging Namescopes for such
>>> a thing?

>>> Regards
>>> Marlon
>>> WPF Blog - http://marlongrech.wordpress.com/
>>> Microsoft MVP for Client App

>>> On Mon, Mar 15, 2010 at 3:12 PM, Peter O'Hanlon <pete.ohan...@gmail.com>wrote:

>>>> Sounds good. As far as the FocusScopes go, there shouldn't be any
>>>> issues, but it's an edge case to consider (I've been bitten too many times
>>>> by custom FocusScopes).

>>>> On Mon, Mar 15, 2010 at 3:08 PM, Josh Smith <flappleja...@gmail.com>wrote:

>>>>> Thanks Pete. I was thinking that there could be an attached property of
>>>>> type bool that is set on an element, instead of setting ValidatedProperty.
>>>>>  When set, that attached property figures out which property on the element
>>>>> to monitor, such as Text on a TextBox.  This would make it easier than
>>>>> having to specify the property, though that would still be an option if you
>>>>> need to specify it.

>>>>> I'll have to look into FocusScopes, though I don't see any issues there
>>>>> (I might be overlooking something...).

>>>>> Josh

>>>>> On Mon, Mar 15, 2010 at 6:31 AM, Peter O'Hanlon <
>>>>> pete.ohan...@gmail.com> wrote:

>>>>>> The only thing that stands out to me is that this is going to have to
>>>>>> be applied in a lot of places in a typical LOB application, so that might be
>>>>>> a little bit tedious. What effects do FocusScope's have here? I'll need to
>>>>>> play around with this a bit just to make sure there aren't any edge cases
>>>>>> that occur (I'm primarily thinking of cases where loss of focus to a
>>>>>> menu/toolbar triggers the validation but the parent FocusScope has changed
>>>>>> from the textbox).

>>>>>> Pete

>>>>>>   On Mon, Mar 15, 2010 at 2:24 PM, Josh Smith <flappleja...@gmail.com
>>>>>> > wrote:

>>>>>>> Thanks.  Any pitfalls or gotchas sticking their heads out?

>>>>>>> On Mon, Mar 15, 2010 at 1:03 AM, Peter O'Hanlon <
>>>>>>> pete.ohan...@gmail.com> wrote:

>>>>>>>> I like it - I know that it feels "dirty", but it's actually pretty
>>>>>>>> darn cool.

>>>>>>>>  On Mon, Mar 15, 2010 at 3:54 AM, Josh Smith <
>>>>>>>> flappleja...@gmail.com> wrote:

>>>>>>>>> A while back Dr. WPF graced us with his clever hack of controlling
>>>>>>>>> input focus from VM objects.  It involved hijacking the VM's IDataErrorInfo
>>>>>>>>> implementation, and doing all sorts of evil-genius stuff to make the input
>>>>>>>>> caret move to the correct element.  Today while I was *trying* to
>>>>>>>>> read a great novel, I couldn't stop thinking about another way to control
>>>>>>>>> input focus from a viewmodel object.

>>>>>>>>> I put the novel down and did a quick spike of the idea.  The source
>>>>>>>>> code is attached (rename it from .DOC to .ZIP since gmail is terrified of
>>>>>>>>> ZIP files for some reason).  Here's the general idea...

>>>>>>>>> Implement this interface on your VM class:

>>>>>>>>>  /// <summary>
>>>>>>>>> /// Implemented by a ViewModel that needs to control
>>>>>>>>> /// where input focus is in a View.
>>>>>>>>> /// </summary>
>>>>>>>>> public interface IFocusController
>>>>>>>>> {
>>>>>>>>>     /// <summary>
>>>>>>>>>     /// Raised when the input focus should move to
>>>>>>>>>     /// a control whose 'active' dependency property
>>>>>>>>>     /// is bound to the specified property.
>>>>>>>>>     /// </summary>
>>>>>>>>>     event EventHandler<MoveFocusEventArgs> MoveFocus;
>>>>>>>>> }

>>>>>>>>> Next, in your VM object (which might implement IDataErrorInfo), do
>>>>>>>>> something like this to support a Save button:

>>>>>>>>>  public ICommand SaveCommand
>>>>>>>>> {
>>>>>>>>>     get { return new RelayCommand(this.Save); }
>>>>>>>>> }

>>>>>>>>> void Save()
>>>>>>>>> {
>>>>>>>>>     if (this.HasError)
>>>>>>>>>     {
>>>>>>>>>         // The Error property knows which property is invalid.
>>>>>>>>>         this.RaiseMoveFocus(this.Error);
>>>>>>>>>     }
>>>>>>>>>     else
>>>>>>>>>     {
>>>>>>>>>         // Save to database...
>>>>>>>>>         System.Windows.MessageBox.Show("Saved");
>>>>>>>>>     }
>>>>>>>>> }

>>>>>>>>> bool HasError
>>>>>>>>> {
>>>>>>>>>     get { return _validatedProperties.Any(prop =>
>>>>>>>>> !String.IsNullOrEmpty(this[prop])); }
>>>>>>>>> }

>>>>>>>>>  public event EventHandler<MoveFocusEventArgs> MoveFocus;

>>>>>>>>> void RaiseMoveFocus(string focusedProperty)
>>>>>>>>> {
>>>>>>>>>     var handler = this.MoveFocus;
>>>>>>>>>     if (handler != null)
>>>>>>>>>     {
>>>>>>>>>         handler(this, new MoveFocusEventArgs(focusedProperty));
>>>>>>>>>     }
>>>>>>>>> }

>>>>>>>>> Lastly, in your View, use my terribly(?) named attached property to
>>>>>>>>> specify which DP on your elements is bound to the validated property of the
>>>>>>>>> VM, for example:

>>>>>>>>>  <TextBox
>>>>>>>>>     Text="{Binding Path=FirstName, ValidatesOnDataErrors=True}"
>>>>>>>>>     *local:FocusControl.ValidatedProperty="TextBox.Text"*
>>>>>>>>>     />

>>>>>>>>> I'm not sure that I like this approach yet.  It's a pretty
>>>>>>>>> important topic, so I thought I'd share this out amongst the Disciples for
>>>>>>>>> feedback.

>>>>>>>>> Thanks,
>>>>>>>>> Josh

>>>>>>>> --
>>>>>>>> Peter O'Hanlon

>>>>>> --
>>>>>> Peter O'Hanlon

>>>> --
>>>> Peter O'Hanlon