09-25-2007 06:33 AM
09-25-2007 07:04 AM
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.
09-25-2007 09:15 AM
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,
09-25-2007 09:39 AM
09-27-2007 04:33 AM
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?
09-27-2007 06:20 AM
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.
09-27-2007 11:52 AM
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 ). 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).
09-27-2007 04:35 PM
09-28-2007 03:01 AM
09-28-2007 06:49 AM
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.