title: Binding ElementName. Does it use Visual Tree or Logical Tree
body: <p>Having <code>{Binding ElementName=foo}</code>, will it lookup visual or logical tree?</p>
  
  <p><a href="https://blogs.msdn.microsoft.com/mikehillberg/2008/05/23/of-logical-and-visual-trees-in-wpf/" rel="nofollow noreferrer">Of logical and visual trees in WPF | Data See, Data Do</a></p>
  
  <blockquote>
    <p>When does the logical tree matter?</p>
    
    <p>When looking up a name, such as in
    {Binding ElementName=Foo}, the search
    walks up the ancestry looking for a
    name scope, again just as it does for
    inheritable properties.</p>
  </blockquote>
  
  <p><a href="http://blog.scottlogic.com/2009/02/22/elementname-binding-in-silverlight-via-attached-behaviours.html" rel="nofollow noreferrer">ElementName binding in Silverlight via Attached Behaviours</a></p>
  
  <blockquote>
    <p>In order to enable this, WPF provides
    ElementName and RelativeSource
    bindings, giving you a powerful
    mechanism for locating other elements
    within your visual tree to bind to</p>
  </blockquote>
  
  <p><strong>EDIT:</strong></p>
  
  <p>It looks like the Logical Tree used for binding by <code>ElementName</code>.</p>
  
  <p>Argument # 1.</p>
  
  <p>According to MSDN article <a href="http://msdn.microsoft.com/en-us/library/system.windows.frameworkelement.aspx" rel="nofollow noreferrer">FrameworkElement Class</a>:</p>
  
  <blockquote>
    <p>FrameworkElement extends UIElement
    and adds the following capabilities:</p>
    
    <ul>
    <li>Support for data binding and
    dynamic resource references: The
    property-level support for data
    binding and resources is implemented
    by the DependencyProperty class and
    embodied in the property system, but
    the ability to resolve a member value
    that is stored as an Expression (the
    programming construct that underlies
    both data binding and dynamic
    resources) is implemented by
    FrameworkElement. For more
    information, see Data Binding Overview
    and Resources Overview.</li>
    </ul>
  </blockquote>
  
  <p>Argument # 2.</p>
  
  <p><code>ElementName</code> points to <code>x:Name</code>, so this name should be found some how. There is a <a href="http://msdn.microsoft.com/en-us/library/system.windows.namescope.aspx" rel="nofollow noreferrer">NameScope</a> concept.</p>
  
  <blockquote>
    <p>For most scenarios, the FindName
    methods exposed on FrameworkElement
    and FrameworkContentElement are more
    appropriate methods to call to search
    for elements by name. The Name
    properties exposed by FrameworkElement
    and FrameworkContentElement are more
    appropriate properties to use to set
    the initial name as markup attributes.
    And the RegisterName methods exposed
    on FrameworkElement and
    FrameworkContentElement is necessary
    to establish a name into a specific
    namescope (there is no NameScope
    member that can do this directly; you
    must set the current namescope first
    to use RegisterName).</p>
  </blockquote>
  
  <p>On the other hand, <a href="http://msdn.microsoft.com/en-us/library/system.windows.media.visual.aspx" rel="nofollow noreferrer">Visual class</a> neither have <code>FindName</code> method, nor implement <a href="http://msdn.microsoft.com/en-us/library/system.windows.markup.inamescope.aspx" rel="nofollow noreferrer">INameScope</a>.</p>