While tinkering with Gantt charts, I noticed that using navigator and dependency arrows sometimes behaves weirdly depending on the current zoom.
On this fiddle (hopefully, for you too), when fully de-zoomed, the dependency arrow splits and sometimes disappears (though it seems to happen intended because it happens when the start date of the task gets out of the "view").
This doesn't seem to be happening when removing the min and maxattributes of yAxis in the chart configuration, in this demo, but doesn't seem to always fix it
But, for instance, if you add the navigator to the "Interactive Gantt" demo, the bug still happens.
Does anyone have an idea ? I don't think I saw an Issue about that on the git repo.
This issue was reported on Highcharts github and it is already resolved, see: https://github.com/highcharts/highcharts/issues/10804
As mentioned there it is expected to be included in the next maintenance version v7.1.3.
Related
vuejs
apexcharts
Hi, I have an issue and not sure if it was a bug or I have missed for some configuration. Currently I'm flowing the Timeline Charts here. I have to enable for the label, and you can see when the time of a task have passed, or not met (by dragging the chart), but the label of hide item is still visible and be stacked with visible label
Issue example 1
Issue example 1
Any body got the same issues yet and how to resolve it? I don't think it's a bug because obiviously no one expected this behavior, right?
I have tried for most of the configuration in the dataLabels but nothing kind related to this. Feel free to drag the chart to see the issue clearly. The code is basically a demo from Apexchart demo, not modify much. You could easily download the original code here: https://apexcharts.com/vue-chart-demos/
Demo for the issue: jsfiddle.net/xhieu2206/quvzaxk9
P/s: after checking for a jsfiddle of the same usecase in React, it work normally without any configuration, so seem like it's a bug from Vue Apexchart team, please correct me if I was wrong (hopefully ...) ...
Demo in react: jsfiddle.net/xhieu2206/3fzb60ar/2/
Editted: the issue happened with react too:
demo: jsfiddle.net/xhieu2206/3fzb60ar/2
enter image description here
We have upgraded our higstock version from v1.2.5 to the latest (v1.3.9).
We have had to do many minor tweaks and changes, which we have now sorted to make it work as it did before, however, there are a couple of issues that remain and are proving hard to resolve.
The first is rounded end points on one of our bar charts;
postimg.org/image/6uqvr5szd
(The highlighted end points used to be flat and not overlap)
postimg.org/image/426uym7eh
(How it looks in old version (preferred))
The second (which seems like it could be related) is as follows;
postimg.org/image/n0gyaz9cr
(Again more roundedness)
postimg.org/image/yuncfy43b/
(How it looks in old version (preferred))
I have checked borderRadius, symbol, marker settings etc. etc. but nothing obvious is causing these issues.
Furthermore we have many other types of charts which all seem to be fine.
NB:
The second issues are an attempt at a basic Gantt chart as described by Torstein Hønsi in this post;
http://highcharts.uservoice.com/forums/55896-general/suggestions/804783-gantt-chart
(I would also have added the images here, or the links, but StackOverflow forbid it because of my low reputation!)
As always, any help appreciated.
I have tested with various graphs and this seems like a consistent problem.
I have a highstock graph, if you draw a lot of data and zoom out to the full view of the graph by using the sliders or the range selector, the whole graph draws all messes up.
I found an example fiddle that illustrate the issue.
http://fiddle.jshell.net/highcharts/qgprf/show/
I've used Chrome to get the path that highstock generated and then plotted just the path:
http://jsfiddle.net/MsFhh/
It's obvious that highstock is creating some tomfoolery.
For the sake of stackoverflow, here's some code
alert("I R code"); //Copying the huge svg path in here is kinda insane
Is there something that I can do to fix this?
PS: if I upgrade to the new highstock version, everything in our graphs breaks so updating is not an option :(
This is known bug of Highstock 1.3.0, alread y fixed in 1.3.3+. Reported here. You can modify sources to fix issue, or upgrade to latest version.
If you have issue with upgrading - let us know what kind, and we will try to fix them. Of course working fiddle with that issues is really appreciated.
The bug has been fixed. The fix for version 1.3.5 can be found here:
https://github.com/highslide-software/highcharts.com/issues/1651#issuecomment-25226662
Don't use the patch though. It doesn't fully fix the issue. It seems like 1.3.6 fixes everything that were causing the defect.
The patch can be seen here:
https://github.com/highslide-software/highcharts.com/commit/9607afd512473710b6aeb9bfceaf23549d285ff0
After upgrading from d3 3.1.9 to 3.1.10, animations on my d3 svg visualizations broke.
My guess it's related to this commit (removal of old functionality), and that I'm using an old api.
https://github.com/mbostock/d3/commit/d9659b6794fa1985c756d2a7d8ee73174e54ee08
Even the most simple transition fails (moving a group element 75 pixels to the right):
d3.select('g.slider').transition().duration(500).attr('transform','translate(100,0)');
I have similar transitions on other elements that will start the same time as above transition. Could there be a conflict where transitions cancel each others, even though they're on completely different elements? I hope I'm just using the (new?) API the wrong way?
Please note that it all worked great on 3.1.9. I've tried following this guide from Mike (transitions with d3.js 3), but the api looks the same, so I'm stuck:
http://bost.ocks.org/mike/transition/
edit: I'd be surprised if I'm the only one experiencing this issue. All visualizations with animations I've created over the years with d3 stopped working when moving from 3.1.9 to 3.1.10
Please use GitHub issues to report bugs.
And please create a full example that demonstrates your unexpected behavior rather than quoting a code snippet out of context. I can’t reproduce the behavior you’ve described. Here is your snippet working correctly inside a full example, http://bl.ocks.org/mbostock/b4e46124258d1b75accb:
slider.transition()
.duration(1000)
.attr("transform", "translate(100,0)");
D3 has thousands of tests and hundreds of examples, many of which include transitions and animations, and none of which were affected by this change. Do all of your visualizations use this obscure, undocumented feature in d3.timer? I’m very surprised that this change affected your code, and I definitely don’t expect it to be widespread.
Please followup on GitHub issues if you are still experiencing unexpected behavior and can provide more detail for me to investigate.
For anyone else having issues with transitions in d3 >= 3.1.10, I was loading date.js library which breaks d3.js due to overloading the Date.now() method.
I suggest not to use date.js, but here's an issue which aims to have d3 do something more graceful instead of silently failing.
See this d3 issue: https://github.com/mbostock/d3/issues/1302
I use Highcharts 2.2.5 to draw a number of area and bar charts.
I Just upgraded my app to jQuery 1.8 and started testing all my charts.
All appear ok, but when I zoom an area chart, I get tons (literally hundreds) of JavaScript errors saying "Error: Problem parsing d=0.99030204037363" (numbers change, sometimes d=1) and on the screen all I see are a bunch of dots where the chart was.
Resetting the zoom doesn't work either (yielding more errors, and no result). The only recourse at that point is to reload the page.
I tried looking online for any clashes between HC 2.2.5 and jQuery 1.8 but couldn't find anything. Switching back to jQuery 1.7.2 solves the problem, but still, one must look ahead...
Any assistance is appreciated,
Guy
After reporting the bug on github, per #MrObrian's suggestion, I got this reply:
It is already fixed for the next release - see
http://jsfiddle.net/highcharts/GJ4wR/. We're running the final tests
on that code now, hope to have it out by next week.
So all I have to do is wait 1 week :)