> 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