Why can't I store a .net reference in a functional global?

[gnunesjr]

I am working on a project that needs to communicate with other programs via an Active MQ messaging system.  Another guy on the team wrote .net assemblies (not my thing), and I strung them together in a LabVIEW test program (not his thing).

In my test program, everything works perfectly, so the problem is with my LabVIEW and not his assemblies.  In the test program, all the .net action is in a single VI, and the various steps (constructor node, property node, invoke nodes, blah, blah) are all strung together with wires.

But...in real life, I need to establish a connection to the queue, and then send messages from other states (and therefore from inside other VIs) far from where the the connection was established.  In principle, I could do it all with wires, but when planning out my project, I decided that would be way too painful.  So, I had the clever idea to store the reference in a functional global, which doesn't work.

In order to properly create the inputs and outputs to the FG, I used the "right-click: create ->" method, and when I wire everything up, I don't get any red exes.  When I establish the connection, I can see the reference going into the FG. But when I try to read it out, I get either "Refnum no longer valid" or "Not a refnum".

Anyone know a solution?  This thread implies that I could "try" storing the reference in a shared variable, but I need to learn as few new tricks as possible in order to meet my deadline.  I could maybe go for it if it was a "definitely" instead of a "try"....

Thanks in advance,

-Geoff 

[gnunesjr]

...and a follow up, just to reveal my ignorance.  What is a ".net object"?  I tried to convert the refnum to a variant using the .NET Object to Variant vi, and store that in a functional global.  [What the hey...it's on the same palette with the rest of the .net stuff, it uses the same kind of skinny green wire, and when you "right-click: create" front panel objects they look just the same.  This is all a good indication of LabVIEW legality---outside of dealing with .NET!]  Of course, I should have been tipped off by the little red type-conversion dot...

When I tried to unflatten the variant using the To .NET Object vi, I got a broken wire.  The error window says "You have connected a refnum of one type to a refnum of another type and both types are members of some class hierarchy, but there is neither a simple up cast nor type cast between the two classes", to which I reply  "Pfffffffttt!  If only I had a clue what you mean!"

Well, any help would be appreciated.  In the mean time, I'm planning how to add a lot of wires to my VIs....

-Geoff N. 

[tst · Accepted solution]

My guess would be that you are missing some point about the scope or lifetime of references in LabVIEW.

In general, a reference in LabVIEW is valid:

1. Within the application context it was created in (this is usually a project or an executable built with LabVIEW).
2. As long as it's not explicitly closed by the user.
3. As long as the top level VI in the hierarchy where it was created keeps running. Once it stops running, all the references in the hierarchy are automatically closed.

My guess would be that you're running into 3 (e.g. if you're trying to run the FG by itself), but the other options are also possible. Telling for sure would be impossible without seeing the code. You could try writing a small piece of test code just to see how to get it working and then go from there.

You should also read this. It deals with closing refnums, but you should be able to learn from it. The rest of the blog has other relevant stuff and there's all kinds of information about LV and .NET online. 

As for how refnums work in general, that's a subject for a much longer post, but what you described sounds weird. I can understand the code throwing at error at run-time, since what you described would not work (try reading the help for the VI to understand why), but I don't see how you managed to break it.

You might also try looking at some of these tutorials to get a better feel of LabVIEW itself and why it does certain things.

[tbd]

Hi Geoff,

      It sounds to me like your usage is "Within the application context" - as tst says - and should work, though,  are you doing any "call by name". 

Can you attach the FG? 

Have you checked whether the FG is getting accidentally re-initialized with a bogus reference?  (I'd make the "write/read"/"function"/"mode" - or whatever you called it - control input "required".)

Cheers!

[Britoa]

Without echoing everyone else, check to make sure your shift register is of the right datatype.  If it's not, it may be casting it into an invalid refnum.  (do NOT use "Use default if unwired")

[smercurio_fc]

I can tell you that it's quite possible to store a .NET reference in a functional global, and no special jumping through hoops is required. I did it for one project. Thus, all your .NET to variant code is not necessary. The key, as tst mentioned, is that the top-level application must still be running. Otherwise, the references are automatically closed.

As for your question:  "What is a .NET object?"... To put it simply, a .NET object is an instantiation of a .NET class. If you don't know what that means, then the best thing to do is to hunt the net for a quick overview of object-oriented programming. 

[gnunesjr]

Thank to all for your help!! 

As suggested, my basic problem was not understanding that refnums are special.  I was treating them like any other wire.  Once I put together a calling program that called my various VIs---and stayed up and running, I discovered that my functional globals and everything else all worked just as I had expected them to. 

When I started out, I was attempting to do a preliminary debug by running each VI as a stand alone.  Often this is a good idea, but in this case, not! 

I leave this thread a tiny bit smarter than when I came in.

Thanks again!

-Geoff