Alert/Confirm/Prompt

[Albert.lederer]

Hi,

I've been playing with the WebVI Module of Labview NXG 4.0.  What really irks me is that although there is a dialog box, it only contains buttons and has now way of getting information from a popup back to the application beyond the button states. 

What tried then was to embed an window.alert into a Javascript Library Interface.  This doesn't work at all.  Basically, I just modified the example from NI to call window.alert in the javascript add.js file.  NXG just seems to ignore the alert statement completely (no errors or messages).  If I create a new project and add a custom function which ONLY calls window.alert, the webVI runs as normal, ignores the alert, and spits out an unhandled exception with code 44302 at JavaScriptInvoke.

Is this a limitation of the NXG WebModule or am I doing something wrong?  I've attached he javascript file and the jsli file...

Br,

Albert

[பரத்_குமார்(bharathkumar)]

Hello,

Post the topic in LabVIEW NXG forum to get answers.

[RavensFan]

There is no "NXG" forum.  NXG questions are posted in the same LabVIEW forum as current generation LabVIEW.

The thought is that the programming logic is the same.  Unfortunately, the development environment and the appearance of objects are quite a bit different.  Also, unfortunate is that NXG is still being developed to add the features that current gen has.  Also, the heavy hitter answer people in the forum have programmed for a long time in classic LabVIEW, and have very little experience with the new NXG version, which means there aren't as many people in the forum capable of answering questions.  The NXG version is new to both LabVIEW newbies, who seem to be the first adopters in using it, and also the LabVIEW veterans.

[Albert.lederer]

Hi Ravensfan,

thanks for the info. I am familiar with the NXG idea (and I think it's a good one, though not quite there yet). I myself hold a CTD and CTA and have been to the European  version of NIDays (called VIP in Germany) since 2013.  I also fully accept that NXG does not have the full functionality of classic LabVIEW, and that's not what I was looking for.  I also accept that the WebVIs will have an even more restricted command set as they are based on web technology and as such are limited to what a browser can do.  For most of my work I can't use NXG yet anyways because some of the functionality I depend on is still missing (cRIO for example), but the WebVI thing really excites me.

What I would like, though, is maybe a list of things that aren't supported.  If the prompt/alert/confirm javascript isn't supported, then that's ok as long as I can somehow find that out, and if I'm doing something wrong (which is most likely the case) I'd like to know what.  Also, I've had no luck finding information about the error message I posted above, on the web or in the help.  So for me this isn't really a technology issue, but a support issue.  

I just thought I'd ask the question.  Maybe someone from NI is listening and knows something 😉

[MilanR · Accepted solution]

Hi Albert,

I took a look at the included JSLI (thanks for including an example) and I think I found why the error code 44302 is occurring. If you create an error indicator and scroll through the error source you see the following message:

JavaScriptInvoke in WebApp::Library.jsli::PromptBox()->WebApp::index.gviweb<APPEND>
Function not found. Verify the function name in the external JavaScript file matches the function name in the JavaScript Library Interface.
function: PromptBox()

And in the JSLI configuration we see the following configured:

While in the provided JS file we see the following global name:

So the error is because the JSLI was configured to search for a JavaScript Global with the name PromptBox() while the name of the global created in the JS file is PromptBox (note the lack of parenthesis). If you remove the parenthesis from the JavaScript Global in the JSLI document it looks like the function can be found:

There are a couple of additional concerns to be aware of trying to use the browser's alert / prompt / confirm functions:

1. When running in the LabVIEW NXG Editor, the dialogs associated with alert / prompt / confirm are not implemented and instead return immediately without asking the user. For the provided JSLI example that results in the JSLI node always returning "User cancelled the prompt." when running inside the editor. This is due to limitations of the browser embedded within the NXG editor and that we have not done the additional work to implement those dialogs in NXG. You can still use the run in browser command, etc. to see the alert in your own web browser.
2. Web browsers each have their own heuristics on what makes an alert / prompt / confirm dialog disruptive to the user on a page. Each browser behaves differently, some allowing users to avoid further dialogs and adblockers frequently blocking alert / prompt / confirm dialogs altogether. If you need to see the dialog reliably these browser behaviors may interfere.
3. The alert / prompt / confirm dialogs completely halt the JavaScript runtime on a page until the dialog is dismissed. If you have parallel while loops, etc. they will not be running while the dialog is open.

For those reasons we did not leverage the built-in alert / prompt / confirm behavior of the browser when implementing the 1 button dialog and the 2 button dialog in WebVIs.

[RavensFan]

---

@Albert.lederer wrote:

Hi Ravensfan,

thanks for the info. I am familiar with the NXG idea (and I think it's a good one, though not quite there yet).

I just thought I'd ask the question.  Maybe someone from NI is listening and knows something 😉

---

You're welcome.  I'm not familiar enough with NXG to be able to comment on it.  My message was more to bharath1991 who was instructing you to post in the "LabVIEW NXG" forum when there is no such forum.  Posting it in the LabVIEW forum and tagging it with the NXG marker was the correct hing for you to do.

I hope someone with more knowledge will see this thread and comment on your question.

[Albert.lederer]

@MilanR:  See, I knew it was something I was doing wrong 🙂  Once I removed the parenthesis it worked perfectly.  I had assumed that it was supposed to look like a function prototype.  The app will be used in a controlled environment where we have full control over how the relevant browsers are configured and I also have the luxury of being able to specify which mobile clients are supported, so I kinda have carte blanche with this system, but really appretiate the caveats you've listed.  Knowing the limitations of a systems is crucial when making design decisions. 

@RavenFan:  I was just going to ignore the message anyways.  I had looked around for an NXG forum beforehand and had discovered that everyone was doing the same thing...  

[MilanR]

Hi Albert,

I wanted to see if there were good alternatives for the browser prompt that avoids the caveats described above and probably as expected there are tons of JavaScript libraries available. One I found interesting due to its compact size, zero dependencies, and high configurability is the SweetAlert2 library.

I created a Library component and sample Web Application component using the SweetAlert library as an example to get started. I exposed about a third of the options available but it is already very configurable compared to the browser prompt, one button dialog, or two button dialog. In particular some interesting features are:

• having different text input types that trigger different input user interfaces (particularly on mobile like tel, number, password, etc) and do some validation (like valid email addresses)
• a mode to display progress steps like steps in a wizard
• the ability to use HTML in the dialog message content which is particularly useful for links and basic formatting

I published a demo page WebVI SweetAlert playground to experiment with, attached a zip of the library + example web app, and the latest source is available on my GitHub. It's not necessarily an advocation for the SweetAlert library (make sure it's tested / licensed correctly for your needs) but an example showing how one may expose a feature rich library.

It sounds like the built-in browser prompt may meet the needs of your application but if you do play with the SweetAlert example I would be interested in your thoughts.

[Albert.lederer]

Kickass.  I'm took a look at it and it looks really interesting.  I'm having some problems with my NXG installation at the moment, but I'll download the code as soon as that's fixed..

I've done a couple of wizard things in the past for semi-automated testing, and there I've had good sucess using an tab control with invisible tabs, then stepping through the tabs one by one, aggregating the information.  That always worked very well...