Typedefs: Cluster Order with SubPanels Confusion

[CoastalMaineBird]

OK, thanks.  Issue #1 is deadly serious - I have to depend on the values it shows being from the execution I just did.

Am I supposed to run it AFTER I insert it into the subpanel?

[Kevin_H.]

It would appear that #1 you have to place the call by reference node AFTER the invoke node. This eliminates the behavior. I'm not sure why this is the case and will be filing a CAR on it today. I wasn't able to recreate #2, and I didn't quite understand what you meant by #3.

[CoastalMaineBird]

Issue #1:  OK, so I need to do things in the reverse order: insert the VI into the SubPanel and THEN run it.

Counter-intuitive, it seems.

I gorched the issue numbers and I messed up the demo VI. Try it again in the attached example.

Issue #2 is the POOF issue.

Here's a JING to show the problem. (it wasn't a typedef in the first example).  

I open the typedef, move the string indicator a pixel or two, and then APPLY CHANGES.  As soon as the APPLY happens, the INVOKE NODE disappears.

Issue #3:  I would like the help to clearly explain that the subpanel is NOT really a control, but it's in the Controls array because ______, or that it really IS a control. but you cannot REORDER it in the cluster because ______.

[Kevin_H.]

Thank you for the screencast! It was very helpful. I believe this is done by design to prevent you from forgetting to modify whatever references you have to the VI. I think it's a rather silly design decision personally, but I don't think it's a bug. I'd be happy to file a CAR on this as well though as I don't believe it should be the expected behavior.

As for issue 3, it is treated like an indicator (for all intensive purposes it IS an indicator). Consult http://zone.ni.com/reference/en-XX/help/371361G-01/lvconcepts/grouping_data_with/ for reordering within a cluster. As far as using that property node, I believe it's in the order it appears in the Bundle/Unbundle cluster functions. Clusters and arrays are both ordered (which is why you can switch between them fairly easily with the right VIs).

[CoastalMaineBird]

I believe this is done by design to prevent you from forgetting to modify whatever references you have to the VI.

Why should I modify a reference to the VI, when I'm changing a cluster with a subpanel?  There's no connection between the two until I make one at run time.

My bet is that the APPLY CHANGES deletes the cluster on the panel and replaces it with the new version, thereby forgetting the reference to the subpanel.  That makes it hard to work with.

it is treated like an indicator (for all intensive purposes it IS an indicator)

Uhhh, that would be "for all intents and purposes".

But that is plainly not true.

From the document you cite:

The first object you place in the cluster is element 0, the second is element 1, and so on.

I always thought that was true, but that also is plainly not true.

Try it yourself:  Make a cluster, place a SubPanel in it, then place a string indicator, then a numeric indicator.

Then try to reorder the items in the cluster. The string is #0, the numeric is #1, and the subpanel? it doesn't get a number.

But if you use the CONTROLS[ ] array (property node of the cluster) and access item #2, you can cast that to a SubPanel reference and play with it.  Nowhere have I seen that behavior described.

[Kevin_H.]

That's interesting... I'm not sure why it doesn't show up in an unbundle. I found this reference on sub-panels (http://digital.ni.com/public.nsf/allkb/D587067E18E0E70186256D44007B91FE). It seems they're sometimes treated as controls, sometimes not. They aren't controls or indicators really, they're containers. Your ordering question is interesting because, like you said, it doesn't appear to be documented anywhere. I'm not sure there's a guaranteed behavior in this case (which is a little strange). The only way to know for sure that you're working with the correct sub panel (from what I can tell) is to look at it's properties. You point out some very interesting problems with the sub panel. I'll consult some collegues and see if we can think of any reason why it works the way it does.

[CoastalMaineBird]

It seems they're sometimes treated as controls, sometimes not. 

Which is what I said in post #1.  It's completely ambiguous, and not documented.

[CoastalMaineBird]

For what it's worth, making the typedef a NON-STRICT typedef means that the INVOKE NODE doesn't disappear when you APPLY CHANGES.