Steelseries Gauges for WD

I create my Carterlake Ajax pages uses a series of classes.

I have had a consistent non-ASCII character at the top of the html page for the gauges. I have solved the issue and post here in case others have this issue.

I think that the issue is caused by one of the files having been edited and saved as UTF-8, but that is only a guess.

Here is my function that creates the gauge portion of my page:

function makessGauges()
{

$gauges = $this->getIncludeContents("../gauges-ss/gauges-ssTO2.html");

//http://stackoverflow.com/questions/4057742/how-to-remove-efbbbf-in-php-string
/* detect the encoding, then convert from detected encoding to ASCII */
$enc = mb_detect_encoding($gauges);
$gauges = mb_convert_encoding($gauges, "ASCII", $enc);
$gauges = ltrim($gauges,"?");

$theBody = "<div id=\"main-copy\"><div align=\"center\">$gauges \n</div><!-- end align=\"left\" --></div><!-- end main-copy -->";
return $theBody;
}

So, I turn the non-ascii into ascii and it is then ? which I strip out. Seems like an ugly workaround, but hey it works!

getIncludeContents is:


function getIncludeContents($filename)
    {
        if (is_file($filename))
        {
            ob_start();
            require_once ( $filename);  // 2-25-12  changed to require_once since started getting redeclared errors  Strange!!!
            $contents = ob_get_contents();
            ob_end_clean();
            return $contents;
        }
        return false;
    }

The non-ascii characters did not appear if I just echoed out the return from the function and displayed it it fireFox with no html wrapping.

Hope this saves someone time.

Bill

Thanks, windy. As always, your help and support is most appreciated as well.

I had the same problem, but my approach was to modify the page and supporting files in order to validate as UTF-8 HTML5 compliant. It was an interesting learning experience, but right now I’m not about to subject the rest of my site to more of the same rigor.

I had seen your earlier message and it helped me identify the problem.

Bill

It is possible that I saved one or more of the files in UTF-8 with a BOM (I switched editors recently) I’ll check. The BOM is what you are seeing when the code is loaded as part of a non-UTF-8 page. The BOM should really not be required or be there.

Minor glitch with 1.6.4. Since you indicated that gauges.js was all that changed, that’s all I uploaded. However, my page is still indicating 1.6.3…

http://tiggrweather.net/wxgauges.php

…even though this is set…

var g_scriptVer = “1.6.4 - 2012-03-01”;

Tried different browsers, different OSs, and different machines. What dummy thing did I miss.

Thanks.

My page is showing 1.6.4. All I did was edit gauges.js for my specifics (gauge colors, etc.)
and upload it to my server. All other files remained the same as 1.6.3.

-Keith

That’s all I did, Keith. Very strange.

Now it’s working, and I didn’t touch a thing - honest! Can’t see 2 different machines, 2 different OSs, and 4 different browsers all failing like that.

Oh, well - maybe a nap will help… :roll:

Cross posted:

John your page loads as 1.6.4 for me. Got it stuck in your browser cache?

Mark,

Thanks for a great script, the gauges are awesome. http://jcweather.us/bruce.php Is it possible to make the tooltips either a little narrower or higher and if so, could you point me in the right direction so I can mess around?

Thanks again. - Jim

Hi,

I am getting a HTTP Request Failed 404 Retry In … seconds error. #-o
Page with the meters is loading but the meters do not load the data.
Any ideas what could be the problem. I set it up just like the other versions.

After many hours of testing & tinkering with SteelSeries Gauges, wxgraphs & jpgraph, I have finally managed to get my gauges up and running together with the pop-up graphs…

http://www.spireweather.co.uk/?page_id=2201

I would just like to thank Jacco for starting this thread, and Mark for his unending hard work, and anyone else in this thread and the wxgraphs thread that has helped me out directly or indirectly. This is a fantastic companion to Weather Display that has transformed my site, and I could not have achieved any of this without this forum. =D>

Regards,

Did you remember to comment out the Cumulus custom text file line and uncomment
the WD custom text file in gauges.js? I’ve made that mistake before and got the failed
404 notice.

-Keith

Jack,

Thank you very much, that solved the problem. :lol:

John,

I experienced similar phenomenon before I made the fix suggested by Jack. One time they were there, the next they were gone. I thought that maybe all the php scripts did not finish running for wxgraphs to build the graphs.

Watch out for those headaches, you will make some goofy mistakes like i did :oops:

I hope you get it all straightened out.

Nope. As mentioned above, can’t see that happening on 2 different machines, 2 different OSs, and 4 different browsers. Besides, I cleared the caches. And, as mentioned below, it just started working by itself. I know, I know… :?

Jack,

Still have the headache, but at least it’s working.

Excellent! :smiley:

Jack

Just a couple of question: -

My pop-up graphs look stretched compared to the graphs on my wxgraphs test page. Is there a way to size the images?

Also, especially for us WD users, there is quite a lot of editing of gauges.js each time a new version is released. What is the possibility of having a settings file from which gauges.js gets what it needs, that survives an update? I presume it’s necessary to update ALL the SteelSeries files each update, unless specified otherwise?

EDIT: Another thing I’ve noticed this morning on my iPhone’s small screen is that the pop-ups can be truncated off the side of the web page. See http://www.spireweather.co.uk/?page_id=2201. Is there any way this can be controlled, so that they’re always centred for example?

Thanks,