LabVIEW Web Development Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

web dev tools

so if i have two different sections in my web app, for example a "task" section and an "instrument" section. should I use one script for both and put all the event handlers in that one script, or should I have a separate script fo reach. when I try to use separate scripts I am having issues with "windows.onload" method, it seems like they are conflicting? Also, global variables are accessable in both script, how do I make them local to their defining script so that I can use the same variable/function name in another script?

0 Kudos
Message 11 of 32
(2,782 Views)

Seperate scripts should be fine. What's probably happening is that when the first script runs it sets the value of window.onload and when the second script runs it overwrites the value. When the window is ready to fire the load event, only the second one is getting called.

One approach to solve the problem is to call addEventListener for the 'DOMContentLoaded' event. The addEventListener function can be used on the same object multiple times for the same event without overwriting each other. This way multiple different files can register for an event to run when the DOM is ready. Be aware of browsers that support the DOMContentLoaded event and you can find libraries that support more browsers if needed.

To make a local variable you use the 'var' keyword inside of a function. The article Everything you wanted to know about JavaScript scope gives a good overview of the different scopes in JavaScript.

This plunker example shows a page (index.html) that includes two scripts (script.js and script2.js). Each script uses a variable local to a function and the functions are called when the DOM is loaded.


Milan
0 Kudos
Message 12 of 32
(2,781 Views)

Rood,

To make a variable global to a given script but not clutter up the global space, consider wrapping the script in an IIFE.  If you want the variable to be scoped to a function, consider what Milan has to say above.

Cheers, Matt

Message 13 of 32
(2,781 Views)

I'm currently working (in my spare time) on something that should work like the wezarp tool (http://www.wezarp.com/). You drop a vi on your block diagram and it automatically builds a web-page that reproduces the look of the front panel - no change of code needed.

The webpage then updates its indicators just like the front panel does and allows the user to operate controls which will be forwarded to the front panel and make stuff happen in the VI.

Turns out, that's rather difficult and I might never finish it but I'm happy to share various stages of development around if there is interest.

0 Kudos
Message 14 of 32
(2,781 Views)

teegee wrote:

I'm currently working (in my spare time) on something that should work like the wezarp tool (http://www.wezarp.com/). You drop a vi on your block diagram and it automatically builds a web-page that reproduces the look of the front panel - no change of code needed.

Yes, it does sound interesting.

I should point out that Wezarp actually appears to use an embedded VNC server to allow a connection to a specific window. What you're describing sounds exactly like WebPager, in case you actually need this functionality. I haven't used either of them, so I can't comment. I also think I did see at least one other product which works similar to WebPager, although I'm not sure of that and I don't remember the details.


___________________
Try to take over the world!
0 Kudos
Message 15 of 32
(2,781 Views)

You might also want to check out the LabSocket System by Bergmans Mechatronics. This implements the same concept as WebPager and has a nice evaluation mode:

http://sine.ni.com/nips/cds/view/p/lang/en/nid/212532

Joey S.
Senior Product Manager, Software
National Instruments
0 Kudos
Message 16 of 32
(2,781 Views)

Ha!  You beat me to the punch on this suggestion, Joey!

I for one have never been particullarly interested in these solutions that allow the user to "mimic" the LabVIEW UI in a browser.  Besides the high entry cost of an implementation such as LabSocket, , I think that LV has significantly lagged the fast pased of UI development in the web world.  LV UIs tend to be clunkier and less flexible than native web based applications.  My suggestion is not to spend too much time or energy on these technologies and take the time to understand development of web based UIs; you will be a more well-rounded developer and it will provide insight into developing applications in general as well as LV applications.

Message 17 of 32
(2,781 Views)

Hm, I must admit those look very similar to what I had in mind. Massive price tag though.

I don't like the idea of screen-grabbing the front panel and showing a picture in the web browser (or using vnc like wezarp). I would prefer native HTML5 elements but there are some limitations I haven't figured out yet. For example, how do you tell the difference between a check box and a normal button or in fact any boolean control (without supersecretspecialstuff that doesn't work in RT). Grabbing an image of both of the control's states in question and using it instead of a HTML/js representation would be the last resort.

But isn't it funny how all their demos tip-toe around issues like latching booleans, tab controls and subpanels? How do you programmatically press a latching button without using user32.dll to actually send a mouse click event?

It seems like "no modification to the code required" can only be true for a subset of all possible FP configurations.

0 Kudos
Message 18 of 32
(2,781 Views)

LabSocket was probably the second one I was thinking of (I certainly knew of it, but I seem to remember seeing a pricing model which allowed fine grain control of the payments, like time-based payment. It might have been one of those two and that option was removed).

Based on the name (I haven't looked at the details in a long time), I'm assuming LabSocket uses web sockets to transfer values from HTML widgets to LV controls (probably using Value(sgnl), although that would indeed be a problem with latching booleans). There was also a project on LAVA a few years back that did something like this. I haven't looked at the details since then, but if I remember correctly, then it was a problem because sockets were unsupported and I don't know if that's still the case today.

A quick search yields these links:

https://lavag.org/topic/13777-labview-websockets-and-svg/?p=82819

https://lavag.org/topic/15470-webpanel-open-source-svg-and-websocket-project-launched/


___________________
Try to take over the world!
0 Kudos
Message 19 of 32
(2,781 Views)

I am not totally following this, teegee.  What are you trying to do?  Latching in web based development is not a big issue.  If you are using something like bootstrap, active is a class that indicates the state of the button (it will have control over the way the button appears).  This class can be manipulated via js by tying events to the button press using whatever tool or framework you have chosen for your application.  Nothing particularly supersecret about it.

Here is how I might do a latching button using angularjs:

<button class="btn btn-default" type="button" ng-click = "saveData()" ng-class="{'active': save}">Save

</button>

In this case, ng-class is a directive that will add the class active when the value save is true (ng-click causes the function saveData() to fire which will toggle the value of save).

But, maybe I am not understanding your comment?

Matt

0 Kudos
Message 20 of 32
(2,781 Views)