What does "refnum not valid in this context" mean andwhat are the ground rules for when a queue refernce is valid or not?

[Ben]

This Question is being posted to help us learn more about LV. 

Item "B" in this image shows a probe with that message.

What does it mean?

How can I make it valid?

What I am hoping for is that someone will check with the Ivory Tower and give us a nice definition and cast some light on the topic "context" and how it relates to queue references.

Ben

PS Source (in LV 8.5) of the above can be found in Dr. D's Tale of Two Servers Nugget here.

Message Edited by Ben on 01-05-2010 08:33 AM

[tst]

I think the basic answer is very simple. Basically, "Context" is the same as "Application instance". Whenever you run LV 8.x, you get several contexts, with each project you open being its own context (which you can see in the bottom left corner of each window) and a few others (such as the main context and the one that items called from the menus are run in).

A context basically defines a boundary, as if you're running two instances of LabVIEW in parallel, so that (for instance) you can have two VIs with the same name open in two different contexts without collision. The same also applies to references - a reference opened in one context is not valid in any other context (unless you're using 8.0, which had a bug which allowed this).

I don't have a good answer for your question there, but I suspect it might be a bug.

[Ben]

---

tst wrote:

I think the basic answer is very simple. Basically, "Context" is the same as "Application instance". Whenever you run LV 8.x, you get several contexts, with each project you open being its own context (which you can see in the bottom left corner of each window) and a few others (such as the main context and the one that items called from the menus are run in).

A context basically defines a boundary, as if you're running two instances of LabVIEW in parallel, so that (for instance) you can have two VIs with the same name open in two different contexts without collision. The same also applies to references - a reference opened in one context is not valid in any other context (unless you're using 8.0, which had a bug which allowed this).

I don't have a good answer for your question there, but I suspect it might be a bug.

---

Thanks Yair.

I agree with everything you said. From all that you wrote and what I know, everything should be running in the same context. Maybe I'm missing something with how LVOOP works or using a template to realize my object.

I should add another question:

What code/project context foreces/uses multiple context?

In early release notes etc for LV 8.0 (or there-about), XControl where "supposed" to run in a different context but I have never seen evidence of that in XControls since I can queue back and forth to them.

Ben

[DFGray]

I can not help with your original question, since my usual sources are still on vacation or otherwise indisposed and I have not had time to dive into the problem (still dealing with the after effects of a two week vacation).  However, I can comment on the XControl.  In LabVIEW 8.0 through (I believe) LabVIEW 8.2, XControls ran in a different context.  In 8.0, it was possible to send queue messages across a context boundary, so you could message an XControl in 8.0 using queues.  This behavior could crash LabVIEW in some situations, so queue use across context boundaries was forbidden as of LabVIEW 8.2.  You have to use control references and Value (signaling) properties or something similar.  In LabVIEW 8.5 (I think, could have been 8.6), XControls were moved back into the owning context to solve problems with the XControls, so queues worked again.

Contexts are generally used by the LabVIEW team to hide running LabVIEW code so it is not an annoyance.  For example, the FPGA Wizard, a LabVIEW application, runs in a separate context to prevent its hundreds of VIs from showing up in the VI hierarchy, causing more than a minor annoyance.  LabVIEW has several standard contexts for this purpose.

At this point, I speculate your problem is caused by a circular reference due to having a queue reference to the object inside the object (worked in 8.2, does not work in 8.5 and above).  I do not, know, however, so take this with a grain of salt.  It could also be as simple as the code which created the reference going out of memory, but since the reference is good in other places, this is unlikely (given your experience level is it very unlikely  ).

[Ben]

---

DFGray wrote:

I can not help with your original question, since my usual sources are still on vacation or otherwise indisposed and I have not had time to dive into the problem (still dealing with the after effects of a two week vacation).  However, I can comment on the XControl.  In LabVIEW 8.0 through (I believe) LabVIEW 8.2, XControls ran in a different context.  In 8.0, it was possible to send queue messages across a context boundary, so you could message an XControl in 8.0 using queues.  This behavior could crash LabVIEW in some situations, so queue use across context boundaries was forbidden as of LabVIEW 8.2.  You have to use control references and Value (signaling) properties or something similar.  In LabVIEW 8.5 (I think, could have been 8.6), XControls were moved back into the owning context to solve problems with the XControls, so queues worked again.

Contexts are generally used by the LabVIEW team to hide running LabVIEW code so it is not an annoyance.  For example, the FPGA Wizard, a LabVIEW application, runs in a separate context to prevent its hundreds of VIs from showing up in the VI hierarchy, causing more than a minor annoyance.  LabVIEW has several standard contexts for this purpose.

At this point, I speculate your problem is caused by a circular reference due to having a queue reference to the object inside the object (worked in 8.2, does not work in 8.5 and above).  I do not, know, however, so take this with a grain of salt.  It could also be as simple as the code which created the reference going out of memory, but since the reference is good in other places, this is unlikely (given your experience level is it very unlikely  ).

---

Thank you Dr. Gray,

Yes I would still want nice formal answer to those questions because it would help me avoid designing my way into a crash, so when your resource get back, I'd like to learn more.

I did deliver an app with a circular ref in LV 8.2. So i'm stuck at 8.2 for tht one huh? The good news is was fixed price and has been delivered. I'll cover my head when they come back and ask to upgrade.

As far as the code above, circular refs are not the answer, but... the crashing on shutdown... could be realted to my queues getting killed at the wrong time...

Ben 

[Ben]

Bump!

Can an AE get invloved now please?

Ben

[Ben]

I still feel that the question above is appropriate for this forum and am wondering why no AE is relying.

Do I have to log a servcie request to get an answer?

Feeling like I am being ignored,

Ben

[Ben]

I logged SR # 1471189 to get an answer.

Ben

[Robbob]

Hey Ben,

You are not being ignored. I was hoping the dialogue sparked by TST and Dr Damien helped shed some light on contexts. I did access the source from the other thread and have been playing with it. I will try and bring this up at our next LabVIEW experts meeting to get some clarification on the contexts and the invalid refnum, but I was attempting to find some concrete information before jumping in the conversation.

Dr Damien, did you have a chance to talk to your resources?

[Ben]

---

Robbob wrote:

Hey Ben,

You are not being ignored. I was hoping the dialogue sparked by TST and Dr Damien helped shed some light on contexts. I did access the source from the other thread and have been playing with it. I will try and bring this up at our next LabVIEW experts meeting to get some clarification on the contexts and the invalid refnum, but I was attempting to find some concrete information before jumping in the conversation.

Dr Damien, did you have a chance to talk to your resources?

---

Sorry I had to punch the GO button but I am a creature with a grand goal in mind.

As far as that code goes, talk to Charley who's working SR #14368867. He reported that crash will be VAR'd early next week.

As far as this thread goes, please focus on those Q's I posted above since those answer should help us navigate the various contexts LV runs in. There really should be a white paper on this subject but for the time being just getting answer to the Q's above should help us.

Ben