Problems using .NET in LabVIEW

[Anonymous]

I'm having two problems attempting to use a .NET class library in
LabVIEW. I was wondering if anyone could help suggest a solution or
workaround:

(1) .NET exceptions are not turned into LabVIEW errors. They are
shutting the VI down. Is there a way to catch .NET exceptions in
LabVIEW?

(2) The .NET library I'm using uses default indexers. I cannot seem to
access the indexers from LabVIEW. And the "Index Array" block does not
connect up to the .NET class instance.

Many thanks!

- Kevin Hall

[Lycangeek]

1. Hmmm, they should be going into the error clusters. When you say it closes down the VI, do you mean LV crashes, the VI disappears, or what?

2. I'm not sure what you mean by indexers. Do you mean the enumeration pattern? Are you using ArrayLists?  The reason I ask is that we convert .NET arrays (but not ArrayList objects) into LV arrays. Could you post an example of what you're trying to do?

Also, which version of LV are you using?

We'll get this sorted out 🙂

[Anonymous]

Thanks for the reply.

The LabVIEW version I'm using today is LabVIEW 8.0 evaluation version
(until my company purchases the licenses we need for development --
which are likely to be the Basic version).

About indexers.... I was refering to "default indexers". C# does not
like indexed properties, so if you want to make life easier for C#
programmers, you have to make a property that returns a proxy class
that may then be indexed into. Here's the C++/CLI code used to create
the default indexer:

ref class Internal_Property_Axis
{
public:
delegate Mpx::Axis^ GetMethod(long);

private:
GetMethod^ getter_;

public:
Internal_Property_Axis(GetMethod^ getter) : getter_(getter) {}

// DEFAULT INDEXER HERE
property Mpx::Axis^ default[long]
{
return getter_(index);
}
};

Now my problem in LabVIEW is that I can access the proxy class
(Internal_Property_Axis in this case) just fine. But LabVIEW doesn't
list any methods or properties for the proxy class. It does not see
the default the indexer property. I've tried the "Index Array"
block, but that doesn't seem to work. So there is no way I know of for
me to access the sub-class.


About the exceptions. I'm sorry, the VI didn't die. LabVIEW does
catch the exception and produce an error cluster. What I can't figure
out is how to get the exception information out of the error cluster.
All I can seem to do is get a general LabVIEW error along the lines of
"Exception occured in the .NET library". I don't know how to get the
type information or data members of the .NET exception. I also can't
find any explanation in the LabVIEW help documentation. Any help you
can provide will be very valuable to me and I will be very, VERY
grateful.

Many, many thanks!

- Kevin Hall

[Lycangeek]

As I'm on the road traveling, I probably can't answer for sure on the indexer question right away - I'll need to build one and see what's going on, but I didn't want to leave you hanging.

As far as the exceptions go, yes *sigh*, I'm afraid there isn't a way to get the exception information programmatically. It is something that we are interested in improving, but it simply hasn't made it up to the action list yet...However, as a semi-palpative, I put in a "feature" in LV 8 to debug-out the full exception information. If you go to www.sysinternals.com and download their Debug Viewer (dbgview.exe), you'll be able to see all debug-out information written by anything running on your computer. Typically this isn't much, because as the name implies, it's debug stuff. But, if the LV code captures a .NET exception and converts it into an error cluster, it'll first write out the message and stack trace to the viewer.

I'll get back to you as soon as I can on the indexer.

[Anonymous]

The error I am getting is:

Source: "Type 'Mpx.Exception' in Assembly 'MPXNET, Version 1.0. ...'
is not marked as serializable. in test.vi

Code: 1172

Status: Red check mark (True?)

Mpx.Exception is derived from .NET's System.Application exception. I
can dissasemble the error cluster, but I don't know how to get a
reference to the exception. Any help would be greatly appreciated!

[Anonymous]

Ok, I found an answer to the exceptions question on the NI forums (that
you gave Lycangeek 😉 😞


http://forums.ni.com/ni/board/message?board.id=170&message.id=164302

Unfortunately, it's not what I wanted to hear. I have to agree with
the OP in that thread -- it would be very nice if LabVIEW nodes had an
exception output. Other possibilities could include the error cluster
including a .NET exception or the error cluster being convertable to
the .NET excetption.

I'm sure there are a lot of design decisions and constraints that I'm
not aware of -- but the point is that not every VI can assume to be
single threaded, most .NET libraries were not designed with LabVIEW in
mind, not every .NET library has a "last error" global property, and
that many .NET libraries were designed using exceptions for error cases
and assuming that the exception information could be usefully
extracted. Consequently, it would make LabVIEW much easier to use if
..NET exceptions could be available for analysis.

- Kevin Hall

P.S. I'm still curious about default indexers. If you have any
information about that, please let me know. Thanks again!

[Anonymous]

Brian,

I just found out you have been replying to me in the NI forums. I've
been posting using Google Groups (GG hereafter) and for some reason
your first reply showed in GG, but not your subsequent replys. I'll
check and post (or try to anyway) in the NI forums from now on.

For those of you browsing from Google Groups, here's the link to the NI
Forums thread:


http://forums.ni.com/ni/board/message?board.id=170&message.id=172709&query.id=79658#M172709

Thanks again for you help!

- Kevin

[ZMeson]

Thanks for the hint with the exception information.  Lucky for me, I'm helping develop the .NET library.  So I'll see what can be done about adding a "last error" property.

But LabVIEW support for this library is more for the OEM testing departments, while C# and VB interface is meant for the production code.  So while LV support is important, I don't know how much the guidelines can be bent since C# and VB are the larger audiences.  I don't think it will be traumatic (still unfortunate though) to add the last error property.  Finding a way to access the default accessors is the more critical item today.  (I know you're on the road and won't be able to get back to answering this right away.)

Thanks again for the help.

- Kevin Hall

P.S.  Mirroring the NI Forums into a usenet group is pretty slick!

[Lycangeek]

I must emphasize that I don't recommend the Last Error approach as a solution, but merely a workaround - it isn't where I want LV to be for .NET support, merely were we find ourselves at the moment.

By the way, I do strongly recommend to keep your class library and your wrapper seperate - especially when your library is meant to go out to customers. You're wrapper merely contains the try/catch along with the Last Error property.

[ZMeson]

> By the way, I do strongly recommend to keep your class library and your wrapper seperate - especially when your library is meant to go out to customers.

I understand (at least I think so) and believe we're doing that.  Our class library is actually a thin C++/CLI wrapper around a C++ library.  The The C++ library is a simplification (an Adapter library from a GoF design patterns viewpoint to a simpler interface) over a C library.