ZoomContentControl not updating CenterPoint as a result of Zoom operation

Hi Justin,

We did some internal debugging to see the value of CenterPoint in our ZoomContentControlVirtualSpace QuickStart.  The ZoomContentControl.CenterPoint property is bound to a ZoomDecorator.CenterPoint property (ZoomDecorator is used in ZoomContentControl's template) and that property does use coercion.  In the QuickStart if you zoom into 800% and scroll all the way left, the real value and coerced values are the same.  As you zoom out a couple steps, coercion starts to take effect.  The property still has the real value behind the scenes so that if you zoom back in, it will go all the way left again.  But the coerced value keeps scrolling such that the shape starts to center so that it's fully visible horizontally.  The problem seems to be that the binding on ZoomContentControl.CenterPoint doesn't seem to pick up the coerced value change, it only sees the uncoerced change.  We don't really want to manually force an update to the CenterPoint because that would break the zoom-in functionality from returning to where it should.

You could probably work around it by allowing virtual space.  Is that an option for you or do we need to look into something else?

>>The property still has the real value behind the scenes so that if you zoom back in, it will go all the way left again. But the coerced value keeps scrolling such that the shape starts to center so that it's fully visible horizontally. The problem seems to be that the binding on ZoomContentControl.CenterPoint doesn't seem to pick up the coerced value change, it only sees the uncoerced change.

I understand how this is working - however, it seems to me that the external behavior is incorrect.  While it makes perfect sense to maintain some internal value so it knows to zoom back to where it was, the fact is that this is more of an implementation detail; what it's exposing publicly as a CenterPoint should represent what's being shown...and in this case it does not.  This is clear by how it "jumps" back to the correct value as soon as you grab the content with the mouse.  Again, I do understand what it's doing - but when CenterPoint is shown visually in one place while the CenterPoint property value is different...the public interface no longer represents the behavior it's meant to represent.

(Essentially there are 2 CenterPoints, the coerced and the uncoerced - but the ones that should be public vs internal are swapped.  The public one should reflect the public view, while the internal one can maintain the point to which it should return.  Currently the opposite is true - leading to glitches like described above...).

Hi Justin,

After researching, it seems that coerced values in WPF don't forward back to the other binding.  We are adding a new read-only ZoomContentControl.CenterPointResolved property that will return the true center, even when the normal value is coerced.  This is what you will want to bind to in the future for your ruler.  This update will be in the 2016.1 version.  We have some users testing a 2016.1 preview due to all the Docking/MDI updates that were made for it.  If you'd like access to the preview, please write our support address to request it and we'll hook you up.

Great, sounds good - thanks!  I'm alright just hanging tight for now & using virtual space until it's released; I've already got a list of things to change once that version is out anyway (presuming it's also what'll include vNext) ;)

Hi Justin,

Yes, Docking/MDI vNext is what will be in 2016.1 and it's looking great.