> 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

> 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

> 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

> 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

> 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

> 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

> 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

> 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

> 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

> 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

> 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

> On Mon, Mar 15, 2010 at 6:33 PM, Marlon Grech <marlongr...@gmail.com>wrote:

>> something like this... but I need to do something else so that its
>> cooler...

>> 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

> --
> Peter O'Hanlon

> On Mar 15, 7:33 pm, Marlon Grech <marlongr...@gmail.com> wrote:
> > something like this... but I need to do something else so that its
> cooler...

> > 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

> Basically I hate it when my ViewModel has to implement all these
> interfaces... It feels like back in Java days to me...

> so the idea here is to still use namescopes but leverage the databinding
> capabilities of WPF... so that you can do something like this

> <Grid focusStuff:FocusedBehaviourTake2.FocusElement="{Binding Focus}">

> and in the VM

> Save = new RelayCommand( x => Focus= "Name");

> Basically in the ViewModel you set a property that exposes the element that
> should get focus. The attached behavior (which accepts binding) will get
> triggered when the property changes. THERE IS ONE SIDE EFFECT OF THIS.
> Basically if the viewmodel sets the Focus property to be the same the
> attached behavior will not get triggered again... this might be a show
> stopper for this idea... what do you guys think?

> which approach would you like best?

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

> On Mon, Mar 15, 2010 at 8:25 PM, Daniel Vaughan <dbvaug...@gmail.com>wrote:

>> Good thinking Marlon. As Pete said, very innovative.

>> On Mar 15, 7:33 pm, Marlon Grech <marlongr...@gmail.com> wrote:
>> > something like this... but I need to do something else so that its
>> cooler...

>> > 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

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

> On Mon, Mar 15, 2010 at 8:42 PM, Marlon Grech <marlongr...@gmail.com>wrote:

>> Attached is take 2...

>> Basically I hate it when my ViewModel has to implement all these
>> interfaces... It feels like back in Java days to me...

>> so the idea here is to still use namescopes but leverage the databinding
>> capabilities of WPF... so that you can do something like this

>> <Grid focusStuff:FocusedBehaviourTake2.FocusElement="{Binding Focus}">

>> and in the VM

>> Save = new RelayCommand( x => Focus= "Name");

>> Basically in the ViewModel you set a property that exposes the element
>> that should get focus. The attached behavior (which accepts binding) will
>> get triggered when the property changes. THERE IS ONE SIDE EFFECT OF THIS.
>> Basically if the viewmodel sets the Focus property to be the same the
>> attached behavior will not get triggered again... this might be a show
>> stopper for this idea... what do you guys think?

>> which approach would you like best?

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

>> On Mon, Mar 15, 2010 at 8:25 PM, Daniel Vaughan <dbvaug...@gmail.com>wrote:

>>> Good thinking Marlon. As Pete said, very innovative.

>>> On Mar 15, 7:33 pm, Marlon Grech <marlongr...@gmail.com> wrote:
>>> > something like this... but I need to do something else so that its
>>> cooler...

>>> > 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

> On Mon, Mar 15, 2010 at 8:43 PM, Marlon Grech <marlongr...@gmail.com>wrote:

>> P.S sorry for ugly code and all that but the code I produced is just to
>> show you guys the idea ....

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

>>   On Mon, Mar 15, 2010 at 8:42 PM, Marlon Grech <marlongr...@gmail.com>wrote:

>>> Attached is take 2...

>>> Basically I hate it when my ViewModel has to implement all these
>>> interfaces... It feels like back in Java days to me...

>>> so the idea here is to still use namescopes but leverage the databinding
>>> capabilities of WPF... so that you can do something like this

>>> <Grid focusStuff:FocusedBehaviourTake2.FocusElement="{Binding Focus}">

>>> and in the VM

>>> Save = new RelayCommand( x => Focus= "Name");

>>> Basically in the ViewModel you set a property that exposes the element
>>> that should get focus. The attached behavior (which accepts binding) will
>>> get triggered when the property changes. THERE IS ONE SIDE EFFECT OF THIS.
>>> Basically if the viewmodel sets the Focus property to be the same the
>>> attached behavior will not get triggered again... this might be a show
>>> stopper for this idea... what do you guys think?

>>> which approach would you like best?

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

