LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

.NET Components: How do I create exported methods and generate interrupts in C#?

I have a Front Panel which consists of a custom made .NET Component written in C#:
 

If I go to the .NET Component in my Block Diagram and right click and choose "Create" -> "Method for TestingDotNet.TestingDotNetControl Class" I get big list of methods my custom .NET Component supports.
Q1. If I want to add my own methods to the big list, what code should I add to my Visual Studio Project?
 
Let's say the user pushes the button on the custom .NET Component.
Q2. Can this button press generate an interrupt to a LabVIEW Event Structure outside of my .NET Component?
Q3. If so, please provide some simple guidelines/tutorial as to what I should add in my Visual Studio Project.
 
I have never before programmed in C# and this is my first .NET Component so please have that in mind when replying. If anybody can provide snippets of sample code, I'd be most grateful.
0 Kudos
Message 1 of 10
(4,045 Views)

I can't help you with the specifics, since I don't do .NET (and I have LV 7.0, which doesn't have support for .NET controls), but I suggest you search the example finder (Help>>Find Examples) for some examples of how to use this. If I remember correctly, you need to register callback VIs which execute when your registered event happens.

You might also wish to search the site, because it probably has some tutorials on this.


___________________
Try to take over the world!
0 Kudos
Message 2 of 10
(4,043 Views)

Hi Arnold,

First off, since you are a beginning C# developer, here are a couple suggestions:

- Get a good book on C# development
- Check out the .NET LabVIEW examples (we even have a couple of .NET event examples). To access those examples, just open up the NI Example Finder and then navigate to the Communicating with External Applications >> .NET directory.
- Read through the Using .NET with LabVIEW help topic (which talks about events) to get a good feel of how things work.

Secondly, in order for any environment to see methods you have created, you need to make them public.  For example, if I created a .NET User Control and I wanted a couple of methods exposed to LabVIEW, I would say something like:

public int myMethod1(int a, int b)
{
   return (a + b);
}

public void myMethod2(int test)
{
       //// DO SOMETHING ////
}


These are basic principles of .NET programming and Microsoft's website has tons of examples. Here is a small CodeProject tutorial on writing methods and properties in C# found here

As far as events go, your C# assembly needs to set up the correct delegates.  Delegates can be an interesting rascal and somewhat confusing if you are just starting out so I would strongly encourage you to do your research first.  Make sure you understand how setting up events and delegates works in C# first and then move it over to LabVIEW. Otherwise you will confuse yourself.  Here is a nice little tutorial on working with delegates and events in C# found here.

Also, here is a link to another post in which we show the source code for one of our .NET assemblies used in a example. 

Hope this helps!

Best Regards,

Jonathan N.
National Instruments
0 Kudos
Message 3 of 10
(4,025 Views)
By the way, as I mentioned in the other thread, it's probably best to stick to a language you know and it would definitely be better than trying to learn two new languages. Smiley Tongue
You can use the functions LV uses by calling the same DLL LV calls or you can trying getting NI software which already has an exported C interface (e.g. download the CVI evaluation and just use the functions it exports, although I'm not sure if the evaluation license permits that). I know that the LabVIEW drivers for NI's hardware come with the hardware. Is this not the same for the C drivers?

___________________
Try to take over the world!
0 Kudos
Message 4 of 10
(4,023 Views)

I think the dynamic callback event registration in LabVIEW is kind of complicated. Do I have to use dynamic event registration, can't I use static events in a regular Event Structure?

0 Kudos
Message 5 of 10
(3,997 Views)

I got the event callback working, but it seems to me that I must place my callback code in a seperate VI. When the event occurs, I would like to execute a piece of code that resides in the same VI as the .NET Component. Is there an appropriate workaround for this? If you know the answer to this quetion or the question in my previous post, please reply.

0 Kudos
Message 6 of 10
(3,990 Views)

My understanding is that for a callback you have to use a seperate VI. I realize this isn't as convenient as having everything in the same VI, but there is probably a reason for this (yes, Jonathan, I wouldn't mind hearing that reason Smiley Happy ). I can understand how after being used to C development you will find it annoying having to create a million files for your code.

It really does seem to me that you are hurting yourself by using tools you don't know that well. Don't get me wrong, I think LabVIEW is great, but unless you've made a decision to do regular development in it (or are interested in learning new languages), you're probably better off (and the resulting code will probably be better) if you use a language you know. If you provide more details about the features you need, we can probably tell you if there are alternatives (other than the ones I already mentioned).


___________________
Try to take over the world!
0 Kudos
Message 7 of 10
(3,977 Views)
Hi arnold,

Yes, callback VIs are required for handling both .NET and ActiveX events.  Events that are fired from .NET will not be handled in the LabVIEW event structure.  Instead you will be using the LabVIEW event handler.  The difference between these two concepts is subtle but very important. The LabVIEW event structure is used for events generated within LV and the event handler is used for things generated outside of LabVIEW.  The reasons for this architecture are mostly because of the technical issues with threading and avoiding deadlocks.  Basically there is a difference in the threading models. 

Best Regards,
Jonathan N.
National Instruments
Message 8 of 10
(3,953 Views)
Thanks a lot for your time and help. Unfortunately, these were not the answers I was hoping to get, but I'm nevertheless grateful for your assistance. I think this thread can be closed now and I will start new threads for my future questions.
 
tst:
In order to maximize flexibility and speed up the development (in the long run), I would prefer to do the control part of my GUI's in something else than LabVIEW. I don't think I can convince my boss to buy anymore tools so I have to stick with what I already have (LabVIEW 8.2.1 and Microsoft Visual Studio .NET). I have lots of experience with C and Java and I've done some C++ and MFC programming as well. I feel confident that I can learn C# quite easily and I've heard a lot of good things about C# so it will be a pleasure to do so.
0 Kudos
Message 9 of 10
(3,927 Views)

There's nothing wrong with writing a single product using two different languages, as long as there is a good reason for it and that the boundaries for what each language is supposed to do are well defined. The UI is probably not a place where you would want to place such a boundary. It would probably be more logical to create DLLs in LV to provide the functionality that you want and call those from C# rather than trying to mish-mash the two languages together to handle your UI (although I'm still not clear on where it is you want to do the UI).


@Jonathan N wrote:

The reasons for this architecture are mostly because of the technical issues with threading and avoiding deadlocks.  Basically there is a difference in the threading models. 

OK, now we know that you know. Can you give us some of the gory details?
And go easy... I have practically zero understanding of .NET. Smiley Very Happy


___________________
Try to take over the world!
0 Kudos
Message 10 of 10
(3,920 Views)