> 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

>  TestFocus.zip.doc
> 140KViewDownload