>>>   On Mon, Mar 15, 2010 at 8:25 PM, Daniel Vaughan <dbvaug...@gmail.com>wrote:

>>>> Good thinking Marlon. As Pete said, very innovative.

>>>> On Mar 15, 7:33 pm, Marlon Grech <marlongr...@gmail.com> wrote:
>>>> > something like this... but I need to do something else so that its
>>>> cooler...

>>>> > 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

>  --
> Sacha Barber
> sacha.bar...@gmail.com

> On Mon, Mar 15, 2010 at 9:18 PM, Sacha Barber <sacha.bar...@gmail.com>wrote:

>> I prefer option 1 actually

>> On Mon, Mar 15, 2010 at 8:43 PM, Marlon Grech <marlongr...@gmail.com>wrote:

>>> P.S sorry for ugly code and all that but the code I produced is just to
>>> show you guys the idea ....

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

>>>   On Mon, Mar 15, 2010 at 8:42 PM, Marlon Grech <marlongr...@gmail.com>wrote:

>>>> Attached is take 2...

>>>> Basically I hate it when my ViewModel has to implement all these
>>>> interfaces... It feels like back in Java days to me...

>>>> so the idea here is to still use namescopes but leverage the databinding
>>>> capabilities of WPF... so that you can do something like this

>>>> <Grid focusStuff:FocusedBehaviourTake2.FocusElement="{Binding Focus}">

>>>> and in the VM

>>>> Save = new RelayCommand( x => Focus= "Name");

>>>> Basically in the ViewModel you set a property that exposes the element
>>>> that should get focus. The attached behavior (which accepts binding) will
>>>> get triggered when the property changes. THERE IS ONE SIDE EFFECT OF THIS.
>>>> Basically if the viewmodel sets the Focus property to be the same the
>>>> attached behavior will not get triggered again... this might be a show
>>>> stopper for this idea... what do you guys think?

>>>> which approach would you like best?

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

>>>>   On Mon, Mar 15, 2010 at 8:25 PM, Daniel Vaughan <dbvaug...@gmail.com>wrote:

>>>>> Good thinking Marlon. As Pete said, very innovative.

>>>>> On Mar 15, 7:33 pm, Marlon Grech <marlongr...@gmail.com> wrote:
>>>>> > something like this... but I need to do something else so that its
>>>>> cooler...

>>>>> > 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

>>  --
>> Sacha Barber
>> sacha.bar...@gmail.com

> --
> Peter O'Hanlon

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

>> Same here.

>> On Mon, Mar 15, 2010 at 9:18 PM, Sacha Barber <sacha.bar...@gmail.com>wrote:

>>> I prefer option 1 actually

>>> On Mon, Mar 15, 2010 at 8:43 PM, Marlon Grech <marlongr...@gmail.com>wrote:

>>>> P.S sorry for ugly code and all that but the code I produced is just to
>>>> show you guys the idea ....

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

>>>>   On Mon, Mar 15, 2010 at 8:42 PM, Marlon Grech <marlongr...@gmail.com>wrote:

>>>>> Attached is take 2...

>>>>> Basically I hate it when my ViewModel has to implement all these
>>>>> interfaces... It feels like back in Java days to me...

>>>>> so the idea here is to still use namescopes but leverage the
>>>>> databinding capabilities of WPF... so that you can do something like this

>>>>> <Grid focusStuff:FocusedBehaviourTake2.FocusElement="{Binding Focus}">

>>>>> and in the VM

>>>>> Save = new RelayCommand( x => Focus= "Name");

>>>>> Basically in the ViewModel you set a property that exposes the element
>>>>> that should get focus. The attached behavior (which accepts binding) will
>>>>> get triggered when the property changes. THERE IS ONE SIDE EFFECT OF THIS.
>>>>> Basically if the viewmodel sets the Focus property to be the same the
>>>>> attached behavior will not get triggered again... this might be a show
>>>>> stopper for this idea... what do you guys think?

>>>>> which approach would you like best?

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

>>>>>   On Mon, Mar 15, 2010 at 8:25 PM, Daniel Vaughan <dbvaug...@gmail.com
>>>>> > wrote:

>>>>>> Good thinking Marlon. As Pete said, very innovative.

