如何从视图模型访问不可绑定的视图属性？

Question

I'm using the Telerik WPF RadGanttView control to display a bunch of data. Since the data can be arbitrarily weird - events that are instantaneous, or that last days, or have a week between them - it's not possible to set a PixelLength (ie a scale factor) that's guaranteed to be useful. I've been asked to make it possible to change this scale factor with a slider. Unfortunately, just changing the scale factor with the slider has a usability issue, which I need to fix by manually adjusting where the view is scrolled. I'm at a loss as to how exactly.

To outline the usability problem I'm fixing: the view works by providing a "viewport", located at an "offset", over the whole "extent" of the data set. (Terms lifted from the Telerik API . These seem to simply represent pixels in the canvas underlying the scrollable view.) When the scale factor goes from, say, 100% to 200% (which corresponds to halving the PixelLength ), what happens is that the width of the extent is doubled, but the horizontal offset remains the same. The consequence is that after zooming in, it's quite likely you'll see entirely different data than before, since the events that were there before got "pulled out" of the viewport to the right.

The way I intend to fix this is: grab the offset/viewport/extent etc before zooming in, zoom, then do some maths I haven't figured out yet with that and the new offset/viewport/extent. The problem is: the properties of RadGanttView that describe the scrolling stuff are not DependencyProperty s, and I cannot simply bind them to properties on my ViewModel . (In fact, they're not even accessible in XAML to begin with, RadGanttView implements IScrollingInfo explicitly.)

So, my question is: how do I, in my ViewModel , or wherever else in reaction to the ViewModel 's scale factor changing, access properties of a control in the corresponding View , that cannot be data-bound? Every search I tried tells me that accessing the view from the viewmodel is "not MVVM", but since Telerik is a third-party library, I can't really refactor how this works on their side.

A fill-in-the-blanks outline of my code:

FooViewModel.cs

class FooViewModel 
{

    // A slider in the view pushes its value into this property
    double ScaleFactor 
    {
        get { /*...*/ }
        set
        {
            PixelLength = GetNewPixelLength(value);
            // ...
        }
    }

    // The RadGanttView pulls its scale from this property
    double PixelLength
    {
        get { ... }
        set
        {
            // How do I get these values?
            var oldOffset = ???;
            var oldExtent - ???;

            // Trigger the actual change in the view.
            PropertyChanged("PixelLength", ...);

            var newExtent = ???;
            ???.HorizontalOffset =  GetNewOffset(...);
        }
    }
}

FooView.xaml

<UserControl ... d:DataContext="{d:DesignInstance my:FooViewModel}">
    <telerik:RadGanttView x:Name="Gantt">
        <!-- ... -->
    </telerik:RadGanttView>
</UserControl>

Things I've looked into:

• Making a bunch of DependencyProperty wrappers in the FooView code-behind that just access corresponding properties in the RadGanttView . This seems like it both is a horrible abuse of the system - ie it doesn't seem to make sense to have a dependency property not backed by a DependencyObject . And also that it plain wouldn't work - in WPF, the view seems to "push" data into the view model, and I'd still have no way to actually get the current values, since the values of the wrapper properties would never get updated.
• Uh, Command s, maybe? I'm fairly new at WPF, I have no clue how those work at all, merely a vague impression that they might be a loosely coupled way for the view model to talk to the view.
• Attached properties? Custom bindings? Way above my pay grade, if they help I don't know how myself. It seems like they could accomplish the "dirty" solution of just binding a control to a view model property. Since the type of that property would be IScrollingInfo , not the whole view, I could live with that.

Answer 1

Attached Behaviors may solve your issue. They are basically Attached Properties with a callback.

Check out my answer here . Just instead of KeyDown event, you register to the Changed event (or whatever your control is actually calling it) and then assign the value you get from the Changed event to your Attached Property, and you have two way binding on a non-bindable property