Executable hangs with ActiveX web browser

[mikeporter]

Sounds good. Do us a favor if you will, please post to this thread when you find a resolution.

Mike...

[reggier]

Hi Kyle,

I have seen this sort of thing before, and have some things that have worked in the past.  I have opened your program and Mike Porter's program, and they seem to work fine for me.  This makes me think the issue is with your software.

1) The first thing I would do is reregister your ActiveX Control.  This stands out the most in my mind as to what is wrong.
2) Try building a LV ActiveX example into an executable to see if that will work.
3) Try rebuilding Mike Porter's program into an executable and enable debugging.  This will allow you to access it, probe it, and see where the error is coming from.
4) Update your version of Internet Explorer.

I think you should find your solution somewhere in these steps.

Reggie Rector ¦ Applications Engineer ¦ National Instruments

[Kyle Thompson]

Tried reregistering the ActiveX control multiple times and in multiple ways. Nothing seems to have made a difference with that.

I rebuilt Mike Porter's rendition of my example VI into an executable. I was able to access NI.com and my blank.html just fine without it crashing. However, when I tried to connect to a remote VI running on another computer, it froze. I have tried this on three different systems and they all do the same thing. I made sure that I reregistered the ActiveX control with each system before I tried accessing the remote VI.

One of the systems that I tested on had IE7 and the other had IE6. Same issues on both systems so it can't be the version of IE that I am using.

So I tried my VI again (not Mike Porter's) and it still froze. Interestingly, I have been finding that if the HTML file that I specify can not be found when I hit connect, it will not freeze the VI. All the buttons are completely responsive. It is only when I give the VI a valid HTML file that it can access that causes the VI to freeze.

When you mentioned that you think it is in issue with my software, do you mean my LabVIEW installation or the software that I have written?

Kyle

[mikeporter]

So it sounds like it might be a VI webserver issue? Can you access the VI on the other machine from a regular browser?

Mike...

[Kyle Thompson]

Yes, I have tried that one multiple times. Before I run the remote VI application, I make sure that I can connect to the server VIs through IE. That way I can rule out a problem connecting to the server VIs if the remote VI errors on me.

Also tried this in IE6 and IE7.

Kyle

[reggier]

Kyle,

I took a second look and have new information.  I was able to reproduce your issue by taking Mike Porter's executable and using a LabVIEW Remote Front Panel as the webpage to access.  This exe works great when accessing normal webpages (ni.com/yahoo.com etc...).  The problem occurs when accessing a LV remote front panel.  I saw the same errors you did.  I will file a Corrective Action Request (CAR) on this issue.

I have tried a few different things.  First, I ran the original VI and it worked great.  I could open the remote panel in the ActiveX container.  I then rebuilt the executable with remote debugging.  I found something unique here.  When I remotely debug the executable, it works!  There is a bug though.  When I remotely control the exe, the webpage gets published on the original executable shell and not the remotely controlling panel I have open!  I will be filing a CAR on this as well.

What I am looking into now is being able to split your program into two VI's.  One VI for the Event Handling, and a second VI that will open an ActiveX shell for the browser.  I would suggest playing around with this option yourself as well.  I have attached a sample VI of what I am playing with.  It doesn't work now, but might give you a start on where to go.  Open the Project, then open CallVI and look at the block diagram.  It is a start of where we want to go.

I will post to this thread at some point next week (as I am Out of Office for a while) and let you know what I find.  If you find anything sooner, post back and let me know!

Reggie Rector ¦ Applications Engineer ¦ National Instruments

[Kyle Thompson]

Well, it's good news that I am not off my rocker completely. I was beginning to think I was the only one who could break the thing!

Thank you for continuing to work diligently on this issue with me. Just one thing, there weren't any files attached to your most recent forum post like you said.

Kyle

Message Edited by Kyle Thompson on 07-12-2007 04:09 PM

[reggier]

Here is the option I was trying to start looking at.  It remotely calls the VI to be opened (similar to the remote debug that works properly).  It isn't working now, but should give you some idea of where to go.  I will continue looking as well.

reggier

[Kyle Thompson]

I see now what you are getting at by using two VIs. Good idea based on the observation that things work correctly in the EXE when it is being remotely debugged. I have looked at your VIs and have not been able to find a way to have RemoteVI.vi trigger those events by changing the values of the controls from CallVI.vi. RemoteVI's front panel will show the changes in the controls so I know that is working, but the event associated with a value change of the control never is triggered.

Otherwise the VIs look fine and they work. Obviously there was no use testing it as an EXE because I wouldn't be able to get the events to trigger which seems to be where the problem occurs everytime.

I attached the VIs again because I added Mike Porter's error handling VIs since they were required for the ~RemoteVI.vi that he originally provided. Otherwise I am not sure what to do about that one. Any further help would be greatly appreciated.

Kyle

[Kyle Thompson]

Congratulations goes to Reggie Rector for finding a workaround for the issue. His final example with some tweaks has been attached for convenience in understanding the forum conversation thus far.

My final issue was resolved by creating a while loop in RemoteVI.vi that checks the value of the controls to see if they have changed since the loops previous iteration. If a change has occured, it will change the Val(Sgnl) property of the control so that the appropriate event handler will be activated.

Thanks again all!

Kyle