Executable hangs with ActiveX web browser

[Kyle Thompson]

I have a VI that loads a web page in an ActiveX container with a Web Browser. Since the ActiveX server begins loading immediately without any execution I have a dummy html page that gets loaded at first. There is a field for the user to type the name of the computer they want to connect to. Then there is a connect, disconnect and stop button. The intention is that the user can type in the computer name and press the connect button. This triggers an event that will build the path to the HTML page and it will be loaded into the browser. The disconnect button will trigger a different event that will navigate back to the dummy page. The stop button will obviously stop the execution of the VI.

All of this works perfectly when I execute the VI from my project file. However, when I build it into an executable and run it, then I begin to have problems. Everything seems to work fine but whenever I press the disconnect or stop buttons, the VI hangs indefinitely. And it looks like the button stays pressed down for some reason. Note this does not happen before I build it into an executable.

I am guessing the event structure is not at blame because the connect button works just fine. And it cannot be an odd quirk of the ActiveX server because it works before I build the executable. So I beginning to wonder if it is not something I have to set when I build the executable. Any ideas?

Kyle

[mikeporter]

Can you post a subset of your code that demonstrates the problem? (Also check to make sure there aren't any paths that break when built into an executable)

Mike...

[Kyle Thompson]

Here is about as much as I can include. Note that on the frontpanel.vi, the VI is exhibiting the behavior where the button stays pressed down. This occurs immediately after I press the button. This always happens with the disconnect and stop buttons and sometimes with the connect button. However, they all work perfectly when I load the VI instead of the executable.

On the block diagram you will find my event structure. The particular handler that you see is for the stop button. The path that is being wired into the "URL" input of the navigate nodes is not tied to where the VI is in the file structure. It is simply http://computername/file.html. The computer name is read from labview using the IP to String and String to IP functions of the TCP Palette. You see two Stop and two Navigate nodes because I have two web browser objects, but that isn't the issue.

Also note that the web browser is an ActiveX container and I have enabled the ActiveX server in the executable build.

Kyle

[mikeporter]

The reason that the stop button at least is staying down is that its not in the value change event case anywhere. For the mechanical action to be triggered the code has to read it. Beyond that I can't see any problems that would explain the troubles that you are having - but it is hard to troubleshoot from screen shots...

Mike...

[Kyle Thompson]

I was able to reproduce the issues I was having. Here is the VI that loads the remote front panel in a web browser container. It contains the same structure that is triggered by the connect, disconnect and stop buttons. It also hangs when I put it in an executable. In the current form that I attached it works perfectly, but maybe you can find something in that VI that I have not thought of. If you would like to try and test it yourself with the executable and all, I can email it to you along with the HTML files that I am using to display the VIs.

NumGen.vi generates a random number every 500 ms and displays it to the screen. This is the VI that should be displayed in the web browser when you hit connect. Blank.vi is simply that, a blank VI with an infinite while loop that is displayed when you hit disconnect or stop. I execute Blank.vi on the machine running the RemoteVI.vi. NumGen.vi is on another machine connected to the network. "String name" in RemoteVI.vi is the name of the computer that is running NumGen.vi.

Kyle

Message Edited by Kyle Thompson on 07-05-2007 12:43 PM

[mikeporter]

Hmmm.... Well Kyle I don't know what to say, I can't get the foolish thing to break... To help me see a bit better what was going on I added a bit of error check, but haven't seen any errors. The attached zip file has the code as I modified it (along with all subVIs), the blank.html file that I created and the executable which I built.

To test it I ran the VI and it promptly loaded the blank.html file. I then typed in a web address like ni.com or google.com and clicked the connect button. The page loaded without a problem. Clicked the disconnect button, display reverts back to blank page. Click connect again, display goes to page I requested. Clicked stop, display goes to blank page and program stops.

Mike...

[Kyle Thompson]

Thank you for the additional testing material. However, I was able to break the executable that you created. I ran it on a system with the full Developer's Kit 8.2.1 and I also ran it on a system with only the LabVIEW runtime engine. On both systems I was able to hang it up. It worked perfectly if I ran the VI instead of the executable.

However, now I am not sure if it is completely freezing. I launch the executable and fill in both fields. Then I press connect. The button stays pressed down and the VI seems to freeze. I can not exit the VI and I cannot move the window. But I can still access other VIs and windows. When I go back to the "frozen" VI, I can press stop or disconnect and the button allows me to press it but it "freezes" again. So I go to another open window and then go back to the "frozen" VI. I press stop and it actually stops the VI but I still cannot exit the window. So I have to terminate the process in the Task Manager.

It would almost seem like there is a problem with my LabVIEW Runtime Engine. I am wondering if even the system with the full development environment uses the RunTime engine to run executables.

Kyle

[Kyle Thompson]

Well no obvious problems with my Runtime Engine. I installed it fresh from a CD on another machine and it still didn't work. So I'm still at a loss!

Kyle

[mikeporter]

Well, I've flat run out of good ideas. The only other thing I can think of is to check with your IT dept and see if there could be any firewall/proxy issues...

Mike...

[Kyle Thompson]

I know that it isn't IP settings or anything because I have my own private network set up. Currently I am testing as the admin on all the computers so I have firewalls turned off. I have also statically defined all the IP addresses so I know nothing is wrong with that.

Thank you for all the help. I currently have a request for email support in with NI. So hopefully something will come of that.

Kyle