>>>>>> On Mar 15, 7:33 pm, Marlon Grech <marlongr...@gmail.com> wrote:
>>>>>> > something like this... but I need to do something else so that its
>>>>>> cooler...

>>>>>> > 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

>>>  --
>>> Sacha Barber

> On Mon, Mar 15, 2010 at 9:56 PM, Marlon Grech <marlongr...@gmail.com>wrote:

>> may I ask why you guys prefer option 1? Just for curiosity...
>> Regards
>> Marlon
>> WPF Blog - http://marlongrech.wordpress.com/
>> Microsoft MVP for Client App

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

>>> Same here.

>>> On Mon, Mar 15, 2010 at 9:18 PM, Sacha Barber <sacha.bar...@gmail.com>wrote:

>>>> I prefer option 1 actually

>>>> On Mon, Mar 15, 2010 at 8:43 PM, Marlon Grech <marlongr...@gmail.com>wrote:

>>>>> P.S sorry for ugly code and all that but the code I produced is just to
>>>>> show you guys the idea ....

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

>>>>>   On Mon, Mar 15, 2010 at 8:42 PM, Marlon Grech <marlongr...@gmail.com
>>>>> > wrote:

>>>>>> Attached is take 2...

>>>>>> Basically I hate it when my ViewModel has to implement all these
>>>>>> interfaces... It feels like back in Java days to me...

>>>>>> so the idea here is to still use namescopes but leverage the
>>>>>> databinding capabilities of WPF... so that you can do something like this

>>>>>> <Grid focusStuff:FocusedBehaviourTake2.FocusElement="{Binding Focus}">

>>>>>> and in the VM

>>>>>> Save = new RelayCommand( x => Focus= "Name");

>>>>>> Basically in the ViewModel you set a property that exposes the element
>>>>>> that should get focus. The attached behavior (which accepts binding) will
>>>>>> get triggered when the property changes. THERE IS ONE SIDE EFFECT OF THIS.
>>>>>> Basically if the viewmodel sets the Focus property to be the same the
>>>>>> attached behavior will not get triggered again... this might be a show
>>>>>> stopper for this idea... what do you guys think?

>>>>>> which approach would you like best?

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

>>>>>>   On Mon, Mar 15, 2010 at 8:25 PM, Daniel Vaughan <
>>>>>> dbvaug...@gmail.com> wrote:

>>>>>>> Good thinking Marlon. As Pete said, very innovative.

>>>>>>> On Mar 15, 7:33 pm, Marlon Grech <marlongr...@gmail.com> wrote:
>>>>>>> > something like this... but I need to do something else so that its
>>>>>>> cooler...

>>>>>>> > 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

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

>> Same here.

>> On Mon, Mar 15, 2010 at 9:18 PM, Sacha Barber <sacha.bar...@gmail.com>wrote:

>>> I prefer option 1 actually

>>> On Mon, Mar 15, 2010 at 8:43 PM, Marlon Grech <marlongr...@gmail.com>wrote:

>>>> P.S sorry for ugly code and all that but the code I produced is just to
>>>> show you guys the idea ....

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

>>>>   On Mon, Mar 15, 2010 at 8:42 PM, Marlon Grech <marlongr...@gmail.com>wrote:

>>>>> Attached is take 2...

>>>>> Basically I hate it when my ViewModel has to implement all these
>>>>> interfaces... It feels like back in Java days to me...

>>>>> so the idea here is to still use namescopes but leverage the
>>>>> databinding capabilities of WPF... so that you can do something like this

>>>>> <Grid focusStuff:FocusedBehaviourTake2.FocusElement="{Binding Focus}">

>>>>> and in the VM

>>>>> Save = new RelayCommand( x => Focus= "Name");

>>>>> Basically in the ViewModel you set a property that exposes the element
>>>>> that should get focus. The attached behavior (which accepts binding) will
>>>>> get triggered when the property changes. THERE IS ONE SIDE EFFECT OF THIS.
>>>>> Basically if the viewmodel sets the Focus property to be the same the
>>>>> attached behavior will not get triggered again... this might be a show
>>>>> stopper for this idea... what do you guys think?

>>>>> which approach would you like best?

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

>>>>>   On Mon, Mar 15, 2010 at 8:25 PM, Daniel Vaughan <dbvaug...@gmail.com
>>>>> > wrote:

