It is important to note that not all standard application features translate well into distributed applications. Application features that are localized to the computer on which they run are the biggest potential pitfalls, because they are computer specific, and do not transmit on the Web. Two good examples of localized application features are ActiveX and system dialog boxes.
ActiveX is a powerful, useful communication and control technology. Any Web browser can download and execute ActiveX controls, after which they have full control of the Windows operating system. This full control yields great functionality but also presents a considerable security risk. To control this risk, Microsoft developed a registration system so browsers can identify and authenticate an ActiveX control before downloading it. After the browser downloads it, you must register the control on the local system before you can run it. While it is not necessarily a problem to register an ActiveX control on a single computer, it can be difficult to ensure that the control is validated and registered by every computer that might view your application on the Web.
Another common component of most applications is a system dialog box. System dialog boxes are a good way to notify a user of a problem, communicate important results, or solicit input from the user. The Simple Error Handler VI even makes use of the system dialog box to manage errors. System dialog boxes are great tools, but they do not work well with distributed applications. The system dialog box remains on the local computer instead of being distributed with the application. In the following example, the VI is simple. It uses an Event structure to monitor the status of a Boolean control. When the user clicks a button, the VI displays a one-button system dialog box with the message Button Pressed.
. Front Panel and Block Diagram of a Simple VI Calling a System Dialog Box
If you distribute this VI remotely and a user on the Web clicks the button, a dialog box appears on the host computer only. Because that dialog box is a local system box, it does not appear to the user on the Web, but it prevents anyone from using the VI until it is closed. So the user on the Web cannot use the VI but is unaware that the problem is the open dialog box. Because of the localized nature of ActiveX and system dialog boxes, you should not use these technologies in applications designed to be viewed and controlled remotely.
For remote front panels, you can accomplish the tasks of system dialog boxes without any of the drawbacks. For example, you can use a subVI for a dialog box instead of a system dialog box. Customize the Window Appearance settings in the VI Properties dialog box of the subVI to make the subVI behave identically to the system dialog box. Because the subVI is part of the LabVIEW application, the Web Server can serve it to remote clients (Figure 5).
Displaying a SubVI Dialog Box Instead of a System Dialog Box
For Web applications, consider eliminating dialog boxes completely, because they can distract the user. An alternative way to present a user with information that you might display in a dialog box is to use a tab control. Design your application to run on one page of a tab control, and switch to another page when an error occurs or the user must make a decision. You can use Property Nodes to disable the other pages of the tab control until the user acknowledges the error or makes the decision (Figure 6).
. Front Panel and Block Diagram of a VI Using a Tab Control to Handle Warnings
In LabVIEW 7.1 or earlier, refer to the LabVIEW User Manual (linked below) for more information about functionality not supported in viewing and controlling remote front panels. In LabVIEW 8.0 or later, refer to the Functionality Not Supported in Viewing and Controlling Remote Front Panels topic in the LabVIEW Help (linked below).