02-21-2008 01:58 PM
02-22-2008 04:25 PM
02-23-2008 03:54 PM
Kevin,
Thanks for the reply.
Attached is a screen shot of the problem. This is from my home machine which does not have a LabVIEW environment installed, but does have runtime plug-ins for 7.1 & 8.2.1. I also get similar results on my development machines.
The serving machines are all on campus.
The remote front panel on the left is what I expected to see embedded in the 'loading ....' field on the Web page on the right.
The application [ The iLab Project ] is complex and uses a collection of .Net Web Services to provide access to remote labs using the Internet.
Access to an iLab Lab Server running on port 80 is authorized by a Service Broker, normally running on another machine. The Lab Server, LabVIEW environment and measurement hardware are normally on the same machine, iLab Lab Server using port 80, LabVIEW WebServer using port 81.
Once the user is authorized and redirected to the Lab Server the Lab Server ensures that LabVIEW is running and the specified VI is loaded, a web page is generated on port 80 that includes the OBJECT block to display the front panel from port 81. Example OBJECT block included in my original post.
I have used this code on three other 8.2.1 Lab Servers with different VI's and the Front panel is displayed in the web page as expected.
Variations of the code have been used since LabVIEW 7.0. Prior to version 8.2 the InternetToolkit, GWeb Server and a custom CGI VI were used to generate the contents of an in-line frame to display the Front Panel. Since 8.2 I generate the Object block directly as part of the aspx processing. Is it possible I need the InternetTookit installed even if it is not used, I'm pretty sure one of my working systems has never had the toolkit installed, the machine in question has not.
I hope this makes my problem clearer, any help, pointers or further questions will be appreciated.
Phil
02-24-2008 04:15 PM
Kevin,
I feel a little foolish, there was a simple resolution to my remote panel problem.
The VI in question had the window appearance property set to 'Run as Top-Level Application', instead of the default or custom settings that I used for all the VI's that I've worked with before. This includes the example application that I use for testing 'Tank Simulation'. Since the application that had the strange behavior was written by the folks at the hosting lab I should have spent more time looking into what were the differences in the actual VI from the VIs that have worked within the iLab environment, instead of expecting to find a problem with the lab site configuration.
It is nice to know that you can run a top-level application remotely , if that is what you want.
Thanks for your time & help.
Phil