>>>>>> Good thinking Marlon. As Pete said, very innovative.

>>>>>> On Mar 15, 7:33 pm, Marlon Grech <marlongr...@gmail.com> wrote:
>>>>>> > something like this... but I need to do something else so that its
>>>>>> cooler...

>>>>>> > 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

>>>  --

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

> On Mon, Mar 15, 2010 at 10:04 PM, Sacha Barber <sacha.bar...@gmail.com>wrote:

>> I do not like the idea of the Binding not firing.

>> On Mon, Mar 15, 2010 at 9:56 PM, Marlon Grech <marlongr...@gmail.com>wrote:

>>> may I ask why you guys prefer option 1? Just for curiosity...
>>> Regards
>>> Marlon
>>> WPF Blog - http://marlongrech.wordpress.com/
>>> Microsoft MVP for Client App

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

>>>> Same here.

>>>> On Mon, Mar 15, 2010 at 9:18 PM, Sacha Barber <sacha.bar...@gmail.com>wrote:

>>>>> I prefer option 1 actually

>>>>> On Mon, Mar 15, 2010 at 8:43 PM, Marlon Grech <marlongr...@gmail.com>wrote:

>>>>>> P.S sorry for ugly code and all that but the code I produced is just
>>>>>> to show you guys the idea ....

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

>>>>>>   On Mon, Mar 15, 2010 at 8:42 PM, Marlon Grech <
>>>>>> marlongr...@gmail.com> wrote:

>>>>>>> Attached is take 2...

>>>>>>> Basically I hate it when my ViewModel has to implement all these
>>>>>>> interfaces... It feels like back in Java days to me...

>>>>>>> so the idea here is to still use namescopes but leverage the
>>>>>>> databinding capabilities of WPF... so that you can do something like this

>>>>>>> <Grid focusStuff:FocusedBehaviourTake2.FocusElement="{Binding
>>>>>>> Focus}">

>>>>>>> and in the VM

>>>>>>> Save = new RelayCommand( x => Focus= "Name");

>>>>>>> Basically in the ViewModel you set a property that exposes the
>>>>>>> element that should get focus. The attached behavior (which accepts binding)
>>>>>>> will get triggered when the property changes. THERE IS ONE SIDE EFFECT OF
>>>>>>> THIS. Basically if the viewmodel sets the Focus property to be the same the
>>>>>>> attached behavior will not get triggered again... this might be a show
>>>>>>> stopper for this idea... what do you guys think?

>>>>>>> which approach would you like best?

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

>>>>>>>   On Mon, Mar 15, 2010 at 8:25 PM, Daniel Vaughan <
>>>>>>> dbvaug...@gmail.com> wrote:

>>>>>>>> Good thinking Marlon. As Pete said, very innovative.

>>>>>>>> On Mar 15, 7:33 pm, Marlon Grech <marlongr...@gmail.com> wrote:
>>>>>>>> > something like this... but I need to do something else so that its
>>>>>>>> cooler...

>>>>>>>> > 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;

> actually you know what... I am at a pub and have nothing to do (besides
> drinking beer) so I will have a go with that Idea :) lol

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

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

>> true ... it is a show stopper isn't it...

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

>> On Mon, Mar 15, 2010 at 10:04 PM, Sacha Barber <sacha.bar...@gmail.com>wrote:

>>> I do not like the idea of the Binding not firing.

>>> On Mon, Mar 15, 2010 at 9:56 PM, Marlon Grech <marlongr...@gmail.com>wrote:

>>>> may I ask why you guys prefer option 1? Just for curiosity...
>>>> Regards
>>>> Marlon
>>>> WPF Blog - http://marlongrech.wordpress.com/
>>>> Microsoft MVP for Client App

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

>>>>> Same here.

>>>>> On Mon, Mar 15, 2010 at 9:18 PM, Sacha Barber <sacha.bar...@gmail.com>wrote:

>>>>>> I prefer option 1 actually

>>>>>> On Mon, Mar 15, 2010 at 8:43 PM, Marlon Grech <marlongr...@gmail.com>wrote:

>>>>>>> P.S sorry for ugly code and all that but the code I produced is just
>>>>>>> to show you guys the idea ....

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