docbee

Members
  • Content count

    12
  • Joined

  • Last visited

Posts posted by docbee


  1. Come on, there must be a way around this.

     

    During Load time it looks completely unacceptable with XT:

    post-21455-0-72544800-1350497371_thumb.png

     

    After load it looks fine:

    post-21455-0-15318700-1350497542_thumb.png

     

     

    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>


  2. Hi,

     

    Could you please try by increasing the chart's bottom margin?

     

    Ref. Code:

    <chart ... chartBottomMargin='18'>

     

    Thanks! I added "chartBottomMargin='18'" and it makes the Humidity bar thinner, exactly as I would like it,

    but it also cuts the value display of the pointer. It now looks like this:

    post-21455-0-67482700-1350292061_thumb.png

     

    Any idea of a solution that keeps the pointer value visible?

     

    code for humdity HLinearGauge now is:

    <chart bgColor='#000000' bgAlpha='100' showBorder='0' borderThickness='0' baseFontColo
    r='#dddddd'  lowerLimit='0' upperLimit='100' lowerLimitDisplay='' upperLimitDisplay='' numberSuffix='%'  decimal
    s='0' ticksBelowGauge='0' majorTMColor='#dddddd' majorTMNumber='2' minorTMColor='#dddddd' minorTMAlpha='0' place
    TicksInside='1' showTickValues='1'  showTickMarks='0' chartTopMargin='0' chartBottomMargin='18' chartLeftMargin=
    '10'  chartRightMargin='15' toolTipBgColor='#333333' dataStreamURL='' > 	<colorRange>    	<color minValue=
    '0' maxValue='100' code='#3399FF' label=''/> 	</colorRange> 	<pointers> 		<pointer value='0' showVal
    ue='1' color='#00ffff' radius='6' toolText='Humidity' /> 	</pointers>  </chart>


  3. 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.

     

    I could solve problems 1 and 2 in the meantime (although flash still acts different than javascript), but problem #3 remains.


  4. 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:

    post-21455-0-82255600-1350226171_thumb.png

     

    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.

    post-21455-0-53703700-1350226396_thumb.png

     

    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!


  5. 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?


  6. 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.


  7. 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.


  8. 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;
    }


  9. Could you please try giving the setting the value of the chart using:

    <value>980</value> and not inside the <chart> attribute

    I hope this helps.:)

     

    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.


  10. lower Limit is always set to zero instead of the value given.

     

    Example:

    <chart bgColor='#000000' bgAlpha='100' showBorder='0' borderThickness='1' 
      baseFontColor='#dddddd'  upperLimit='1040' lowerLimit='980' setAdaptiveMin='0' 
      numberSuffix=' hPa' refreshInterval='10' autoScale='0' cylHeight='250' cylRadius='10' 
      cylYScale='0' cylFillColor='#cd5c5c' ticksOnRight='0' majorTMNumber='13' 
      majorTMColor='#ffffff' minorTMColor='#ffffff' cylOriginX='70' cylOriginY='260' value='980.0'>
      <annotations>
    		<annotationGroup id='Grp5' >
      			<annotation type='text' x='57' y='290' fontColor='#cd5c5c' fontSize='11' bold='1'  label='Barometer' />
    		</annotationGroup>
      </annotations>
    </chart>

     

    Please also see attachemnt.

     

    Any ideas?

    post-21455-0-70771200-1316107001_thumb.png


  11. 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.