[efraga]

Thank you. I have finally had the chance to apply the workaround your team suggested for this issue and it appears to be working.

It would however still be nice if this could be fixed at some point so we can remove our workarounds. Thank you for considering this for a future release.

[efraga]

I can confirm that the .toFixed issue is indeed fixed in the latest StockChart v1.6.7.

To work around the problem with zooming into open-ended regions I had to use the following code in the end:
const viewportMinimum = this.canvasStockChart.charts[0].axisX[0].get(“viewportMinimum”);
this.canvasStockChart.charts[0].axisX[0].set(“minimum”, viewportMinimum, false);
const viewportMaximum = this.canvasStockChart.charts[0].axisX[0].get(“viewportMaximum”);
this.canvasStockChart.charts[0].axisX[0].set(“maximum”, viewportMaximum, true);

This is effectively saying: if you can see it (ie. it is part of the viewport) then you should be able to zoom into it.

It would perhaps be more intuitive if this was the default behavior of CanvasJS. Something to perhaps consider for a future release.

For anybody else reading this. It is also important to remember that the above code needs to be executed every time after a render since the axisX array gets overwritten each time.

[efraga]

I was able to reproduce the problem. It seems to happen when the following 3 conditions are true:
(1) There aren’t any dataPoints (yet). Please keep in mind I am loading data progressively so this would be normal.
(2) A minimum and maximum value has been set for the X axis.
(3) xValueType: “dateTime”

You can observe the problem with the following fiddle:
https://jsfiddle.net/jcmalek/a7Lorh18/85/

[efraga]

So if I understand correctly, the zoom reset button only goes back to the last call to stockchart.render().

This would seem to work against the ability to do live updates as suggested by your example:
https://canvasjs.com/docs/charts/how-to/live-updating-javascript-charts-json-api-ajax/

The moment a live update comes in, the end user looses the ability to reset their zoom to anything before the last update (due to the stockchart.render() call).

Consequently, I would like to make a feature request that the zoom reset button’s history extend beyond the last call to stockchart.render() so that resetting the zoom actually works with live updates.

[efraga]

Yes, I will see if I can reproduce this in a fiddle at some point when I have some free time.

In the meanwhile, I did just give you the exact line in the canvasJS source that is causing the problem and instructions on how to fix it. Could you perhaps forward the fix to your developers?

[efraga]

So I’ve run into another bug in CanvasJS trying to get this to work.

It looks like there is a problem handling Dates on line 18304 of canvasjs.stock.js:

ERROR TypeError: (intermediate value)(intermediate value)(intermediate value).toFixed is not a function
at Axis.CanvasJS.Chart.Axis.createLabels (c:\Users\CMalek\Desktop\Web-Client\src\assets\canvasJS\canvasjs.stock.js:18304:81)
at Axis.CanvasJS.Chart.Axis.createLabelsAndCalculateHeight (c:\Users\CMalek\Desktop\Web-Client\src\assets\canvasJS\canvasjs.stock.js:18992:1)
at Function.CanvasJS.Chart.Axis.setLayout (c:\Users\CMalek\Desktop\Web-Client\src\assets\canvasJS\canvasjs.stock.js:19200:1)
at Chart.CanvasJS.Chart.Chart.setLayout (c:\Users\CMalek\Desktop\Web-Client\src\assets\canvasJS\canvasjs.stock.js:5228:1)
at StockChart.CanvasJS.StockChart.StockChart.setChartsLayout (c:\Users\CMalek\Desktop\Web-Client\src\assets\canvasJS\canvasjs.stock.js:27341:1)
at StockChart.CanvasJS.StockChart.StockChart.render (c:\Users\CMalek\Desktop\Web-Client\src\assets\canvasJS\canvasjs.stock.js:26909:1)
at HistoryComponent.renderChart (c:\Users\CMalek\Desktop\Web-Client\src\app\history\history.component.ts:1041:27)
at HistoryComponent.processDataPoints (c:\Users\CMalek\Desktop\Web-Client\src\app\history\history.component.ts:1036:12)
at Object.next (c:\Users\CMalek\Desktop\Web-Client\src\app\history\history.component.ts:645:16)
at Object.next (http://localhost:4200/vendor.js:150422:21) {stack: ‘TypeError: (intermediate value)(intermediate …t (http://localhost:4200/vendor.js:150422:21)’, message: ‘(intermediate value)(intermediate value)(intermediate value).toFixed is not a function’}

The problem appears to happen when “i” is a Date object. “i + this.interval” consequently does string concatenation instead of addition as I believe was intended. For Dates I believe the desired behavior would be new Date(i.getTime() + this.interval).

There also seems to be way to much happening on this single line. I highly recommend splitting it into several statements instead for readability and debug-ability. Something similar to the following might be a good starting point:

for (var j = firstBreakIndex, i = this.intervalStartPosition; i <= endPoint; ) {
var intermediate = this.logarithmic && this.equidistantInterval ? i * Math.pow(this.logarithmBase, this.interval) : (i instanceof Date ? new Date(i.getTime() + this.interval) : i + this.interval);
i = parseFloat(this.interval < 1E-12 || intermediate instanceof Date ? intermediate : intermediate.toFixed(12));
etc.

[efraga]

The latest version is working for me thanks. Guess it was something mainly in the fiddle.

[efraga]

After further thought. It sounds like this is maybe just some naming confusion with the names of these functions. I’ll use the dynamicUpdate property of the navigator as suggested.

You may wish to consider clarifying their names to better reflect their actual difference in usage? Maybe something like rangeChangingAutomatic and rangeChangingManual or similar. And also perhaps fix/update/eliminate the event.type parameter since it doesn’t sound like it provides much value or was a remnant of an old implementation.

[efraga]

Ok. Thanks. I guess something in the implementation changed since the code was working previously. I’ll switch to the other methods you suggested and upgrade to the latest stockcharts.

[efraga]

Yes, it makes sense why that wasn’t working now. I’ll adjust my code accordingly.

However, it could be nice if the chart’s automatic maximum/minimum calculation automatically took into account the navigator maximum/minimum. I was assuming that if a user was allowed to navigate into a certain region that they should also be able to zoom into that same region on the chart which I believe would be a reasonable assumption from a usage perspective.

You could perhaps consider this a minor bug or feature request.

Either way, this is no longer a priority for me as you suggested a simple workaround. Thanks!

[efraga]

Yes, thank you. I am aware that there are a few other ways I could potentially work around the problem. You could perhaps consider this a feature request as it would be a much better user experience if the navigator automatically zoomed into small regions (as implied by the documentation).