Is it possible to know, when a FlipView is sliding back or forth, what item is currently on screen? The only relevant event I can see is SelectionChanged, which only gets raised when the FlipView comes to a rest and not if the person is quickly flipping through multiple items. I want to implement a "page number" indicator that changes even when the FlipView has not come to a rest. I'm using C++/CX.
You could check the ScrollViewer that is part of the control template of the FlipView. To get hold of the control - you would use the VisualTreeHelper to scan the visual tree looking for it. Then perhaps the ScrollViewer's ViewChanged event would let you see if the FlipView was manipulated.
If all you want to do is show a page number, you could DataBind the TextView displaying the number to the FlipView's SelectedIndex property. You'll need to create a ValueConverter that adds 1 to the SelectedIndex, but that'll only take a minute.
Related
I want to load more data when user scroll to bottom of LongListSelector or ScrollViewer (contain longlistselector).
I have search some stackoverflow question but it's not solve my problem
Here is a good post about Detecting **LongListSelector’s scrolling to the bottom. You can have Reference from here Detecting WP8 LongListSelector’s end of scroll (stretching)
Try this Implementation for calling calss function:
var _list_compress = new WP8PullDetector()
_list_compress.Bind(LongListSelectorName);
_list_compress.Compression += _list_compress_Compression;
I am using Daniel Vauchan solution with ScrollViewerMonitor from this blog post: http://danielvaughan.org/post/Scroll-Based-Data-Loading-in-Windows-Phone-7.aspx
Where is also sample code availiable http://danielvaughan.org/file.axd?file=2011%2f1%2fDanielVaughan.ScrollViewerMonitor.zip
It was developed for ListBox in WP7, but still works fine with LongListSelector in WP8. Just be careful with scenarios which involve Navigation between pages, because this code uses DependencyPropertyListener class and subscribes to listener.Changed event every time your LongListSelector will be Loaded. So you have to manually detach listener.Changed when Navigating from your page.
As an alternative you can try to use Telerik RadDataBoundListBox. It's rather good and supports Infinite loading from the box.
UPDATE:
It seems, that LongListSelector doesn't contain ScrollViewer. ScrollViewer is inside Listbox. However there is ScrollBar inside LongListSelector and its Value Property and ValueChanged event. You can detect scrolling to bottom with scrollbar valuechanged event with checking that ScrollBar Value is more or equals ScrollBar.Maximum. (You can add some constant to improve scroll to end detection).
Have a look a this link from Windows Phone Blog. I haven't tried it personally but have bookmarked it for future. Let me know if it is useful.
How to create an infinite scrollable list with LongListSelector
Now I'm developing windows phone 8.1 app with WinRT
I'm trying to support swipe-right-to-go-back gesture in my app.
I try to capture the manipulation events on my page. My page's root is a grid and have a ListView inside. I used the UIElement.AddHandler method with "handledEventsToo=true" to add the event handlers. But when I touch the screen, only the ManipulationStarting event is fired, other events seems to be eat by listview.
Could anyone tell me about the manipulation event behavior or other methods to implement this feature? Thanks!!
You won't normally capture events on LisView, beacause it has a ScrollViewer which intercepts them.
There is a way to do it - you will have to disable ScrollViewer and then perfrom some actions when the events are fired and perform scrolling manually. This answer will guide you.
In case someone encounters this page, I spent the better part of a week figuring out why manipulation events were only firing half the time on my UWP charts using the winRT xaml toolkit.
You may need to check that the background is not null on whatever element has the event handler attached. Templated controls are not necessarily hit test visible unless they have one. Otherwise, the input can go right through to the element behind it.
https://msdn.microsoft.com/en-us/windows/uwp/xaml-platform/events-and-routed-events-overview
I feel like I'm missing something obvious. I have an application which uses the 'IsSelected' property of GridViewItem to indicate that an item has been selected. When I'm using the application on a desktop computer (no touch devices) and I right-click on the item, it becomes selected. Take the same program and put it on a Surface and I can find no gestures that will select it. Swipe-down, press-and-hold; nothing seems to do the work that the Right-Click does on the desktop.
Anyone have any ideas what might be missing?
OK, got the answer and it's not pretty. In my code, I had attempted to subclass the GridView with my own control called ContentView. In XAML there is no subclassing of standard controls (you can't use the 'BasedOn' to pick up the style of built in controls) so my ContentView was not picking up the styling of a standard GridView. However, after pulling apart the standard style I've discovered the two critical features are:
IsSwipeEnabled - Must be set to true for swiping to work on the item.
ScrollViewer.VerticalScrollMode - Must be disabled so the scroll viewer doesn't try to interpret the swipe motion as a command to scroll downward.
After that, swiping to Right-Click works easy as pie.
I get what you are asking. It seems counterintuitive, huh? In this situation, my preference is to enable item clicking and use item clicking to set the selected item. If find this to be the most intuitive for users. Start with this XAML:
<GridView IsItemClickEnabled="True" ItemClick="GridView_ItemClick" />
And then simply do this:
private void GridView_ItemClick(object sender, ItemClickEventArgs e)
{
var grid = sender as GridView;
if (grid.SelectedItems.Contains(e.ClickedItem))
grid.SelectedItems.Remove(e.ClickedItem);
else
grid.SelectedItems.Add(e.ClickedItem);
}
It should work for SelectionMode Single and Multiple just fine.
Does that make sense?
// Jerry
I simply cannot find a way to get a ScrollViewer to share manipulation events. As soon as I put something inside a ScrollViewer and then set that items ManipulationMode, the ScrollViewer stops working
I have read that the ScrollViewer handles all of these events and stops them bubbling up, but there MUST be a way to get around this without disabling the ScrollViewer's scrolling behaviour.
I am very simply trying to implement a horizontal swipe feature on items in an ItemsControl, which is inside a ScrollViewer. (I have disabled the ScrollViewer's Horizontal scrolling mechanisms to no avail)
Without the ScrollViewer wrapped around it, everything works fine.
Any ideas anyone ? I cannot believe that this simple UI gesture cannot be implemented.
Many thanks
Dean
You can use a ListView to get the built-in cross-slide/swipe behavior if that's what you need. Otherwise - the last time I had to implement dragging out of a list - I put a rectangle in front of the ScrollViewer and captured all input events and then manually handled ScrollViewer scrolling. It's a bad idea, but there is no better choice yet.
I am porting a Desktop WPF application to WinRT and I'm facing a little issue.
I had a ItemsControl and I had a context menu on every item to delete / edit the item.
I have been told that PopupMenu are not good in WinRT and I should use a AppBar.
I think I'm doing something wrong or I misunderstood that.
I thought that I could put that options on a AppBar and when I select an element, popup the bar and click where I need.
The problem is that the AppBar will show up when I right click on any part of my app, so that buttons will show up with an item selected.
So can I change the layout of the AppBar on different contexts (because it seems that Microsoft wants us to use AppBar as context menu without context capabilities) or only show it when I want via code?
Would be good to have a TopAppBar with some App-wide options and a BottomAppBar just for ListView's item context menu.
Or maybe I'm doing all this stuff wrong and I have to use another approach to put extra options on the Listview's items.
You are thinking about this correctly. AppBar is the place where you should put all your non-essential and selection based commands.
The guidelines here and here suggest that they should be arranged as follows:
Navigation commands should be in TopAppBar
Commands related to selection should on the left side of BottomAppBar
The rest of page specific commands should be on the right side of BottomAppBar
Contextual commands should only be shown when a relevant item to that command is selected. For that purpose you should set Visibility of these commands accordingly. Also AppBar should open automatically when an item with contextual commands in it is selected. You can do that programmatically by setting its IsOpen property. You should also set it to sticky mode by via IsSticky property.
If you're using MVVM you can bind your viewmodel properties to all Button and AppBar properties mentioned above.
There's a CustomAppBar control available in WinRT XAML Toolkit. I haven't used it myself yet but it has a couple of extra features that might prove useful in your case.