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

[tst]

---

Aristos Queue wrote:

I would've guessed LV 6.1, but you've made me doubt myself, so we'll go with 8.0 for now. 

...

---

I think what I'm thinking about is that if you created a queue reference indicator from the obtain queue primitive in earlier versions it did NOT automatically link to the typedef. You had to either make the reference a typedef as well or know the trick of dragging the data type into the reference (which you have to admit is not something most users know).

---

I'm not sure what part isn't documented. You can drag any type onto the queue control/indicator to set the type of the queue's data, including typedefs.

... 

I don't see anything wrong with not typedef'ing the queue

---

Niether do I. It's much better.

BUT. It's much better IF and ONLY IF it's guaranteed that every instance of that reference will update correctly when I update the typedef today and in future versions. I'm pretty sure that's not documented and from a user's perspective, what's not documented is subject to disappear (even if the great AQ declare this "officially recommended practice").

Which isn't to say I don't do this. I never typedef my queue and notifier refs. I do rely on this behavior because I do see it as a feature. It's just that as long as it's not officially clear that it's there to stay, I am technically doing something which is against the standard best practice.

[AristosQueue (NI)]

---

tst wrote:

BUT. It's much better IF and ONLY IF it's guaranteed that every instance of that reference will update correctly when I update the typedef today and in future versions. I'm pretty sure that's not documented and from a user's perspective, what's not documented is subject to disappear (even if the great AQ declare this "officially recommended practice").

---

I wouldn't have thought of that as something needing documentation. The queue control includes an instance of the typedef control. When you edit a typedef, all instances everywhere update, no matter where they are. It wouldn't have occurred to me that "including those instances included in the queue controls" needed to be explicit. We can certainly add that to the docs if you think we need to... is there a particular document that you have in mind, or just somewhere in the shipping documentation?

[tst]

To be honest, I don't mind that much (as I said, I already use it) as long as we know that no one is going to remove it (which is less likely now that every queue reference created from a typedef'ed queue links to the typedef automatically. It could probably be added to the main queue page in the help and to the Obtain Queue help page.

I'm guessing this dissonance arose mainly because in the past the reference didn't have the auto link, causing us not to automatically trust that auto link.

[AristosQueue (NI)]

Well, this has been an exciting evening digging into this bug...

1. We all know about the dangers of casting refnums by now. In the VI hierarchy, there's a cast of a Queue of Array of Object refnum into a Queue of Object refnum. What I discovered tonight, weirdlly, is that LV 8.5 does not crash when you have this bug on your diagram, but both 8.6 and 9.0 do. As I said before, casting refnums to other refnum kinds is dangerous, and it's worse when it appears to work.
2. I fixed the VIs by inserting an Index Array call so that the queue was created with the right core data type. I then tried to probe the Write Connections.vi to replicate the bug that Ben originally posted about.
   A) I did replicate the bug in LV 8.5.
   B) LabVIEW 8.6 and 2009 both crash if you have the probes set on the diagram. I tested the yet-unreleased 2009 SP1 and it also crashes with the probes set.
   
   ARGH. 
3. [Later] Ok. I have tracked the bug to its lair. LV 8.5 and 8.6 and 2009 all have the same bug, but in 8.6 and 2009 it is a DAbort because someone strengthened the error checking of probes to cause LV to quit early if the probes start showing incorrect data. In other words, in LV 8.5, we detected that there was some problem, though we didn't know exactly what, with the info being shown in the probes, and returned an error. That error was silently logged but no one ever noticed and thus never CAR'd it for fixing. In 8.6, the error was trapped and turned into a shutdown of LV, presumably to keep customers from continuing to work on a corrupted LV -- any time probes start being corrupted, that means bad data exists somewhere, and although emergency shutting down LV may mean loss of work for a customer, allowing LV to continue running may mean that the corrupt data gets saved into their VIs and their VIs become unloadable, resulting in even greater loss of work. But this existing bug with the probes was still not noticed until now. 
4. [Even Later] I now have a fix for the bug in 2009, but it is too late to put it into 2009 SP1, so I'll be putting it into LV 2010.
5. I'm not sure if I can propose a workaround for the bug. If I think of one, I'll post it here.

[Ben]

---

Aristos Queue wrote:
Well, this has been an exciting evening digging into this bug...

...

---

A couple of points...

All of my work was done in LV 8.5.

The queue ref habit (that I will try to quit) was one I adopted after being burned by the queue data type not updating in some earlier version. Maybe it was bug that I did not realize.

The idea of using a class instead of a type-def cluster in the queue that I did use in one of the queues (based on something I read by you (Aristos) saying "You should think class instead of type-def"... or something to that effect. I did that for the one queue (the command queue) that I thought would be generic across all of the children. For the other response queue, I was thinking that could cause me problems with children of this class latter when I started to implement over-rides leading me to require a Polymorphic Dynamic dispatch VI that as I understand is not supported.

This code and the adventure leading up to it is a self defined learning exercise intended to make me more familiar with the how to use LVOOP while at the same time harness the LVOOP power to let me develop more faster. SInce I am often creating background threads to do something while other things are happening, I takled this challenge of writing all of that...

Create the cmnd q

Create teh respons Q

Run the VIT

Check if it started

Tell it do something

check if it has errors

Monitor its performance and determinsim

Tell the widget to shut down

Kill a Q

Kill another Q

Squash the process if it hung

stuff ONCE and then just create a new child that inherits all of those capabilities.

When it hit me that I could write one generic VIT and that by using Dynamic dispatch I could change it personality completely, I had to give it a try.

Again thank you for your dedication and support!

Ben

[DFGray]

One more point which is slightly pertinent to this conversation and has bit me more than once.  If you have nested typedefs and update one of the lower level ones, the change will only propagate a maximum of about two levels.  If you have nested more than this, you will need to close the code and reopen it to get everything to update properly.  In LabVIEW 8.0, doing this type of change with lots of code open could crash LabVIEW and possibly corrupt code.  This was fixed in LabVIEW 8.2.

I usually close other code when I am updating typedefs.  This makes the problem a non-issue.

[tst]

---

DFGray wrote:

If you have nested typedefs and update one of the lower level ones, the change will only propagate a maximum of about two levels.

---

I don't remember ever running into anything like that, and I'm pretty sure I had cases of something like 4 or 5 nested levels of typedefs (as in an enum inside a cluster inside a cluster inside a cluster inside a cluster).

[Ben]

---

tst wrote:

---

DFGray wrote:

If you have nested typedefs and update one of the lower level ones, the change will only propagate a maximum of about two levels.

---

I don't remember ever running into anything like that, ...

---

I have.

Ben

[AristosQueue (NI)]

I was confused by DFGray's last comment. I went to talk to him and got some clarification.

Nested typedefs work fine -- don't be afraid of using multiple levels of typedef nesting. What DFGray has seen is that if you have the windows open for all of those typedefs, and you edit the lowest level typedef, changes will be made to the upper level typedefs, but those upper level typedefs won't apply their changes to their instances unless/until you close the front panels of those upper level typedefs. 

Now, I've never seen that bug and I'd like to confirm its existence and/or behavior. I'm interested because the code that updates typedefs is the same as the code that updates LV classes, and I haven't heard of any problems in my team's domain.  Can someone give this a try today and confirm it still happens in LV 2009 and exactly what the behavior is?

[Ben]

Not in 2009!

In prior versions I found myself going through all of my classes and right-click save all this class. I would see a flash of the save screen. I would keep it up until I stopped seeing the save screen flash.

Ben