You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Bear with me as I'm not a Swift programmer otherwise I'd make a fix for this.
This code though has a preset hard limit for 25 labels. The number of labels that can be displayed is something that is relative to screen size. 25 labels may be too many for an older iPhone and it is wasting capability of an iPad Pro display. This is the offending code from AxisBase:
@objc open var labelCount: Int
{
get
{
return _labelCount
}
set
{
_labelCount = newValue
if _labelCount > 25
{
_labelCount = 25
}
if _labelCount < 2
{
_labelCount = 2
}
forceLabelsEnabled = false
}
}
There is no simple way for someone to override this as internally this code uses _labelCount directly, so if you manage to override this method in a subclass and assign that class for use, the replacement for labelCount won't be called internal to the rest of the class. So you'd basically have to override every method where the _labelCount is being accessed because of the > 25 and = 25 hardcoded assignments.
There are two stages of suggestions here... the first is simple, this hardcoded max limit should be a separate variable that the user can set. So if I want to max out at 50 labels let me change the max, then compare in here vs. the max instead of 25.
I'm guessing this would patch it for the simple case and work as it is by default, while letting someone set a more reasonable number for their app. This will offload the calculation then to the app programmer about what is going to fit.
fileprivate var _labelMax = Int(25)
@objc open var labelMax: Int
{
get
{
return _labelMax
}
set
{
_labelMax = newValue
}
}
@objc open var labelCount: Int
{
get
{
return _labelCount
}
set
{
_labelCount = newValue
if _labelCount > _labelMax
{
_labelCount = _labelMax
}
if _labelCount < 2
{
_labelCount = 2
}
forceLabelsEnabled = false
}
}
The second suggestion would be to pick the number of labels to display based on available screen real estate instead of simply hard coding a limit. More work than this patch but it is the next logical step.
The text was updated successfully, but these errors were encountered:
What did you do?
25+ labels in horizontal bar charts
What did you expect to happen?
Should be able to handle more than a preset hard coded limit for labels gracefully.
What happened instead?
Labels didn't display.
Charts Environment
Charts version/Branch/Commit Number: 3.0.4
Xcode version: 9
Swift version: 4
Platform(s) running Charts: iOS10
Demo Project
Bear with me as I'm not a Swift programmer otherwise I'd make a fix for this.
This code though has a preset hard limit for 25 labels. The number of labels that can be displayed is something that is relative to screen size. 25 labels may be too many for an older iPhone and it is wasting capability of an iPad Pro display. This is the offending code from AxisBase:
There is no simple way for someone to override this as internally this code uses _labelCount directly, so if you manage to override this method in a subclass and assign that class for use, the replacement for labelCount won't be called internal to the rest of the class. So you'd basically have to override every method where the _labelCount is being accessed because of the > 25 and = 25 hardcoded assignments.
There are two stages of suggestions here... the first is simple, this hardcoded max limit should be a separate variable that the user can set. So if I want to max out at 50 labels let me change the max, then compare in here vs. the max instead of 25.
I'm guessing this would patch it for the simple case and work as it is by default, while letting someone set a more reasonable number for their app. This will offload the calculation then to the app programmer about what is going to fit.
The second suggestion would be to pick the number of labels to display based on available screen real estate instead of simply hard coding a limit. More work than this patch but it is the next logical step.
The text was updated successfully, but these errors were encountered: