Thanks very much, that fixed all my issues. I was almost getting there by the way, was trying to do that by subclassing the layout and override the
So I have a comment about the current mouseWheelHandler after looking at the source:
The current stepSize in the code depends on the delta property which by default is 3 or -3, so it jumps 3 items up or down, because the delta is 3. A few months ago I asked for how to increase the mouseWheel speed and one of the answers was to addEventListener to systemManager for the mouseWheel with capture = true and boost it. I did that and set the delta to be 30 not 3. So if you are following my thinking.. this was working fine for my Scroller which had a group inside it, but for the List component the result was having not 3 steps but 30 steps and the List trys to jump 30 items not 3.
So do you think it's a better idea to set the stepSize to a fixed number in the scrollbars and just get the direction from the delta?
And one more question about the feature request:
I understand how difficult are the calculations for the default scroller behavior after looking at them.. especially when you have a virtualLayout on your hands too.
So it's great when scrolling lists and datagrids with fixed sizes, but it's definitely not smooth when it comes to scrolling content like the web browser scroller does - which is with a fixed amount. So with that feature request it will be definitely easier to alter the default behaviour to a "fixed stepSize" one, but I really think that it should be integrated inside the component, I mean just set a boolean value to switch between item scroll or fixedStep scroll, and when it is fixedStop scroll selected to also take in accout the stepSzie property which has default value 30 for example, which you can also alter.
I'm pretty sure many people use the fixedStep Scroll probably when not building a control panel for management but the web site presentation itself which should most of all provide a fluent user experience.
Do you think I should post a feature request about that ?
Hello again Shongrunden,
Please take a look at this very simple example I've provided following you way of customizing the vertical scroller to get the fixed scroll behavior.
http://filip.nedyalkov.net/ListScrollTest/ - view source enabled
I have one comment on this and probably one bug to report, so i need your opinion if you have the time, of course.
The comment: extending the VScrollBar is not enough to get the desired behaviour of fixed scroll in some cases as show in the example above. For the customization to be complete Scroller needs to be extended too and the same change applied but this time to the skin_mouseWheelHandler, because otherwise if you have the minViewportInset set to 20 for example in that 20 pixels the skin_mouseWheelHandler will work, not the VScrollBar one.
I have a question here: will this duplication be fixed in Flex Hero or later ? I mean in the source there is something mentioned about Scroller API...
The bug: open the example, if you hover with the mouse between the item renderers(20px gap between the text from the v layout) from after bla10 to bla 20, and scroll with the mouse wheel the event will be taken by the scroller skin not by the VScrollBar and if you scroll from bla1 to bla10 the mouse wheel event will be taken by the VScrollBar. I've tested to find out that this behaviour is only when mx:Text is used and I have no explanation for that at this point.
You can notice this in my example, because I've only customized the VScrollBar and it scroll by 10px on scroll, and when the skin takes the mouse wheel event it scrolls with the default behaviour which is to jump 3 items up or down.
Update to the previous post,
I can't extend the Scroller component cause the skin_mouseWheelHandler is declared private... is it possible at all to extend from SkinnableComponent and copy the Scrollers code and make it work ?
Would be great if you could show how to do that cause if it's possible, otherwise looks like I am stucked with finding solution for this as for now...
Yes, it's possible, I just made it work, it was very hard cause you have to extend so many things and apply the changes to the component classes: extend ListBase and copy List with changes to Scroller Class, extend BaseLayout and copy ScrollerLayout with changes to Scroller Class, extend SkinnableComponent and copy Scroller with changes to the ScrollerLayout class etc (I won't go in more details).
The conclusion is that to fix this bug with the fixed scroll behavior currenlty is very hard, of course you can set the minViewportInset = 0 and no gap for the layout, but that's not a real solution.
Shongrunden, what would you advice me to issue as feature request/s, bug ?
P.S. I will wait a few days if you could find the time to look at this and kinda confirm my thoughts and then will post in the adobe bug base.
@FM_Flame - Sorry for the late reply. Thanks for documenting your experiences here its quite helpful to see the issues you are running into.
Re: "I mean just set a boolean value to switch between item scroll or fixedStep scroll, and when it is fixedStop scroll selected to also take in accout the stepSzie property which has default value 30 for example, which you can also alter."
> This is interesting, can you file a minor enhancement request for this?
Re: "The comment"
> I'm not aware of this changing for Hero or in the future. I think the skin_mouseWheelHandler is required for when the mouse wheel happens on areas of the Scroller that aren't over the viewport.
Re: "The bug"
> Very interesting. It would be good if you could file a bug on this, but if it doesn't happen with spark text elements I'm not sure if this will be prioritized very highly.
Re: "I can't extend the Scroller component cause the skin_mouseWheelHandler is declared private"
> Seems like it might be good to make this method protected. Want to file a bug for this?
Re: "The conclusion is that to fix this bug with the fixed scroll behavior currenlty is very hard, of course you can set the minViewportInset = 0 and no gap for the layout, but that's not a real solution."
> Good feedback. Would the feature added in SDK-26432 have made this process any easier for you? If the bugs/enhancements I outline above are fixed would that be enough to make this process easier?
Hi, sorry I delayed the reply, I've got a lot of work here too. And thank you for really looking into this
So I will start with the things we can check right away:
1) ok, I will file a bug for skin_mouseWheelHandler is declared private, to set it to protected for the Scroller.
2) about the bug - if it doesn't happen with spark text elements, I just tested with spark RichText and it produces the same problem even earlier - in all gaps after bla 3, I will post bug for the s:RichText but will also say the problem persists in mx:text too.
Now the more heavy stuff:
1) So at the moment Scroller duplicates the keyDownHandler and skin_mouseWheelHandler functions with the only difference that it checks if the vertical scroller is visible, if it is it uses it's code, if it's not it uses the horizontalScrollBar code.
I think this duplication of functionality is confusing and not expected and when extending it doubles the changes one needs to make. When using the Scroller component knowing it relies on his 2 subcomponents - vertical and horizontal scrollBars I expect that he manages them, and so every event within the Scroller component should be passed to them, not handled by the scroller itself.
So my suggestion here for a fix is instead of duplicating the functionality in both functions i mentioned above, just redispatch the event to the appropriate scrollBar component and let it handle the event. If you do this that would also mean there's no need to declare those 2 functions protected cause everything will be handled by the scrollBars and their functions I can extend at the moment.
Of course I could be missing something cause I don't have the time to look through all of this and test if it works etc but looks like it's possible and logical to me. Let me know what you think, should I post this as enhancement request ?
2) Now about the feature added in SDK-26432 + my suggestion for enhancement.
I understand why you've added that and I have to tell that I managed to boost/decrease the delta a few weeks ago even without that method so maybe it's a little bit unnecessary but I guess the more options we have the better.
Let me tell you what I think the real problem is, cause some months ago when I was just starting to use flex that was one of my first kinda newbie question (http://forums.adobe.com/thread/636269?tstart=30)
So I took the advice here to bump the delta (to 30) with an event listener with high priority and I set it to the systemManager. Back then I didn't know there's a difference between using the Scroller with a group and datagroup. So I though hay, I will fix my problem for all of my site with this. Great!
I continued developing my app and then I used the list. I was very surprised when I had like 15 elements and with 1 scroll down it went to the bottom and 1 scroll up it went to the top... (actually it tried to scroll 30 items at a time cause of my delta bump).
The problem here is that at the moment the default behaviour of the scrollBars calculates the next index based on the delta. So the guy that complained here: SDK-26432 had problem only because the default delta is 3 and it jumps 3 items at a time not 1. So with your current fix you added one more option to fix the delta before the mouseWheelHandler takes action.
I will update my suggestion from my previous post with the solution below how I think things should be working so people are mostly happy and you have less questions asked how to do this or that about scrollers
Adding 3 properties to Scroller, VScrollBar and HScrollBar which the user can alter:
1) boolean value to switch between itemScroll or stepScroll - by default it should be itemScroll for datagroup and stepScroll for group
2) stepSize property which has default value 30 for example - when stepScroll is selected it will scroll 30px per scroll - this won't depend on mouse delta to avoid confusion
3) itemCount property which has default value of 1 - when itemScroll is selected it will scroll 1 item at a time - this won't depend on mouse delta to avoid confusion
Of course at 1) you can add one more option mouseScroll for example which would be working as at the moment and it would take in account the mouse delta and people should be fixing their problems with the mouseWheelChanging u added or bumping/decreasing the delta from an mouseWheel_eventHandler. I probably won't use this but... don't know maybe sometimes u need to keep some features for backward compatibility.
Should I feature request this Shongrunden ?
Thanks again for helping me sort out these things
Sorry for the long post again... it's hard to explain everything in a few lines...
I have 1 more suggestion but it's not as important as these discussions here. So I will get back to it as soon as we are done here and I have the time
"So my suggestion here for a fix is instead of duplicating the functionality in both functions i mentioned above, just redispatch the event to the appropriate scrollBar component and let it handle the event. If you do this that would also mean there's no need to declare those 2 functions protected cause everything will be handled by the scrollBars and their functions I can extend at the moment."
>> Interesting. Can you mention that in the bug you file for making those methods protected? You're right, that might be a better solution than making the methods protected (if it is possible).
"Heavy Stuff #2"
>> It sounds like this comes back to item-based scrolling vs. pixel-based scrolling and exposing an API to control which behavior to use and also exposing a way of controlling the distance scrolled whether that is x items, x pixels, or x NavigationUnits. I think this would be a great to file as a feature request.
>> Once you file these bugs please post the links to this thread so people can keep track of them.
Yes I will Shongrunden, thanks for sharing your opinion, I am floaded with work right now, I will do that as soon as I have some free time and post the links here, I haven't forgotten
The itemRenderes bug: http://bugs.adobe.com/jira/browse/SDK-29609 - Scroller VScrollBar's (and probably HScrollBar's) mouseWheel event wrongly handled by the Scroller not the VScrollBar.
The private declaration bug + the suggestion for enhancement: http://bugs.adobe.com/jira/browse/SDK-29610
The ScrollBars enchancement request: http://bugs.adobe.com/jira/browse/SDK-29611
Please let me know if you want me to add or edit something in these issues Shongrunden or just comment under them, thanks !