Leaderboard

Since I didn't set a lower limit on interest. Here is a ZIP file with the project and demo SVG and HTML files. It's crude, but works. Some things about the project: 1. The script file for the SVG demo is www\libraries\webpanel.js file. There is a line of code in that scipt that is: var ipAddr="LocalHost"; This line of code must be edited to replace LocalHost with the IP address of the server when serving the file in which this script is embedded. If you just want to test it by opening the WebPanelTest.svg file from the disk using Chrome, it must be set to localhost if you have your LV server enabled. You could make a VI that edits the webpanel.js file and sets the IP address on startup. 2. If you want to server the SVG file from the LV web server, you will need to add the following mime type to the C:\Program Files\National Instruments\LabVIEW 2009\resource\webserver\mime.types file: image/svg+xml svg svgz On the cRIO, the mime.types file is in the ni-rt\system\webserver folder 3. To test the SVG panel, open the LV 2009 project and run the SVGDemo.vi. Open the www folder, right-click the WebPanelTest.svg file, and select Open With > Google Chrome (you must install Chrome 8 or 9 first) Watch the panel update from the VI. Use the slider to move the dial indicator. 4. To test the RGraph Library Example, open and run RGraph Demo.vi. Open RGraphdemo.html using Chrome. You will need LV 2009 minimum for this demo. I'll keep watch here and try to answer any questions that are posted. I really would like to get an open-source project started based on this idea of a common SVG format for free Web UI controls/Indicators. If everyone pitches in a little, it could progress quickly and drive a stake through the heart of NI's misguided Silverlight adventure. Too bad about the security issue confusion, but from what I read, it seems to be a proxy issue that affects Flash and Java, as well as WebSockets. I hope Mozilla.org wasn't too hasty in disabling WebSockets in FF Beta 8. WebPanelLava.zip

You are correct as it is not really "code" it is an application. The code will not work unless it is compiled into an EXE (mercurial cannot call a vi directly). It cannot be run as source nor is it useful to call it as source from another application (not an API). Thought I would make it easy on users by not requiring them to download and compile the tool in order to use it. I for one dislike downloading free applications from the web that do not have a compiled application packaged in an install.For those looking to make updates to the source code and performing their own builds, they can contact me via PM and I can send them a link to a public mercurial repository that they can pull down. I will put a warning in the description.