The displayed results are reasoned in the fact that UISlider (among many other controls) in fact is composed of multiple subclasses which handle the drawing themselves. The results is a highly optimized display code which can not properly be overridden using drawRect: on the UISlider only. You would have to override several other, partially closed implementations of that composed control.
In fact, there is a much easier and much more performant solution which is providing the graphical elements you wish to customize to UISlider. A nice introduction on that subject can be found on Apple's conceptual introduction to Sliders.
There some smaller pitfalls though - one of them is the fact that a UISlider's thumb does not "like" to be replaced by something with a different size. Those are however covered by many tutorials - one of those would be how-to-make-a-custom-uislider.
As a rule of thumb: avoid subclassing and overriding drawRect: when possible by any means as it will vastly degrade the performance of your UI.
Instead look at solutions that make use of the UIAppearance protocol for controls that do not provide interfaces for customizing. UISlider however does provide them, so go for those.
This would be my approach priority list:
- Check very carefully if the control in question does allow customizing by providing images etc.
- Check if the control in question adheres to the
UIAppearance protocol.
- Use subclassing and possibly overriding
drawRect:
- When it turns out that the control in question appears to handle
drawRect: in a "weird" way, subclass UIView and recreate the missing logic yourself.
drawRect:) for customizing a slider. You can simply provide the graphic parts to its instance - seesetMaximumTrackImage:forState:and alike. For a complete tutorial on that subject, you may want to use (the first google hit) getappninja.com/blog/how-to-make-a-custom-uislider - TillUIView. - Till