Within a WP7 app I am generating a Scrollviewer within the code. This Scrollviewer has a StackPanel as its content and within the Stackpanel I have a grid.
I have not assigned any specific heights to these controls.
As far as the look and the behaviour I am after, all is fine.
I now want to position the scrollviewer to a certain point - after I have generated it and its children.
It seems that the ScrollViewer.ScrollToVerticalOffset method is what I should be using.
But I cannot ascertain the height of the Scrollviewer... both Height and ActualHeight are returning 0. I want to use this height to determine which point I should be scrolling to.
And even when I hardcode a ScrollToVerticalOffet value then it still doesn't reposition itself.
Is there a way that I can get this to position as I want, and how can I determine the height values?
thanks
Got it working ok when I checked for values in the Page loaded event... and the ScrolltoOffset seemed to work fine there too.
Related
I have several controls in a ScrollViewer which when printed should span multiple pages both horizontally and vertically. My current solution uses a series of scrolls (both in horizontal & vertical direction) to achieve the printing.
For this implementation to work the content of the ScrollView needs to be disassociated and added to a new ScrollViewer (the new instance of ScrollViewer is adjusted to PrintWidth and Height to achieve the print objective), as a result the original view will be emptied. To overcome this problem, I have tried Cloning the entire ScrollViewer, but this seems to fail with bindings - DataGrid is displayed empty in the cloned visual.
Is there any other approach where the visual elements can be printed, or, are there any other approach (perhaps using VisualBrush) to achieve the objective of multi page print?
This question already has answers here:
WPF DataGrid : CanContentScroll property causing odd behavior
(2 answers)
Closed 9 years ago.
Both are quite general terms but I'm curious to know when these height will be different apart from the case we're using Virtualization?
One more question:
I read on MSDN:
If CanContentScroll is true, the values of the ExtentHeight, ScrollableHeight, ViewportHeight, and VerticalOffset properties are number of items. If CanContentScroll is false, the values of these properties are Device Independent Pixels.
However I'm facing an issue with ViewPort Height: I've 2 listbox in application:
1. Which have Virtualization Enabled and CanContentScroll = True.
2. Which have no virtualization and CanContentScroll = True.
In ListBox 1 while drag-drop Viewport Height comes to 4/5 (Number of elements currently visible). However in ListBox 2 i get Viewport Height equal to Actual Height of Listbox.
Why this difference?
Few more findings:
1. Scrollable Height is number of items not visible in scrollviewer
2. Viewport Height is number of items visible in scrollviewer.
Thus Viewport Height + ScrollableHeight = Extent Height
Can someone please explain what's the difference between two listboxes? I need ViewPort hieght in case of Listbox 1
the ActualHeight is the actual height of the ScrollViewer. The Viewport is what is visible from the ScrollViewers Content. So to answer your question: ViewportHeight differs from ActualHeight if the horizontal Scrollbar is visible by the Height of the Scrollbar.
so, to sum this up:
ActualHeight = ViewportHeight + HorizontalScrollbarHeight
Finally This was the root cause:
Quoting from https://stackoverflow.com/a/3062692/3195477:
You are encountering the differences between physical scrolling and
logical scrolling.
As you have discovered, each has its tradeoffs.
Physical scrolling
Physical scrolling (CanContentScroll=false) just goes by pixels, so:
The viewport always represents exactly the same portion of your scroll
extent, giving you a smooth scrolling experience, and but
The entire contents of the DataGrid must have all templates fully
applied and be measured and arranged to determine the size of the
scrollbar, leading to long delays during loading and high RAM usage,
and It doesn't really scroll items so it doesn't understand
ScrollIntoView very well Logical scrolling
Logical scrolling (CanContentScroll=true) calculates its scroll viewport and extent by items instead of pixels, so:
The viewport may show a different number of items at different times,
meaning the number of items in the viewport as compared to the number
of items in the extent varies, causing the scrollbar length to change,
and
Scrolling moves from one item to the next and never in between,
leading to "jerky" scrolling
but
As long as you're using VirtualizingStackPanel under the hood, it only
needs to apply templates and measure and arrange the items that are
actually visible at the moment, and
ScrollIntoView is much simpler since it just needs to get the right
item index into view
Choosing between them
These are the only two kinds of scrolling provided by WPF. You must
choose between them based on the above tradeoffs. Generally logical
scrolling is best for medium to large datasets, and physical scrolling
is best for small ones.
A trick to speed loading during physical scrolling is to make the
physical scrolling better is to wrap your items in a custom Decorator
that has a fixed size and sets its child's Visibility to Hidden when
it is not visible. This prevents the ApplyTemplate, Measure and
Arrange from occuring on the descendant controls of that item until
you're ready for it to happen.
A trick to make physical scrolling's ScrollIntoView more reliable is
to call it twice: Once immediately and once in a dispatcher callback
of DispatcherPriority.ApplicationIdle.
Making logical scroll scrollbar more stable
If all your items are the same height, the number of items visible in
the viewport at any time will stay the same, causing the scroll thumb
size to stay the same (because the ratio with total number if items
doesn't change).
It is also possible to modify the behavior of the ScrollBar itself so
the thumb is always calculated to be a fixed size. To do this without
any hacky code-behind:
Subclass Track to replace the calculation of Thumb position and size in MeasureOverride with your own
Change the ScrollBar template used for the logical-scrolling ScrollBar to use your subclassed Track instead of the regular
one
Change the ScrollViewer template to explicitly set your custom ScrollBar template on the logical-scrolling ScrollBar
(instead of using the default template)
Change the ListBox template to use explicitly set your custom ScrollViewer template on the ScrollViewer it creates
This means copying a lot of template code fom the built-in WPF
templates, so it is not a very elegant solution. But the alternative
to this is to use hacky code-behind to wait until all the templates
are expanded, then find the ScrollBar and just replace the ScrollBar
template with the one that uses your custom Track. This code saves two
large templates (ListBox, ScrollViewer) at the cost of some very
tricky code.
Using a different Panel would be a much larger amount of work:
VirtualizingStackPanel is the only Panel that virtualizes, and only it
and StackPanel to logical scrolling. Since you are taking advantage of
VirtualizingStackPanel's virtualization abilities you would have to
re-implement all of these plus all IScrollInfo info function plus your
regular Panel functions. I could do something like that but I would
allocate several, perhaps many, days to get it right. I recommend you
not try it.
They can differ from the point of (specified) Height being evaluated to any given time during the (ongoing) rendering process.
From MSDN:
There is a difference between the
properties of Height and Width and
ActualHeight and ActualWidth. For
example, the ActualHeight property is
a calculated value based on other
height inputs and the layout system.
The value is set by the layout system
itself, based on an actual rendering
pass, and may therefore lag slightly
behind the set value of properties,
such as Height, that are the basis of
the input change.
Because ActualHeight
is a calculated value, you should be
aware that there could be multiple or
incremental reported changes to it as
a result of various operations by the
layout system. The layout system may
be calculating required measure space
for child elements, constraints by the
parent element, and so on.
I have some problems with implementing autoscrolling in WPF (I think I could call it that way).
I have a canvas placed inside a scrollviwer. On my canvas I can dynamicly add different shapes. The position of this shapes can be changed with mouse. Everytime I add new shape on canvas or change position of shape I fire measureOverride function.Thanks to this scrollview "know" the real size of canvas and the scrollbars appear. However even if scrolbars appear, the view doesn't "follow" shape which I currently move. I mean if I reach visible part of canvas I would like canvas to srcoll.
I was trying to use this function
ScrollToHorizontalOffset()
However I have problem with proper use of that function. I was trying to use (as a parameter) canvas actualwidth but it didn't work well. I also was trying to use as a parameter current position of shape (which I move) but it works only one way. I the viewer follow the moving element if I was moving this element to right side of canvas. However if I move shape back(to the left) the view don't follow the shape.
I hope somebody will understand this :) It is hard to explain my problem.
I also was trying to use as a
parameter current position of shape
That is the correct way to implement. Waht you need is a converter, which will returns the position according to the direction you move the object.
I have a question regarding the setting of the HorizontalOffset-property (using the ScrollToHorizontalOffset method).
Upon starting my application, the content for the scrollviewer is dynamically created (i.e. I do not know its extent during design-time). I then want to set the horizontal offset of the scrollviewer control, however at that time its scrollable width is returned as 0. Calling UpdateLayout on the scrollviewer does not help either.
I am currently working around this issue by checking the ScrollableWidth property of the scrollviewer control in the rendering event and make a call to ScrollToHorizontalOffset as soon as ScrollableWidth > 0.
This works fine but leads to a short display of the wrong inital position, before in "rendering" the position is adjusted.
Is there anything I can do to force an update on the scrollviewer so that I can set its horizontal offset without this hassle?
Thanks in advance!
Set the opacity of the Content control in the scroll viewer to 0. When you've called ScrollToHorizontalOffset then set the content control's opacity to 1. That way no content is actually seen until its positioned correctly.
Scrollable Height/Width will be zero until the child content is loaded. Until then, it doesn't know how big it needs to be - thus the value of 0.
Been checking the web and this site, but couldn't come up with any descent results.
Is there a way to make a canvas in WPF show scrollbars on overflow ? Been trying the scrollviewer, but can't get it to work :(
Thanks in advance..
The problem you're running into is that Canvas, unlike many WPF panels and containers, does not size to contents. That means if you add an element which goes outside the canvas boundaries it will not update it's size. Hence embedding a Canvas in a ScrollViewer will do no good unless you manually update the size of the Canvas.
It sounds like what you want is a Canvas which supports size to contents. This blog entry has exactly that control.
http://themechanicalbride.blogspot.com/2008/11/auto-sizing-canvas-for-silverlight-and.html
I took a different approach and abandoned the Canvas for Grid. The Canvas is more performant but for my purposes at least I haven't noticed a difference. The grid can mimic the behavior of canvas by doing the following.
Create a single row,single column grid.
Set the HorizontalAlignment to Left
Set the VerticalAlignment to Top
Use Margin "x,y,0,0" to set the position.
Bam..works just like canvas and it works great in a Scrollviewer.