Get control ref from Xaml caret position in text editor

[amwx]

Is there any mechanism to derive the control from the caret position in a xaml file? As in the VS extension, if you move the caret around in the text view, you could easily get the reference to the control the current xaml block corresponds to, such as clicking on a <Panel> tag, or within it, will highlight the bounds of the panel in the designer view. This is possible and a feature of the WPF/UWP designer.

I'm working my way through some features I'd like to get included into the VS extension to improve it and this is something I think could be really useful. Note, I'm not trying to invent a full designer - I know the general consensus on that - but being able to scroll the preview bitmap to the current control being edited in xaml, or highlight and maybe display some layout characteristics could be a really nice feature. The IWPFTextView has an event that listens for caret changes not related to text changes which can retrieve the xaml position, but I haven't found a way to translate that text position to the control it corresponds to.

Technically, this should work both ways - such that specifying a control can retrieve the xaml declaration position, but one step at a time.

[kekekeks]

We can add an extra transformation pass similar to what we do with x:Name that would register created objects in some kind of a scope and then use it for bi-directional mapping.

There are 2 problems, however:

1. XDocument (and XmlReader) only gives you the element start position, not the full span, that has to be taken into account when implementing the editor support
2. There can be multiple element instances in case of data/control templates, which should be returned to the IDE view?

We also need to properly design the protocol messages so the same feature could be implemented in the Rider plugin

[amwx]

2. There can be multiple element instances in case of data/control templates, which should be returned to the IDE view?

As far as I know, WPF/UWP designers only do this for the main visual tree (the elements under the Window/page/user control), mostly likely because of this reason. Similarly, ItemsControls with generated items (not xaml declared) don't react and the parent ItemsControl is instead selected.

1. XDocument (and XmlReader) only gives you the element start position, not the full span, that has to be taken into account when implementing the editor support

Since we only need the main xaml tree, I don't think we need the full span of the element. If you have the start position of the element and the position of the caret (either char position in doc or line number + char position) it should be a fairly straightforward test to figure out which element you want. For the other way, WPF/UWP designers don't move the caret, but scroll the document to make that element in view and adds some highlighting to direct you to it. I'm not sure how that's accomplished, but we could just move the caret to the start of the element tag, if desired.