rvats

Javascript Charts: Getsvg() Call Errors Second Time Around

Recommended Posts

After upgrading to SR3 for Fusion Charts XT, we are facing issues when calling getSVG() twice on a chart object:

 

First issue:

 

First call:

this.jsVars.hcObj.getSVG()

(returns the SVG string correctly)

 

Second call on the same chart:

this.jsVars.hcObj.getSVG()

(throws a javascript error in the console)

 

This happens because of the call to chartCopy.destroy() in the getSVG() method:

// get the SVG from the container's innerHTML
svg = chartCopy.container.innerHTML;
// free up memory
options = null;
chartCopy.destroy(); (THIS CALL CAUSES THE ISSUE)
discardElement(sandbox);

 

Commenting out that call fixes the issue for now, but we would like the memory to be recollected ideally.

 

Second issue:

 

The getSVG() method returns the visibility property incorrectly:

  • In Chrome, the SVG string has: visibility="" which is incorrect since the property cannot be blank (fixed by: .replace(/visibility=""/g, ''))
  • In IE, the SVG string has just prop1="val1" visibility prop2="val2", which is incorrect syntax (fixed by: .replace(/ visibility /g, ' '))

Edited by rvats

Share this post


Link to post
Share on other sites
Guest Sumedh

Hi,

 

We are working on this issue.

 

We will update you on this, as it will be fixed.

Share this post


Link to post
Share on other sites

I can confirm that this is still present in Fusion Charts Suite Nov 2012 : calling getSVGString() on the same chart twice results in a JS error shown below

var svgstr = FusionCharts(cid).ref.getSVGString();

 

Share this post


Link to post
Share on other sites

Hi,

 

I can confirm that this is still present in Fusion Charts Suite Nov 2012 : calling getSVGString() on the same chart twice results in a JS error shown below

var svgstr = FusionCharts(cid).ref.getSVGString();

 

 

Please note that we had found a fix which seemed to have been breaking the link of other implementations.

 

Hence, we are probing further into analysis and come up with a solution that would not affect the other implementations. We shall update you once we come up with the solution.

 

Thank you for your continued patience and support.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now