Leaderboard

I didn't include the HTML file in my zip because the Publish will create it, and then open it in the default browser. It's pretty self contained and has several improvements, but the core basics are the same. Glad you got it working, and glad I finally got around to testing it with a webserver.

What I did (not an expert BTW just like playing around) was from the XAMPP I clicked Explorer and searched for Dashboard. Notice that is the folder you are in in your browser. From there I found the root of my server was at: C:\xampp\htdocs So I ran the command mklink /J "C:\xampp\htdocs\Test" "C:\FP Publisher\www" This makes Windows create a folder called Test which points to the www folder where the webpage is actually created. Then from a browser you should be able to go to http://192.168.1.94/Test/Demo HTML5 Page.html and see the page at C:\FP Publisher\www\Demo HTML5 Page.html. Even if the VI isn't running you should see the page with static data. Then run the VI then refresh the page. Obviously update the path in the mklink call to be the location on your disk to where your www folder actually is.

My experience with this is that under Windows it is pretty easy and non-problematic but if you end up having numerous class hierarchy levels that depend on each other and build the various classes all into its own PPL you have to be careful if you do this for Linux realtime targets. For some reasons only known to I don't know who, if you for whatever reason rebuild one of the base class packed libraries you absolutely have to rebuild every depending class packed library or LabVIEW will start to complain that the depending classes can't be loaded. I have no idea what the reason is, I did assume that a packed library is an isolated container that only exports its public interface to the outside world, so as long as nothing on the signature of the public methods changes this should be a no-brainer, but that doesn't seem to be the case for NI Linux RT targets. I didn't seem to have these problems on Windows nor VxWorks realtime targets.

If your packed library is really just a wrapper around your child class implementation, a better way would most likely be to employ a default naming scheme for the PPL name that follows the class name. Then using "Get Default Class from Path" you simply load the class into memory at runtime and cast it to the Base class and then you can call all the Base class methods and properties from that and the dynamic dispatch will make that the child methods are invoked.

And not just because Thomas is also a Dilbert fan? Keep in mind that code is still in its infancies. That being said I've been successfully using it on a couple of projects, one with over 1,000 individual front panel objects (really should have worked on implementing arrays), and unlike the other 10 or so solutions for web based control of a VI, it is 100% open source so feel free to make improvements.

I couldn't seem to get the Panel to work for me for some reason, so I played around with it and startet digging. In this process I found a bug that affects localised hardware, where the decimal symbol is not a point. To get the example running I had to do the following: Set "use system decimal point" to false and Set the options on the formating string to use the decimal point. There might be other instances of the GetJSONData Method where the format has to be changed, I didn't check all of them. Cheers, Robert