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

[Robbob]

Ben already knows this, but for others following the thread, the reference became invalid because an array of references were being typecast instead of a scalar reference. The fix shown below is implemented with an index array.  NI does not recommend typecasting references unless you are very familiar with the underlying data, as it is easy to make mistakes.

As far as contexts are concerned, I believe the specified context was generic in that LabVIEW said 'I can't find this refnum, therefore it isn't valid in this context' since if lv cannot find an active reference of that type, we have to keep the possibility open that it may be valid in another context, aka project. TST was spot on for the definition of a context...the most common context is simply a project. I will try and dig to get a more 'official' definition and maybe some more examples related to lvoop; our next meeting with our lv experts is on Wednesday. I will post if I find more useful information.

Message Edited by Robbob on 01-11-2010 05:13 PM

[Ben]

That reply only prompts more question you know!

Yes that index array stopped my crashing but...

1) What is the "right way" to create queue ref that is linked to a type-def that does not use the Type Cast?

2) If you look at the Probe #[15] in my orignal post, you will see that the "CommandQue" is NOT showing invalid, it is the response queue that was invalid.

Ben

[Ben]

Hi Rob,

I am familiar with concept of "process context" since I used to do crash-dump analysis on mainframes. What I am looking for ideally is a white paper that has not been written yet that describes each of the process contexts that we should expect our code to run in and when and under what circumstances these contexts are used.

Prior to LV 8 the only time we encountered the concept of process context was when we had exe's talking to each other or to the development environment.

From the discussion above the idea to run the XControls in a sperate conext was thrown out.

Different Projects use different context.

Neither of those two cases explain that message I showed above since the VIT was in the project and created by a VI in the project.

So what context is that message talking about?

Ben

[tst]

---

Ben wrote:

1) What is the "right way" to create queue ref that is linked to a type-def that does not use the Type Cast?

---

In later versions of LV you only have to create the queue indicator after wiring the typedef into the type input of the Obtain Queue primitive. I'm not sure why that wouldn't work, but if it doesn't, you can also simply drag the typedef into the queue indicator, which will now connect that queue indicator to the typedef.

The queue indicator itself does NOT have to be a typedef. It updates automatically when you change the queue data typedef.

[Ben]

---

tst wrote:

---

Ben wrote:

1) What is the "right way" to create queue ref that is linked to a type-def that does not use the Type Cast?

---

In later versions of LV you only have to create the queue indicator after wiring the typedef into the type input of the Obtain Queue primitive. I'm not sure why that wouldn't work, but if it doesn't, you can also simply drag the typedef into the queue indicator, which will now connect that queue indicator to the typedef.

The queue indicator itself does NOT have to be a typedef. It updates automatically when you change the queue data typedef.

---

That is how I create the control that I subsequently customize and save as type def. That type-def is what I have in my Class data and is also the output passed to the caller. Without the type-cast I get coercion dots as shown below.

 

Ben

[tst]

Presumably you wouldn't get coercion dots if you didn't make the control a typedef, but instead allowed LV to take care of it by only having the queue data a typedef.

I can't say whether this is good practice, since there's no official documentation which says that a queue ref will adapt to the typedef that's inside it, but it seems to be a reasonable thing to expect and you know how to get NI not to drop support for it.

[Ben]

---

tst wrote:

Presumably you wouldn't get coercion dots if you didn't make the control a typedef, but instead allowed LV to take care of it by only having the queue data a typedef.

I can't say whether this is good practice, since there's no official documentation which says that a queue ref will adapt to the typedef that's inside it, but it seems to be a reasonable thing to expect and you know how to get NI not to drop support for it.

---

Sometimes I wonder if we are inventing "good pratice" as we go by trial and error.

I have not tried it recently but changes to the type-def'd data structure carried by the queue don't get reflected in the queue ref if it is not type-def'd. This is important to me in this app since I am "inveting it" as I go and that cluster will be subject to many changes as i embelish this code.

Ben

[tst]

---

Ben wrote:

...changes to the type-def'd data structure carried by the queue don't get reflected in the queue ref if it is not type-def'd.

---

They do get reflected or I would not have suggested it. I believe it began behaving this way since ~8.0.

[Ben]

---

tst wrote:

---

Ben wrote:

...changes to the type-def'd data structure carried by the queue don't get reflected in the queue ref if it is not type-def'd.

---

They do get reflected or I would not have suggested it. I believe it began behaving this way since ~8.0.

---

Well that is wonderful news. Thank you! Of course I'll have to try it myself to be sure I understand you. But if so that is a nice change and will save me a lot of headaches keeping the queue refs updated. I would love to be able to toss that old habit.

Ben

[tst]

I don't remember for sure, but this may also work in older versions if you drag the typedef into the queue reference (you can see the queue type if you right click the reference and select "Show Control").

The problem with this, as I said, is that it's not documented, which means that you have to go against the good practice of making a distributed data type (the queue ref) a typedef without anything official to back you up.