I am trying to use a
ScrollBar to get pages of data back from a WCF service to display on a Grid View. We only get back one page worth of data at any time given the sheer volume
of data, so we need to identify the current “Index/position” of the scrubber/thumb on the
ScrollBar. Until Beta 2, we were able to use the
MouseLeftButtonUp
event to know that “dragging” had finished and then issue our data request for data relative to the new thumb location. Now our only option appears to be using the
ValueChanged event, which fires off numerous requests to our service causing massive network congestion.
One forum post I read said the following should be possible, but I can’t get this to work either.
Thumb thumb = (Thumb)scrollbar.FindName("VerticalThumb");if
(thumb != null){thumb.DragStarted
+= newDragStartedEventHandler(thumb_DragStarted); thumb.DragCompleted +=
newDragCompletedEventHandler(thumb_DragCompleted);
Hello, an element in a ControlTemplate has its own name scope. You won't be able to use FindName on the ScrollBar to find the Thumb. You need to modify the ControlTemplate of the ScrollBar (which is very easy to do in Expression Blend), and add event handlers
directly on the Thumb in XAML. Or if you don't want to override the ControlTemplate, you can use VisualTreeHelper to find the Thumb, but that's more work.
shanaolanxing - I'll transfer to the Windows Azure team, and will have limited time to participate in the Silverlight forum. Apologize if I don't answer your questions in time.
It appears that the MouseLeftButtonUp event is well and truely swallowed by the controls code behind! I could add a Mouse Down event, but not a mouse up.
In fact, saying that.. a better idea would be to use a timer to run for a second upon the value changing, then if it encounters the change event being fired again, restart the timer, and keep doing so until the value is not changed for a second, then fire
off the request to your service.
At least until somebody notices that the vital events for a slider have been removed and puts them back..
As I understand it, this change in event bubbling (which is really screwing up everybody) was made to make things more like WPF. Does anyone happen to know if/how the situation is any more tolerable in WPF? I think I read somewhere that WPF has some mechanism
that SL doesn't for getting access to these events, but I can't find any specifics about it or plans to add it to SL.
Yup. WPF has Preview*** events, which are tunneling events. If you don't know already, there're actually three routing strategies in WPF.
Bubbling: The route starts from the smallest element, such as a TextBlock, and bubbles along the route until the RootVisual of the application. Most RoutedEvent use this strategy. For example, MouseLeftButtonDown uses the bubbling strategy. So if a Control,
such as Button, marks this event as handled, the event will no longer bubble to its parent, thus you can't handle it any longer in your UserControl.
Tunneling: the route starts from the RootVisual of the application, and then tunnel along the route to the smallest element, such as a TextBlock. Therefore, even if a Button marks such an event, such as PreviewMouseLeftButtonDown, as handled, its parent,
such as your UserControl, can still handle it. But on the contrast, if your UserControl marks this event as handled, the event will no longer tunnel to the UserControl's children, thus the Button can no longer handle it.
Direct: the event doesn't route. It's just a plain old CLR event. For example, in Windows Forms, there're only CLR events. Thus if you handle the Click event on a Button, the underlying Form will be unable to handle this event.
WPF also provides class handlers, which allows you to handle RoutedEvent that has already been marked as handled. Unfortunately, as a subset of WPF, Silverlight doesn't provide any of those convenience. That is, currently Silverlight doesn't support the
full stack of RoutedEvent. The only routing strategy supported is bubbling. If you need the direct strategy, just use a plain old CLR event. If you need the tunneling strategy, unfortunately there's no workaround...
That being said, in the RTW time, we'll open up the various On*** methods. Currently they're private, in the future, they'll become protected. So you can subclass the built-in Controls and handle the events. In versions post Silverlight 2, we may also consolidate
the RoutedEvent model to support tunneling strategy, but I can't give you any promise at this time...
Meanwhile, in Beta 2, you'll have to write a ControlTemplate for the Control and handle the relevant events.
shanaolanxing - I'll transfer to the Windows Azure team, and will have limited time to participate in the Silverlight forum. Apologize if I don't answer your questions in time.
Thanks for the great explanation. That was really, really helpful! Seems "class handler" is what I was thinking of, and there's all kinds of info about this stuff in the WPF docs.
Good ideas "flyte" - I had implemented a proxy/tunnel to stop multiple events firing - but then I realised I could create my own scrollbar by inheriting the Slider and adding a few more components.
http://silverlight.net/forums/p/17446/68961.aspx#68961
Then I can replace the Scrollbar on my Grid with this one and hopefully I am all set!
Dave Britton
Member
695 Points
231 Posts
Beta 2, ScrollBar and MouseLeftButtonUp workaround?
Jul 02, 2008 09:57 PM | LINK
I am trying to use a ScrollBar to get pages of data back from a WCF service to display on a Grid View. We only get back one page worth of data at any time given the sheer volume of data, so we need to identify the current “Index/position” of the scrubber/thumb on the ScrollBar. Until Beta 2, we were able to use the MouseLeftButtonUp event to know that “dragging” had finished and then issue our data request for data relative to the new thumb location. Now our only option appears to be using the ValueChanged event, which fires off numerous requests to our service causing massive network congestion.
One forum post I read said the following should be possible, but I can’t get this to work either.
Thumb thumb = (Thumb)scrollbar.FindName("VerticalThumb");if (thumb != null){thumb.DragStarted += new DragStartedEventHandler(thumb_DragStarted); thumb.DragCompleted += new DragCompletedEventHandler(thumb_DragCompleted);}
Anyone else have any good workarounds?
Thanks,
Dave
Vertigo
Yi-Lun Luo -...
All-Star
25149 Points
2759 Posts
Microsoft
Re: Beta 2, ScrollBar and MouseLeftButtonUp workaround?
Jul 04, 2008 11:30 AM | LINK
Dave Britton
Member
695 Points
231 Posts
Re: Beta 2, ScrollBar and MouseLeftButtonUp workaround?
Jul 07, 2008 06:53 PM | LINK
It appears that the MouseLeftButtonUp event is well and truely swallowed by the controls code behind! I could add a Mouse Down event, but not a mouse up.
Any other workarounds?
Vertigo
Flyte
Member
14 Points
8 Posts
Re: Beta 2, ScrollBar and MouseLeftButtonUp workaround?
Jul 07, 2008 10:43 PM | LINK
Just a cheap way to lower network congestion; use a timer to only fire off requests every second or so, instead of every time it changes value.
At least until somebody notices that the vital events for a slider have been removed and puts them back.. [:^)]
Flyte
Member
14 Points
8 Posts
Re: Beta 2, ScrollBar and MouseLeftButtonUp workaround?
Jul 07, 2008 10:48 PM | LINK
In fact, saying that.. a better idea would be to use a timer to run for a second upon the value changing, then if it encounters the change event being fired again, restart the timer, and keep doing so until the value is not changed for a second, then fire off the request to your service.
tgrand
Participant
790 Points
175 Posts
Re: Beta 2, ScrollBar and MouseLeftButtonUp workaround?
Jul 07, 2008 10:57 PM | LINK
As I understand it, this change in event bubbling (which is really screwing up everybody) was made to make things more like WPF. Does anyone happen to know if/how the situation is any more tolerable in WPF? I think I read somewhere that WPF has some mechanism that SL doesn't for getting access to these events, but I can't find any specifics about it or plans to add it to SL.
Yi-Lun Luo -...
All-Star
25149 Points
2759 Posts
Microsoft
Re: Re: Beta 2, ScrollBar and MouseLeftButtonUp workaround?
Jul 08, 2008 04:41 AM | LINK
Yup. WPF has Preview*** events, which are tunneling events. If you don't know already, there're actually three routing strategies in WPF.
Bubbling: The route starts from the smallest element, such as a TextBlock, and bubbles along the route until the RootVisual of the application. Most RoutedEvent use this strategy. For example, MouseLeftButtonDown uses the bubbling strategy. So if a Control, such as Button, marks this event as handled, the event will no longer bubble to its parent, thus you can't handle it any longer in your UserControl.
Tunneling: the route starts from the RootVisual of the application, and then tunnel along the route to the smallest element, such as a TextBlock. Therefore, even if a Button marks such an event, such as PreviewMouseLeftButtonDown, as handled, its parent, such as your UserControl, can still handle it. But on the contrast, if your UserControl marks this event as handled, the event will no longer tunnel to the UserControl's children, thus the Button can no longer handle it.
Direct: the event doesn't route. It's just a plain old CLR event. For example, in Windows Forms, there're only CLR events. Thus if you handle the Click event on a Button, the underlying Form will be unable to handle this event.
WPF also provides class handlers, which allows you to handle RoutedEvent that has already been marked as handled. Unfortunately, as a subset of WPF, Silverlight doesn't provide any of those convenience. That is, currently Silverlight doesn't support the full stack of RoutedEvent. The only routing strategy supported is bubbling. If you need the direct strategy, just use a plain old CLR event. If you need the tunneling strategy, unfortunately there's no workaround...
That being said, in the RTW time, we'll open up the various On*** methods. Currently they're private, in the future, they'll become protected. So you can subclass the built-in Controls and handle the events. In versions post Silverlight 2, we may also consolidate the RoutedEvent model to support tunneling strategy, but I can't give you any promise at this time...
Meanwhile, in Beta 2, you'll have to write a ControlTemplate for the Control and handle the relevant events.
Flyte
Member
14 Points
8 Posts
Re: Re: Beta 2, ScrollBar and MouseLeftButtonUp workaround?
Jul 08, 2008 02:25 PM | LINK
Ah, thanks for the explanation.
But could you point us in the direction of any tutorials, or briefly explain what you mean by writing a ControlTemplate?
Thank you [:)]
tgrand
Participant
790 Points
175 Posts
Re: Re: Beta 2, ScrollBar and MouseLeftButtonUp workaround?
Jul 08, 2008 03:10 PM | LINK
Thanks for the great explanation. That was really, really helpful! Seems "class handler" is what I was thinking of, and there's all kinds of info about this stuff in the WPF docs.
Dave Britton
Member
695 Points
231 Posts
Re: Re: Beta 2, ScrollBar and MouseLeftButtonUp workaround?
Jul 08, 2008 03:40 PM | LINK
Good ideas "flyte" - I had implemented a proxy/tunnel to stop multiple events firing - but then I realised I could create my own scrollbar by inheriting the Slider and adding a few more components. http://silverlight.net/forums/p/17446/68961.aspx#68961
Then I can replace the Scrollbar on my Grid with this one and hopefully I am all set!
Vertigo