LabVIEW Idea Exchange

Sometimes when passing multiple values into "format into string" to build a complicated string e.g. a chain of commands for a device, it is possible that the format specifiers may become hard to notice if they aren't all aligned in the same column. I would like to propse that when a string constant is wired to the string formatter terminal of  "format into string", the format specifiers be emboldened.

For example:

SOURCE:TRIGGER %s
LINE:WITHOUT:SPEC on
ANOTHER:WITHOUT:SPEC off
SOURCE:ARB %s
SOURCE:ARB:srate %.2f
MORE:LINES 51
AND:ANOTHER:ONE %f

I think it would be very useful if when selecting a build specification, you could build all the dependencies of that build in a manner similar to the way "make" works.

When building complicated projects, there may be several builds. The simplest example is an application installer that depends on the the application to be built first. Another example is a suite of compiled utilities that all have to be compiled before the installer is made. Another example is an application that uses packed libraries, all of which should be built prior to making the final build and then the installer build.

"Make" is an old tool that does this dependency checking for you. If you select the installer to build, it would check the dependencies of the installer, defined in a "makefile", and then build any project that is out of date. The out of date projects are those where the last modified date of the source code is later then the last modified date of the built file.

In this way you can simply ask that the installer be made, confident that "make" would find all the required dependencies and compile them as well.

This can be baked into LabVIEW. The installer build already knows which build specification it is dependent on.

Below is an idea of where this feature would be implemented.

Single control items have "NewVal" and "OldVal" in the Data Node for Value Change events. This is applies for numeric, boolean, and strings. It would be nice if this feature were included for listbox and multicolumn listbox labels for the "Edit Cell" events.

Use case: I use a listbox to show the materials for which the user has defined experiment settings for. These settings are saved in an XML file with the material name as an attribute. In the event that the user wants to edit the name in the listbox, it would be nice if they could just do that directly in the list box and the XML change will be handled automatically in the background. Currently to find the right element in the XML, I use an XPath to search for the label selected from the listbox. If the user edits the name, I need to know the old value in order to replace the existing name. Presently, this does not work as the Event Data Node only supplies me with the new value.

It would be useful to insert a VI directly from a project or from a class into a line.

To support modern web thin clients, the LabVIEW webservice needs to support the OPTIONS request. When a web browser makes a cross origin request there are a few rules that the response must comply with before the browser will provide with the result to the web application. The OPTIONS request is needed to respond to these requests.

A cross origin request is any request where an application running on one domain needs to make a request to another domain. For example, if there was a javascript application running on the domain www.labview.com and it needed to make a AJAX request to api.labview.com, the browser considers this a cross origin request. This is a common setup when the thin client is being hosted by one server, and the webservice is being hosted by another server. https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

Depending on the request, the browser may issue a "preflight" request. "Standard" requests are GET and POST requests without custom header fields only require the response has an additional headers. Other requests (PUT, DELETE, GET w/ headers, POST w/ headers) require a preflight request. A preflight request is an OPTIONS request. If the OPTIONS request doesn't get an appropriate response, the browser will not even make the actual request. https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request

For example, I'm starting an application and here's how I'd like it setup.

1. Windows PC. This is the central server for the application. There will be a normal LabVIEW application running on this computer. There will also be a web service run on this computer. The web service will mainly host a web application written using HTML/CSS/Javascript (although it could be written using HTML vis from NXG).

2. A bunch of CRIOs. These CRIOs will also host their own web service to get system information, measurements, and diagnostics. As new CRIOs are commissioned, they'll report to the Windows PC.

Now a user uses their web browser to access to the windows PC. The Javascript Application (which is hosted on the Windows web service) provides the user with a list of all commissioned CRIOs. They then click on one and the javascript application starts to make requests directly to the CRIO's web service. Since these CRIO's are on a separate IP address, the browser flags this as a CORS request. This means that an OPTIONS request can be sent. Since I can't handle an OPTIONS request in a LabVIEW web service, I can't implement this.

This is just one example. Another case would be an Apache hosted web application hosted on an Amazon EC2 needs to make requests to a LabVIEW web service running in a different domain. Basically any time a web application (AKA something running in the browser) needs to communicate with a LabVIEW web service you'll run into this problem.