> 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