Defer panel updates when using activex webbrowser

[cbfsystems]

I am working on a LabVIEW application that performs a series of tests and generates an HTML report.  The report is displayed using the Microsoft web browser inside an activex control.  To do this, the report is saved to a file and then the file location is passed to the browser using the Navigate method (IWebbrowser 2).  The report and its view should be updated after each step of the test.  This is currently being done by generating the current edition of the report after each test step, saving it to the same file, and then calling the Refresh method of the browser.  This works fine unless the report does not fit in the browser window (scrollbar needed) and the scroll bar has been moved down from the top.  In this case, the Refresh method causes the scroll bar to move to the top, the latest report is displayed, and then the scroll bar returns to its previous position.  The final position of the scroll bar is what I want, but the redraw appears glitchy.  I tried to deal with this by deferring front panel (using a property of the front panel) updates while the Refresh node was called, but this did not keep the activeX control from updating.  Does anyone know how to prevent this glitchy effect, perhaps by suppressing the rendering of the activeX control until it has finished updating, or some other way?

[Shezaan]

Hello, 

Have you seen this behavior previously? Or is this the first time you have encountered something like this? Also what version of windows/internet explorer and LabVIEW are you using? I think it would be beneficial if you could provide an example or an image of what you are seeing. 

Regards, 

Shezaan Noorani

Applications Engineer 

National Instruments

[cbfsystems]

Here is a simple VI and HTML file that demonstrates the behaviour I was describing.  Select the path to the html file before running the VI.  The VI loads the file into the browser and then refreshes every 2 seconds thereafter.  The file is too long to display in the browser viewport, so the browser will have a vertical scrollbar.  If the scrollbar is placed at the top, everything looks fine.  If the scrollbar is lower down, the glitchy behaviour described previously is observed.

[cbutcher]

I'm attaching my modified VI, backsaved to 2015. In your uploaded VI, I can see the problem. In my VI, the problem disappears, but I'm not certain that the method is necessarily solving the problem properly...

I say this, because moving the changes outside of the loop returns the problem, and setting the property once should be sufficient, rather than having it in the loop. As a result, I expect you have a race condition of some sort, and what I've done just delays it.

The alternative is that calling refresh resets the synchronous property to true, and so it needs to be made false each time. I have no idea if that is true.

[cbfsystems]

I am running into some trouble when I try to execute your code on my machine.  The Navigate node seems to execute correctly and the html page opens in the browser control.  No error is generated when the Container property is read, but an error is output when the Variant to Data node executes (see the attached png).  The error appears to be a type mismatch error of some kind.  A probe on the Container variant going into the Variant to Data node shows Value -> 0.  

[cbfsystems]

Here is some additional information.  I tried a slightly different way of setting the SyncDisp property.  I created a property node for this by right clicking on the webbrowser terminal and selecting the property.  Now a different error is generated indicating that this property cannot be set a run time.

[cbutcher]

Ok. I think you should ignore everything I wrote - it seems like this only works because the Refresh node isn't actually being called (the error in is true, for either of the reasons you mention, and then the property node doesn't execute).

I guess if I had tested this with a page that changed, it would have been more obvious. Sorry for the noise.

[Shezaan]

Hello, 

It seems that the behavior that is being seen is inherent to the web browser rather than LabVIEW. If you open a webpage in Internet Explorer or Chrome, you will see that the page jumps to the top for a split second and returns back to the original location.

I am not sure if there is a work around, but there seems to not be one. Is there a reason for why you would like to update every 2 seconds? You could just refresh the page after the test is completed to avoid dealing with this behavior when you scroll. 

Regards, 

Shezaan Noorani 

Applications Engineer

[cbfsystems · Accepted solution]

The two second refresh period was just chosen to demonstrate what happens when refreshing the browser.  What I really want to do is refresh when each time a step in the test sequence completes.  This is so that the test progress can be seen and the completely results can be viewed part way through the test.

I have found a way to do this, but it is pretty painful and I would not call it elegant.  To prevent the glitchy scroll behaviour, the browser height is made large enough to display the full HTML document so that no scrolling is required (scroll bar on the browser becomes disabled).  The tall browser is viewed in a subpanel, which has a vertical scroll bar.  Moving the subpanel scroll bar allows the full document to be viewed. This approach is accomplished with the following steps:

1. Place the web browser on VI-1.  The vertical scroll bar of VI-1 must be on when running.
2. Insert VI-1 into a subpanel on VI-2.
3. Add javascript to the html document to calculate the height of the document using document.body.offsetHeight.
4. Add javascript to the html document to send the calculated height to a web server running on the local machine.  The height is sent using and HTML request.
5. Create and run a web server to receive the HTML request containing the height.
6. The web server relays the height to VI-1.
7. VI-1 resizes the browser to have a height slightly taller than the document height.

Each time the browser is refreshed, the document height is recalculated, sent to the web server, then to the LabVIEW app, and the browser is resized.  The scroll bars of the subpanel resize appropriately if the document height has changed, but they don't jump around.  It's painful, but it seems to work so far.

[charlie87]

Hello,

has anyone found a less complicated solution ??