Jump to content

.NET Style DataBinding from LV 8.2?


Recommended Posts

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

Link to comment
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!

post-6932-1164718617.jpg?width=400

Download File:post-6932-1164719124.vi

Link to comment

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.

Link to comment
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)

Link to comment

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.

Link to comment
  • 1 year later...

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

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.