Data I/O w .NET WebBrowser Client

[mje]

So this idea rekindled something I've been longing for for a long time in LabVIEW: better integration with web-based UI technologies. I've in the past played with using HTML/etc to create dynamic user interfaces which frankly aren't possible in LabVIEW since elements can't be created or destroyed dynamically, and this is something HTML/etc excels at if you know a little DOM and the idea of a little javascript doesn't scare you.

First a little proof of principle to show that you can get data in and out of a WebBrowser:

WebBrowser.zip

Caveats: This is a very simple proof of principle. To use it you must

• Be on a Windows based PC (it uses .NET after all).
• Keep the contained folder in a location which doesn't have spaces in the path, I didn't do any URL parsing...

How it works. Getting data in is pretty trivial. Once the document is loaded in the browser, grab a reference to whatever you need (in this case an input element), then whenever want to update the value, just push it to the browser using the element refnum.

Getting data out isn't so bad either, though it is rather annoying. If you know any DOM, you're probably familiar that all the input elements have an onchange event associated with them. Well forget that, you can't use a refnum to register for an event callback for anything you pull from the hosted browser (someone please correct me if I'm wrong about this). But you still can register for events on the top level WebBrowser2 refnum, so I pulled the BeforeNavigate2 event and registered a callback for that. Now whenever I want to get data out of the web page, all I need to do is trigger a location change, then pull out any data I wish. You can probably imagine a few other ways to skin this one...

There are still some things that are basically off limits in LabVIEW. In the past I've defined entire COM interfaces (via C++), then passed the corresponding IDispatch interface into the browser which allows you to define arbitrary functions and variables which can be called directly from within a hosted document via the global window object available through javascript. I would love to be able to do this in LabVIEW. Imagine being able to call some code like this:

<input type="text" onchange="CallMyVI('Foo', 'Bar');" />

And have a registered callback VI automatically be called with "Foo" and "Bar" being placed in the appropriate terminals of your connector pane.

So what's the point behind this post? I'm really just hoping to seed some discussion on this. I have no idea how many of you have some web-based development under your belts, but I'm hoping even if you don't, that you can see the possibilities that can be opened up by being able to have a more dynamic user interface canvas available to us? Hopefully in time I can get a more thorough example of what I think is possible, but for now the proof I posted above is all I have.

Regards,

-michael

[MikaelH]

Hi Michael

It was a year since you posted this one, but now I'm also facing a similar task. We have a production traceability system, that we both have LV and WebPage GUI interfaces to.

For some forms that collects data, it's much easier to use the web interface, since you can dynamically create different types and number of controls.

So I need to embed this form into the LV application and wait until the user filled it out.

Our first solution we can think of is to Supply a token (unique ID) to the URL and have the WebPage/Webserver save all data and link it to this Token.

So if I need to read it later or need transact something else against this data I will just use the token.

My first task would be to figure out when the form has been submitted, the 2 solutions I can think of is to poll the WebBroswer.Document.Content and see when the form has been submitted, or I can just implement a WebService function that I call with the Token and it returns me a "FormSubmitted" flag when it's done.

Has anybody else a good solution to this problem?

[asbo]

I think the "right" solution is something like that latter that you mention. It's a more formal handshaking process and it guarantees that the data has reached its destination. IMO, polling the DOM is always a bad idea.

[mje]

Hi Mikael,

Can you clarify something? Are you interfacing with an existing http based application? Are you looking to host the application's form and pull data from the form without sending it to the server, or were you wanting to let the form submit data to the server, then query the server for a result?

[MikaelH]

In the design, I will let the Form Submit and save the data in the database.

The form will be design to fit inside my LV application, so not to be used as a normal web page.

When the form is submitted, it will probably just go to a blank page.

I can just poll the current URL of the browser, or poll the database to see if the data has posted properly.

If the Web-Page likes to send some status information back to me, it could just add that in the new URL page it goes to after submitting the form.

E.g. White text on a white background or something similar so the users can’t see it.

[mje]

No need for polling. There are many ways to tackle this depending on how much control you have over the server application.

I'd say the easiest way is to just register a callback on the browser object to notify you of a navigation complete event. Your job will be to check the URI of the navigation, and if it indicates a submission, then go ahead and query the server. For example (LV2011 SP1):

submit example.zip

When you run submit example.vi, it will show you the lavag.org website and continue to run until you execute a search on the forum. Rather than returning, your application would have to do more sophisticated handling such as error handling, then go ahead and query the server, but this proves the basic premise.

I'd likely stick most of this logic in the callback VI instead of the event frame, but for the example I wanted most of the code in the same place.