I’ve been working on scrollable containers for quite some time.
This was not an easy task: currently I’m in a deep refactoring of the framework.
What started this refactoring cycle was the forum question about the drop-down list, which was showing the horizontal scroll although it wasn’t needed.
This was due to native Unity ScrollView behaviour, which is pretty unpredictable in a sense of displaying scrollbars.
This version started to work OK, but this haven’t solve the processing order bug. However, I decided to use scrollbars and struggled with the desire of creating my own scrollbar control.
However, this didn’t last for a long: I finally decided to go for it, so now I’m working on my own scrollbar. This scrollbar is made of 4 buttons (track, thumb, up and down buttons) and finally solves the processing order bug.
The reason is pretty straightforward: I’m able to process each part of the scrollbar (each button) individually. Since eDriven.Gui renders only the mouse-overed control as a button, there’s no background controls to interfere with the button.
I’m also planning to get rid of Unity slider, and implementing my own.
This would leave eDriven working with only small number of (highly optimized) controls:
- GUI.BeginGroup / GUI.EndGroup
Here is the list of all controls (provided by Unity) for a reference.
Additionally, the styling also works great.
You will be able to target each of the 4 scrollview parts and style them individually (as buttons):
Since the rendering of a new scrollbar doesn’t reference additional parts by convention (grabbing them from the supplied skin as UnityGUI does) – the ScrollerSkin property is now gone.
You could of course still pick source skins for each style of the ScrollbarStyleMapper, as well as the “overall skin”. This allows the usage of up to eight different GUISkins (four for a horizontal and four for vertical scrollbar direction).