How can I find the component in a ScrollViewer that handles the RequestBringIntoView event?
It isn't exposed on the two ScrollBar parts (not directly, anyway).
Thanks for any pointers...
UPDATE: Related: Can I get the ScrollContentPresenter part of the ScrollViewer? How?
Thanks --
Bigger picture:
We have a large Canvas contained in a ScrollViewer. At runtime, an arbitrary number of UserControls (I'll call them 'Blobs') are added to the canvas from the db. Their position and content come from the db. A user can 'select' a blob by clicking on it, and its appearance changes to indicate it is selected.
If the user uses a scrollbar to move the selected blob out of view, then clicks on another blob, the Canvas is scrolled so the previously-out-of-view blob is in view again. I assume this is due to some object raising the RequestBringIntoView, and the ScrollViewer is handling it.
Hope this makes sense...
Yet more info:
Added a handler (sb_ValueChanged) to the Scrollviewer's scrollbar ValueChanged event. Here's the stack from the mouse click that precipitates the scrolling:
OurControl.sb_ValueChanged() System.Windows.dll!System.Windows.Controls.Primitives.RangeBase.OnValueChanged() System.Windows.dll!System.Windows.Controls.Primitives.ScrollBar.OnValueChanged() System.Windows.dll!System.Windows.Controls.Primitives.RangeBase.OnValuePropertyChanged()
System.Windows.dll!System.Windows.DependencyObject.RaisePropertyChangeNotifications()
System.Windows.dll!System.Windows.DependencyObject.UpdateEffectiveValue()
System.Windows.dll!System.Windows.DependencyObject.SetValueInternal()
System.Windows.dll!System.Windows.DependencyObject.SetValue()
System.Windows.dll!System.Windows.Controls.ScrollViewer.InvalidateScrollInfo() System.Windows.dll!System.Windows.Controls.ScrollContentPresenter.VerifyScrollData()
System.Windows.dll!System.Windows.Controls.ScrollContentPresenter.ArrangeOverride()
System.Windows.dll!System.Windows.FrameworkElement.ArrangeOverride()
If only I could find out what the FrameworkElement that starts the mischief actually is...
Sorry... it doesn't seems to exist like it does in WPF. Check this link for a handy solution.
Update: Ok... for this you might need to walk the visual tree and some sort of recursive search need to be done. However, assuming you are using the default template for the scrollviewer as seen here, you can directly ask for the ScrollContentPresenter with something like this:
var BorderChild = VisualTreeHelper.GetChild(MyScrollViewer, 0);
var GridChild = VisualTreeHelper.GetChild(BorderChild, 0);
var ScrollContentPresenterChild = VisualTreeHelper.GetChild(GridChild, 0);
Related
I need to be able to animate drag and drop in my vertical list. I used vuedraggable, wrapped my list in a transition-group and it all worked sweet. Until I fetch new data from the server. Now because of the introduction of transition-group for a split second the old data and the new data live together in the DOM causing the expansion of the list and pushing subsequent div down and back up.
This is kind of expected per the docs:
the DOM operations for insertion and/or removal will be executed
immediately on next frame (Note: this is a browser animation frame,
different from Vue’s concept of nextTick).
Regardless of being able to drag and drop the element, if we were to fade in/fade out the new/old elements they will co-habitate for the time of the animation, which is not great as seen in this pen
Anyway to fade out, change the data, then fade in the new one, while maintaining the height of the list?
Note that without fade the problem is still obvious:
Pen of my issue: click the switch data button to see the issue.
Turns out it's pretty know issue. By reading through this thread and toying with this example, i was able to achieve something to my liking by using:
list-leave-active {
display: none;
}
Resulting Pen
A css fix may be to wrap the contents within a box of some height and set overflow hidden.
So, even when new elements co-exist the jump in scrollbar can be avoided.
I have a series of items in a GridView.
I want to animate the TranslateTransform of a GridViewItem so that it is outside the boundary of the GridView. When I do, it is clipped. Is this type of transform possible?
Sadly, I don't think so. I had to do something similar a while ago and it turns out that the template of a GriView (and ListView, ListBox, etc...) contains a ScrollViewer control. The thing about the ScrollViewer controls is that they MUST define a clipped viewport to give the user the impression of scrolling. In fact, if you were to decompile the ScrollViewer control, you can see that it hard codes the clipped bounds, so you cant even change the template or style.
Things may have changed since I looked into this, and my investigations where on WPF not XAML in Windows 8, but I dont think that it would have changed based on your description of the issue.
Here is a SO question in relation to this topic: WPF clipping even when no clipping is desired - how to turn it off?
I have created a Windows 8 Store App using C# / XAML. My interface includes a scrollable list, which is rendered using an ScrollViewer. I would like to be able to handle manipulation events on the elements within the list, however, setting ManipulationMode to anything other than None on the list element causes my list to no longer scroll.
Here is a simplified version of the UI:
<ScrollViewer>
<Border/> <!-- these contain child content -->
<Border/>
<Border/>
<!-- Set ManipulationMode on an element in order to receive manipulation events -->
<!-- This causes the scroll viewer to stop working! -->
<Border ManipulationMode="All"
ManipulationDelta="..."/>
<Border/>
<Border/>
</ScrollViewer>
I understand that the WinRT ScrollViewer uses a special ManipulationMode of System for performance reasons, but I would like to have a vertically scrolling list, containing elements that respond to horizontal manipulation / gestures. Can anyone think of a creative workaround that would make this possible?
it may be long time but didn't find any good solution. I just achieved what I wanted very easily.
public MovableGrid()
{
ManipulationMode = ManipulationModes.TranslateX | ManipulationModes.System;
AddHandler(ManipulationDeltaEvent, new ManipulationDeltaEventHandler(UIElement_OnManipulationDelta), true);
AddHandler(ManipulationCompletedEvent, new ManipulationCompletedEventHandler(UIElement_OnManipulationCompleted), true);
}
I wanted my MovableGrid to be moved on X axis and I have list of MovableGrids which I wanted to be scrolled with scrollviewer. That's enough to do that.
What I have done was I put a transparent rectangle on top of the ScrollViewer and handle manipulations there. When I find the manipulation should scroll the ScrollViewer - I scroll the ScrollViewer using the ScrollToHorizontal/VerticalOffset() methods. On ManipulationStarted I also use VisualTreeHelper.FindElementsInHostCoordinates to check which item I could manipulate too and then I can decide whether to manipulate that item or not depending on various conditions. It's quite a bit of custom code though. You would also need to update the RenderTransform of the ScrollContentPresenter in the ScrollViewer when the user tries to drag farther than minimum/maximum offset to immitate the ScrollViewer default behavior, handle mouse scrollwheel etc. Nothing YOU could not handle of course. I could not find a better way unfortunately and I am interested if someone finds one.
EDIT* Another solution I thought of when trying to answer another similar question was to use another ScrollViewer as a child item and use its ViewChanged events instead of manipulation events.
EDIT 2*
Also with Windows 8.1 you get ManipulationModes.System which combined with other modes should allow you to handle manipulations inside of a ScrollViewer. Then you can call CancelDirectManipulations() on the manipulated element once you want its parent ScrollViewers to stop processing manipulations for pan&zoom.
Very weird situation going on with a FlowLayoutPanel...
I have been dynamically adding user controls to my panel. This user control has a height of 105. If I have my FlowLayoutPanelwidth to only show 1 "column" of controls, it will only display 296 of them. The rest of the controls are grayed out at the bottom of the flowlayoutpanel. If I widen the flp to allow 2 "columns" of controls, I can see 592 of them, with the remainder grayed out at the bottom. I have gone in and resized the user control to make it shorter in height, which works in some respects (i.e. it works when I have two columns, but not just 1), and can go forward with this work-around.
So, I guess my question is, why does the FlowLayoutPanel behave in this fashion? It seems (based on what I saw) that there is a limit to how much data the FLP will show at one time.
Your comment just reminded me that when you're adding many controls to any container it is a good idea to do this:
YourPanel.SuspendLayout();
// populate panel with controls
YourPanel.ResumeLayout(false);
This in effect stops the container (panel) from re-rendering itself every time you add a control until you're done adding controls. In the very least your panel creation will be smoother and faster. Not sure if this might fix your issue or avoid the need for a hack with PerformLayout.
If you look at your Form's designer file you will actually see this in action in the InitializeComponent function.
I'm working on a UI for a WPF application. I have in my window Stack Panel with some Expanders inside. In each Expander are some controls, one being a List Box. What I want to do is have the List Box resize (shrink or grow) when the window is resized. At the moment, when I re-size, the expander are getting clipped off but the listbox (sometimes very long in height) remains unchanged. How do I go about making this happen.
A good example is in Outlook 2007, the "Mail Folder" on the left shrinks with window size but the other controls don't.
Thanks in advance.
The StackPanel won't push a height on its children - it allows each child to size as big as it likes. You might try using a Grid around the Expanders, and giving each Row a star height so that the contents resize.
Thanks Paul,
I've found something interesting myself.
I've extended the grid control with a simple method that fires when the expander is expanded, I would call this.
RowDefinitions[GetRow(expander)].Height = (expander != selectedExpander) ?
new GridLength(1, GridUnitType.Auto) :
new GridLength(1, GridUnitType.Star);
This worked very nicely.