Profiles

Forums

Everything posted by docbee

I am in the process of migrating from an older fusion widget release to the new XT one.
My hope/expectation that old charting will immediately work as expected was a bit over-optimistic, i think...
Now I step throgh the problems one by one...
Problem 1: How do I supress the progress bar that appears when the chart loads?
As many widgets are loaded in
parallel that does not make sense, instead of that I have a self made loading bar. Question remains,
how can I get rid of the default chart loading progress bar that gets autmatically displayed while loading flash widgets?

Come on, there must be a way around this.
During Load time it looks completely unacceptable with XT:
After load it looks fine:
I guess there will be a trick making the divs unvisible dring load or something like that.
Link to the HTML: http://www.meteoplug...e4&engine=flash
As far as I understand HTML, the flash is rendered into a DIV set invisible.
Older versions of fusion widgets did a render without making it visible, letting it
to a piece of code from me to set the VID visible again, when I like to do so.
XT render command seems to set it visible automatically. Can I avoid this?
<body onload="timedCount()" style="background-color:#000000;">
<div id="divChart0" style="visibility:hidden"></div>
<script type="text/javascript">
var chart0 = new FusionCharts("../fusionwidgets.xt/Thermometer.swf", "ChId0", "84", "360", "0", "1");
chart0.setTransparent(true);
chart0.setDataXML("<chart showValue='1' bgColor='#000000' ....................... </chart> ");
chart0.render("divChart0");
</script>

Migrating my project to FusionWidgets XT does make progress. The Flash variant does look like it did before using XT,
but the Javascript variant still has some "bugs".
This is how it looks fine with flash:
Here is the link that generates the flash based html:
http://www.meteoplug...e4&engine=flash
When I switch to Javascript the marked bugs in layout occur:
1. TempGauges are located too much to the bottom
2. "Chill" Text is not positioned in line
3. Humidity HLinearGauge does not fit into container with given height 43.
Here is the link that generates the javascript based html:
http://www.meteoplug...5f2e4&engine=js
Tweaking the chart a way that it works ok for javascript but does no longer look fine with flash is not an option for me,
as my customers should have a consitent look and feel regardless what device/rendering engine they use.
Any hint is welcome!

Looks like Browser-specific "if-then-else" code behind "getChartFromId" in FusionCharts.js does not work properly with IE9.
I don't get the expected handle back. It works fine with old IEs, Firefox, etc...
Any idea what I should change in the following definition of FusionCharts.js to make it working?
infosoftglobal.FusionChartsUtil.getChartObject = function(id)
{
var chartRef=null;
if (navigator.appName.indexOf("Microsoft Internet")==-1) {
if (document.embeds && document.embeds[id])
chartRef = document.embeds[id];
else
chartRef = window.document[id];
}
else {
chartRef = window[id];
}
if (!chartRef)
chartRef = document.getElementById(id);
return chartRef;
}

Sorry, false alarm.
FusionCharts is fine with IE9, but the JavaScript I wrote for receiving data via "xmlhttprequest" were stuck by some kind of unexpected caching by IE9.
I did solve that by adding a timestamp to the requesting URL which makes the URL unique and disables caching as a wanted side effect.

Doing some more reading on the web it could also be, that the handle returned is fine, but IE9 is not willing to apply the feedData method of the flash object to it.
The code that throws the error is:
var chartRef = getChartFromId("ChId" + i);
chartRef.feedData(lines[i+1]);
Error message is "SCRIPT438: Object doesn't support this property or method"
Any ideas how to get that fixed? Handing over data to the flash applet does work fine with the other browsers.

I did some more testing with angular gauges and it turns out that the scala is as expected, when it is given a value in that range. This is a bit surprising, as I would not expect the scala to adjust to given sample values. can I inhibit this surprising behaviour?

Thanks for your posting. I did try and as expected this does not change the behaviour. Problem is not that the value parameter is not taken into account, but that "lowerLimit" does have no effect. You can easily try yourself with the code I have posted.
I tried to do a work-around by using the angular chart, but... you might guess it... the same bug.
I think it will need a bug-fix, where "lowerLimit" parameter is set back into operation. If you have a temporarily solution for me, that would also be great.

I have the same problem when using Thermometer widget with live data. When the called script does return 25.0 every thing works fine, if it returns 25 as integer I get the "not a number" error as mentioned above.
Looks like a bug to me. I have kit #95515, if you might want to check versions. I can do a work around by using float numbers, but I think this should be fixe in one of the next updates/bug fixe.