I am using the LongListSelector from the Mango Silverlight toolkit.
But I need to be able to set 'MaximumFlickVelocity' and 'BufferSize' but neither do anything.
For example:
<toolkit:LongListSelector IsFlatList="True" MaximumFlickVelocity="10" BufferSize="5" IsBouncy="False">
The properties there have no effect at all, except 'IsFlatList'.
Thanks.
EDIT: I just noticed in the documentation that all the properties I need at marked as Obsolete. So could anyone tell me what alternatives I have? Because the performance on this isn't great at all.
It depends on the kind of list you have. If you can afford to load more items into the list, as the user scrolls to the bottom of the list, you can use the StretchingBottom event on the longlistselector.
The property IsBouncy defaults to true in the latest release, so StretchingBottom is fired everytime the user scrolls to the bottom and then some.
In essence, you can play with the events and the ItemsSource property to improve the performance in an extremely long list. Well, I am not sure if it will be of much help, but it`s worth a try.
Good luck.
Related
I try to migrate my iphone app to wp7.
On ios, UITableview is well designed, and very easy to code.
I have the some book about wp7, but there are no detail concerned about moving and removing of a row of listbox.
Welcome any comment
I'd like to think that Windows Phone is also well designed. :)
To simply remove an item from a ListBox in your codebehind, you need to get a reference to the ListItem that you want to remove. For example, to remove the currently selected item:
var myListItem = myListBox.SelectedItem;
Then you can remove it with:
myListBox.Items.Remove(myListItem);
In order to address your question about moving items, we'd need to know more about how you're populating the ListBox. Are you using databinding, or adding items with myListBox.Items.Add(myListItem)?
If I needed to move items between two lists, I would create a public List<MyItem> property for each list and databind each list to its own ListBox. Then I might do something like this (working from memory here):
var itemToMove = myList1.Remove(myListBox1.SelectedItem);
myList2.Add(itemToMove);
myListBox1.DataBind();
myListBox2.DataBind();
There's a much better way to do this, using INotifiyPropertyChanged, but I suspect you need to play around with the basics for a while to get comfortable in C#.
Bonus tip: Windows Phone is very similar to Silverlight, and you can usually find more information if you search for Silverlight examples.
In WP7, usually we set the ItemSource of listbox, when our source changes its changes automatically propagate to the UI due to data binding ( it is known as one way binding ; source to UI ).
so what ever you do ( add, update or delete) in itemsource, it reflects to UI.
databinding in wp7
when i use pivot with in the panorama .pivot are used as a gallery view. i want to move pivot when i swipe it .but the problem is this because of both panorama and pivot are the same gesture event so both are they move .
i want swipe only my pivot view .
I would like some sample code or any other suggestion to do this.
so please give me a solution for doing this and
also give me a link where i easily understand this. Thanx in advance
You shouldn't have a Pivot in a Panorama control. End of discussion.
I believe it is achievable, because I've already solved similar issues with having WebBrowser control inside a custom horizontal-scrollable overview container like Pivot/Panorama, but believe me, it is NOT worth it. I've had to dig very deep into the visualstructure of the controls and attach my own manipulation-handlers to their viscera, manually choose which horiz/verti events to pass and which to cancel, and so on. This is not so easy, takes a lot of time, and doesn't guarantee that on the end you will have something behaving in a way you wanted to achieve in the first place. If you are not bound by some contract to preserve the shape of the UI, please, drop the idea and redesign your UI, just to save on your sanity and nerves.
But, if you are already insane or really want to dig where noone should, start on analysing your UI as a two rectangles: large pano and small pivo, and think which part should behave how on different possible touches/h-v swipes/h-v pans/pinches/so on. Write it down just to for reference, or soon you will probably start making small mistakes that will interfere with your understaning of the flow of the events.
I've checked the version I have, and "my" Panorama uses internally the UIElement.ManipulationXXXX events. In that case:
Display visualtrees of your UI and try attaching manipulation-events to every control. In those events, write/log which control's which handler was invoked. Then make some swipe/scroll on your APP and observe events. Analyze how they were bubbling and try cancelling (e.Handled=true) the manipulation-completed and/or manipulation-delta events somewhere between pivot and panorama. Your goal is to have the panorama see that e.Handled=true, while your pivot must see e.Handled=false. Your Pivot will probably see the event sooner than the Pano, so that point should be relatively easy.
If it fails to work, then you should check your version of the Pano, and check how it detects movements. If, for example, it uses the GestureListener - try the same trick with it. Etc.
And remember, you can always make your own horizontal-overwiew-container that will look like Pano, behave like Pano, and that will work with Pivo better - because it will be your code and you will tell it what and when to move. if you want to go this way, start on google and check all the preliminary Panorama previews that random people have published before that control was published by MS.
I want to put help buttons on all my windows, like this:
But when I put the help button in, the minimize/maximize buttons disappear. Does Windows forbid having the min/max buttons together with the help buttons? That would be disappointing because that would mean I could put the help button only on dialogs and not on frames.
If Windows does forbid this, it would be nice to see an official Microsoft document which talks about this policy.
It is not possible through setting windows styles. If you really wanted to you could set some hooks that would probably let you do what you want, but I would not recommend doing that. You can mimic the functionality of the help button by sending the WM_HELP message.
According to MSDN, the styles WS_MAXIMIZEBOX and WS_MINIMIZEBOX can not be combined with WS_EX_CONTEXTHELP.
Although it is true what daalbert says, with some effort it is indeed possible to draw just about anything properly on the window frame. Of course this is in no way "official" and the limitation that daalbert mentions still stands.
You can listen for WM_NCPAINT and draw the button yourself with the help of DrawFrameControl with DFC_BUTTON (which makes sure it will look like the real thing). Use WM_NCHITTEST and friends (WM_NC*BUTTON*) to find out whether the button you draw gets clicked.
So yes, it's technically possible to achieve what you want but usually not worth the extra effort.
Just wanted to have this on record for completeness.
In my opinion, ListPicker list items are unacceptably small tap targets; certainly their height is smaller than the minimum size recommended by the style guide Microsoft published, and fact that Microsoft has taken to presenting the list full-screen in a much larger font suggests that I am not alone in holding this opinion.
I would like to use this full-screen big-font presentation in my own UI designs. I have tried specifying a DataTemplate (as a static resource) but it didn't seem to have any effect, although I'm pretty sure it is processed because when I made a typo in the resource name the compiler complained.
On what basis do you say that the item tap target size is too small? Is this personal opinion or based on user feedback?
If you don't like default style of the ListPicker then retemplate it.
You can use the ItemCountThreshold property to control whether FullMode is always used or not (set it to 0).
You can also apply a full mode template to increase the touoch target size of what is displayed there.
I was using ListPickerItem objects for the items. This works until there are enough items to trigger Full mode and then it barfs.
If I import the System namespace and use String objects, everything's hunky dory. Supplying a DataTemplate and binding to something also works.
I think I have found a bona fide bug, but one with a trivial workaround: don't use ListPickerItem.
Is there any way to control the threshold of the flick action to on/off a toggle switch so that it doesn't mess with the pivot control's navigation?
Sorry, but I'm going to avoid you're question (I can't answer it anyway) and suggest you use a different approach.
You could (I assume) use a checkbox to just as easily provide the option to the person using the application. Afterall a toggle switch has the same functionality as a checkbox (specify/choose between two states) it just implements the interaction differently.
The toggle switch has not been designed/built (AFAIK) to support being used on top of something which also supports the same gesture.
As a general rule of usability, having controls on top of each other (or even next to each other) which support the same gesture is likely to cause problems for the user. Even if the problems are through accidentaly triggering the wrong gesture or expectations about how their gesture will be interpretted.
In summary: this is a really tricky problem to solve; I don't think you can with the controls as they are; and the problem goes away entirely if you use a different control for toggling anyway.
I've had the same problem with my codermate, we've been digging this for many hours and we finally reached the top of the hill and we came up with a solution.
This solution works for the bing map control:
on mouse enter: myMapControl.CaptureMouse();
on mouse leave: myMapControl.ReleaseMouseCapture();
And there you go, when you'll navigate inside the map the pivot won't do transition ;)
If you don't get the point, just poke me and I'm going to explain with real code (I'm quite busy right now).
Cheers
This solution posted recently seems to be working out for people for dealing with gesture conflicts on pano / pivot. You might like to check it out.
Preventing the Pivot or Panorama controls from scrolling
Set the IsHitTestVisible = false in your root pivot control
The solution to this is simple, and comes from my experience with Android and iPhone application development.
simply make sure you only tap into the OnMouseLeave event - not the OnChecked or the OnMouseClick as these will accidentally fire just by touching the toggle.
You want make sure that they were touching it when they let go of the screen, and this (unless you put the toggle on the edge of the screen will almost never be the case