Use 3rd party GUI with LabVIEW?

[Sam_Sharp]

For something like that, I would be looking at either:

1) Embedding a web browser control onto your UI panel and then communicating between that and LabVIEW using either Web Services or WebSockets (there are lots of javascript APIs for graphing and you could even use the Google maps API!)

2) A custom .NET control

[rolfk]

I used in the past for an application an ActiveX control to implement a map display. It's quite some years ago and we choose at that time the open source software MapWinGIS, whch still seems to be actively developed. It had a few quirks back then but was working amazingly well for what we needed.

As many here may know, I'm not quick to choose for an ActiveX or .Net solution but this is one area where inventing the wheel in LabVIEW all over again is really a bad idea. 

[ToeCutter]

Ok, thanks. So I'm hearing Active X or .NET from the last couple posts. Obviously I now have to do some research of my own, but why the comment 'I'm not quick to choose...'? Are there any specific headaches or issues with ActiveX or .NET and LV?

[rolfk]

Yes there are. In the past the ActiveX interfacing in LabVIEW wasn't always the most stable part of it.

But more generallyI consider both ActiveX and .Net as a rather heavy sledgehmmer solution to many problems. They involve a quite resource hungry infrastructure (not that LabVIEW itself isn't guilty of that too, but LabVIEW is the primary choice for me so adding extra resource hogs to the system isn't the ideal choice).

Also many times the stability problems aren't even LabVIEW's fault but the fault of the component developer who sometimes isn't really knowledgeable about the technologies used and just worked on it until he got it working minimally somehow not until it was a fully finished product. For instance many ActiveX or .Net control based instrument drivers are more a proof of concept than a real product, sometimes even if the company sells them for money; put together by an intern who didn't know either the technology nor the actual instrument very well.

[ToeCutter]

Thanks rolf, useful info there. I'm concerned on the resource front as I'm doing a lot of DAQmx streaming in part of the app whilst these displays will be active. Memory I can spare, CPU I want to be careful with as in my experience you need lots of latency in Windows to stream reliably.

Sam any feeling if your embedded web browser solution is more lightweight? I suspect not although it's an interesting tech.

[Sam_Sharp]

It's difficult to say because there's obviously quite a bit of difference between having a lightweight .NET graph control versus an almost fully-featured browser (which is then running the javascript code to update/display the graph) embedded on your VI and a poorly written .NET component could turn out to be much worse!

[Hooovahh]

---

tst wrote:

---

Or take a shortcut - https://forums.ni.com/t5/UI-Interest-Group-Blog/Creating-an-Office-2007-like-Ribbon-in-LabVIEW/ba-p/...

---

I guess I was thinking some thing more dynamic.  Similar to my toolbar API where you provide an array of paths, that are PNG files, and the toolbar takes car of the rest with mouse over, and collapsing.  I could see a ribbon API that could do similar functions, provide an array of paths for each tab of the ribbon, and the rest is taken care of. Almost sounds like an XControl

[ToeCutter]

Thanks Sam. Looks like there's no hard and fast answer. I shall 'have a play'.

[ctVolFan]

Take a look at this: https://decibel.ni.com/content/docs/DOC-37532 

It's a way to get data from LabView into Google Charts, which offer far more options for data display and are very attractive.

I would be interested to know if anyone else has tried this.