ZoomContentControl not updating CenterPoint as a result of Zoom operation

Navigation for WPF Forum

Posted 8 years ago by Justin Klein
Version: 15.1.0624
Platform: .NET 4.5
Environment: Windows 10 (64-bit)
Avatar

ZoomContentControl.CenterPoint doesn't seem to get updated as a result of a "zoom out" operation (even when the operation changes the center of the view).  This is most easily explained with a video: http://screencast.com/t/gLYdsSjztV

1) I begin with the default view: everything is centered and un-zoomed.  Notice that the "0" of the ruler across the top matches the left of the image.

2) I zoom in.  At this point, CenterPoint has still not changed (as expected).

3) I use the scrollbar to manipulate the view.  Now CenterPoint has changed (as expected).  Notice that the ruler across the top (which is bound to CenterPoint) moves along with the image.

4) I begin to zoom out.  For the first portion of the zoom operation, we're moving "straight back" and CenterPoint isn't changing - but once we hit the 'edge' of the image, the zoom operation actually is changing where the view is centered.  I would expect CenterPoint to change accordingly - but it doesn't.  Notice that the position of the ruler across the top no longer corresponds correctly with the image.

5) Now that we're zoomed all the way out, you can clearly see that the "0" of the ruler does not match the left of the image.  If I briefly grab the image with the mouse, CenterPoint finally gets updated - and the ruler (which is bound to it) is again correct.

Is this a bug?  If so, how can I work around it?

Comments (5)

Posted 8 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

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?


Actipro Software Support

Posted 8 years ago by Justin Klein
Avatar

>>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...).

[Modified 8 years ago]

Answer - Posted 8 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

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.


Actipro Software Support

Posted 8 years ago by Justin Klein
Avatar

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) ;)

Posted 8 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Justin,

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


Actipro Software Support

The latest build of this product (v24.1.1) was released 1 month ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.