Another bug fix/enhancement submission

Share RGraph:   To help my Google visibility (it can't get much worse!), if you like and use RGraph I'd appreciate it if you could link to me

« Back to message list

Enter your email address to get email updates on this topic. You can stop receiving updates by clicking the link in the update email messages.

Posted by James Parsons on 3rd August 2014
I found another bug. This bug affect y-axis labels. It reveals itself when the number of labels has been mathematically calculated rather than hard-coded. If the calculation gets a small rounding error (e.g. 8.000000000001 instead of 8), RGraph will draw an extra label. It is probably due to a for loop somewhere. Example:

for (i=0; i<numlabels; i++) { // Treats 8 differently than 8.00001

Now a strong argument could be made that the bug is actually in the code of the person using RGraph (me) because they should have ensured they were passing in an integer, rather than a float. That said, RGraph can be made more robust by validating the input.

The following simple code change in RGraph.common.core.js, line 177 (in both the June and July stable releases), fixes the problem.

Add an extra line of code, so:

var numlabels = typeof(opt['ylabels.count']) == 'number' ? opt['ylabels.count'] : 5;


var numlabels = typeof(opt['ylabels.count']) == 'number' ? opt['ylabels.count'] : 5;
numlabels = Number(numlabels.toFixed(0)); // Ensure that numlabels is an integer

In fact, it may be worthwhile to perform a similar check anywhere a user-supplied chart property MUST be an integer.

I have only tested this with my own code.

Add a reply

« Back to message list