.NET Style DataBinding from LV 8.2?

[Yianni29]

Hi, I am a recent Microsoft-land programmer who has swallowed the blue pill and converted to LabVIEW and I was trying to get databinding working in the LabVIEW environment as if I was in .NET.

I am attempting the following from LabVIEW (and .NET 2.0):

(1) Create a System.Data.DataSet object, create one DataTable and populate it with two rows of data.

(2) After I create this dataset, I use the regular .NET functions (via LabVIEW) to verify that the data is accessible and properly written to such DataSet.

(3) I then databind this dataset to a DataGridVIEW control that I have placed inside of a .NET container on my Front Panel.

Unfortunately, for some reason the databinding fails. I have written my own custom controls and have already verified that passing a DataSet to a .NET control works, so before I dig into all of the Microsoft Whitepapers and reinvent the wheel several times, can anybody tell me if they have had any success using .NET controls and databinding in LabVIEW? My goal is to use .NET controls (as advertised by NI) in my LabVIEW programs so that I can harness the power of these .NET controls instead of having to use the controls that already come pre-package with LabVIEW.

I will post my results as I continue my investigation into this.

Thanks,

John

[Ton Plomp]

John,

are you totally fresh on LabVIEW? Maybe you are not fully adapted to the dataflow (or other paradigm shifts)?

Could you post your LV code?

Ton

[crelf]

Maybe you are not fully adapted to the dataflow (or other paradigm shifts)?

You will be assimilated

[Yianni29]

John,

are you totally fresh on LabVIEW? Maybe you are not fully adapted to the dataflow (or other paradigm shifts)?

Could you post your LV code?

Ton

I got CLAD, and I have already verified that the DataSet does get properly passed by creating my own custom .NET user controls and doing the same thing. I guess I should specify that some .NET experience is required to understand what I am talking about. But either way, I will end up teaching some stuff about .NET to the rest of you guys, and you guys will teach me something about LabVIEW!

Download File:post-6932-1164719124.vi

[Yair]

The code in the image seems to be OK, but I can't test it, since I don't have 8.2 and my version does not support .Net container. If you want a certified answer, you should talk to Brian Tyler, who's the head of the LV .Net integration team.

You can do that by posting to the NI forums or (if he doesn't anser that) by finding his email address in his blog. It would also be useful if you post the answer here afterwards.

[Yianni29]

The code in the image seems to be OK, but I can't test it, since I don't have 8.2 and my version does not support .Net container. If you want a certified answer, you should talk to Brian Tyler, who's the head of the LV .Net integration team.

You can do that by posting to the NI forums or (if he doesn't anser that) by finding his email address in his blog. It would also be useful if you post the answer here afterwards.

Cool, I will look him up.

Basically, I think that one of the required functions to show a databinded control is missing from the LV implementation. Speaking with him sounds like a great idea! (DataBinding works when I wrap up the control into my own custom control... still working on it though)

[Yair]

If you do a lot of .Net interaction with LV, you should definitely follow Brian's postings.

One thing I will note about your code is that you don't close the references (for instance, in your example, you should have closed the references to the DataTableCollection, the DataRowCollection, etc.). When working with an external resource (COM\.Net) it's very important to do this or you will have memory leaks over time.

[LAVA 1.0 Content]

Brian's BLOG is at http://detritus.blogs.com/lycangeek/

or you could contact him via his LAVA profile

I looked at your code, and saw nothing unusual about it. Keep us up to date as you learn more...

[Big Hank]

QUOTE(yen @ Nov 28 2006, 04:19 PM)

If you do a lot of .Net interaction with LV, you should definitely follow Brian's postings.

One thing I will note about your code is that you don't close the references (for instance, in your example, you should have closed the references to the DataTableCollection, the DataRowCollection, etc.). When working with an external resource (COM\.Net) it's very important to do this or you will have memory leaks over time.

Ok People Lets get One Thing Clear. Not Closing .Net Reference Dosen't Make Memory Leaks. The Reference handler work differently that in the old C++ And VB 6.0 Days. The .Net Framework Grabege Handler will clear All Unreference Objects when Fired And Leave Objects still in use(Reference by Any outside object). .Net Frame has a table of all Object Created.

Form Tech Spec.

http://msevents.microsoft.com/CUI/EventDet...p;culture=en-us

From A Master of the .Net

[jzoller]

QUOTE(Big Hank @ Jan 24 2008, 12:57 PM)

Ok People Lets get One Thing Clear. Not Closing .Net Reference Dosen't Make Memory Leaks. The Reference handler work differently that in the old C++ And VB 6.0 Days. The .Net Framework Grabege Handler will clear All Unreference Objects when Fired And Leave Objects still in use(Reference by Any outside object). .Net Frame has a table of all Object Created.

Form Tech Spec.

http://msevents.microsoft.com/CUI/EventDet...p;culture=en-us

From A Master of the .Net

Gah, zombie thread!

Besides, I'd be rather surprised if the .NET runtime was cleaning up my LV references...

JZ

[Yair]

A zombie thread indeed, but it is a valid point.

QUOTE(Big Hank @ Jan 24 2008, 09:57 PM)

The .Net Framework Grabege Handler will clear All Unreference Objects when Fired

The key phrase here is "when fired". The garbage collector is only called when the top level VI in the hierarchy is done executing. Until that point you can have memory leaks if you don't close the references, and since some people (me, for instance) have programs which run for months and years without being closed, closing references is a good practice.

Additionally, some .NET classes require calling dispose methods. My understanding is that if the disposed method is implemented using the IDisposable interface, then it will be called automatically when the reference is closed, but if it is not, then it must be called explicitly.

You can find some more specific details http://detritus.blogs.com/lycangeek/2006/05/how_to_say_good.html'>here.

[Rolf Kalbermatter]

QUOTE(Yen @ Jan 25 2008, 06:52 AM)

A zombie thread indeed, but it is a valid point.

The key phrase here is "when fired". The garbage collector is only called when the top level VI in the hierarchy is done executing. Until that point you can have memory leaks if you don't close the references, and since some people (me, for instance) have programs which run for months and years without being closed, closing references is a good practice.

Additionally, some .NET classes require calling dispose methods. My understanding is that if the disposed method is implemented using the IDisposable interface, then it will be called automatically when the reference is closed, but if it is not, then it must be called explicitly.

You can find some more specific details http://detritus.blogs.com/lycangeek/2006/05/how_to_say_good.html' target="_blank">here.

Yen you are right here, but there needs to be some extra clarification since a LabVIEW refnum is a memory resource too, and I have trouble to believe that .Net will have any influence on the life time of that refnum itself, even if .Net has a very smart Garbage Collector.

It may invalidate (but probably won't since the LabVIEW refnum holds a reference to the .Net object) the .Net resource that was referenced by the refnum, (and possibly though not for sure, the Not A Refnum node may be able to detect that too), but it most likely will not dispose of the LabVIEW refnum before the Top Level hierarchy that created it goes idle.

So Your concerns are fully valid and Big Hanks claims are likely to be not the full story with using .Net in LabVIEW.

Rolf Kalbermatter