Scripting - replace invoke node

[DFGray]

The No Error case is 0, the Error case is 1.  Are you trying to move the Cluster or its terminal?  To move into a case structure you need to move either a terminal of a front panel object (get the terminal reference from the front panel cluster property) or a cluster constant.  I can't count the number of times I have made this error.

In general, you can figure out what index which frame in a case structure is by simply showing the cases in the GUI.  They will be listed in the correct order.  However, if you reorder the cases, this is no longer true and you are back to trial and order.

[m3rl3n]

Of course I could totally forego the error case structure...  All I am doing is wrapping .NET methods for use in LabVIEW.

[Darin.K]

Before I wire this up myself to test, are you certain you are using the reference to the Terminal of the control/Indicator.  The Invoke Node should say CtrlTerm or something like that.

I am loathe do disagree with the scripting master DFGray, but my near-certain recollection is that you can in fact specify the Case Structure itself as the new owner and it will be placed in the visible case.  Maybe not what you want, but certainly not a cause for error.

[m3rl3n]

YEUPPERS!!!!  There it is...  the head slapper.

My reference is to the cluster, not to the terminal.

UGH!!

The hardest part to this scripting stuff that I have found so far is just keeping track of what you're referencing and  if what you need is a property (property node) or a method (invoke node)

Thanks for the promptness of pointing out the error(s) of my way. 

Dan

[DFGray]

Darin, you are probably right.  I am not sure I have ever tried to move to a case structure without specifying a frame, since it is a somewhat indeterminate operation for a general purpose scripting engine, which is where I did most of my scripting coding.  And as m3rl3n just posted, that wasn't the problem.

[m3rl3n]

I'll let you know about the visable case structure vs the specific case in a little while.

Let me make sure that I can figure out how to get the ref to the terminal first.....

Dan

[m3rl3n]

Yes, if you have the reference to the case structure, the item that you are trying to move into it will go into the visable case. Although, for safe programming, you may want to have that additional layer of protection in case someone makes an edit in the future and then they find no reason for the item to end up in the wrong case every time they run the script.

What you may infer from that discussion is that I am no able to place my cluster TERMINAL into the case structure.

Thanks for the help, again.

Dan

[m3rl3n]

Well, I was looking for a place to start a new thread because although this one has grown, I thought for this new question it would be appropriate.

The questions...

When working with clusters (and of course bundle and unbundle):

How do you find out the names of the terminal / object that is in the cluster and is it the same if you are working with a front panel control, BD terminal or constant?

How do you expand the bundle / unbundles to list all of the terminal connections?

I think answers to those will get me jump started again.

Thanks,

Dan

[tst]

I don't remember off-hand, but LV might have some examples, and this code should also demonstrate it. Generally, these things aren't too complicated - if you want to manipulate a bundle node, you can expect the methods/properties for that to be in the class for the bundler. It's useful to be aware that property and invoke nodes separate parts of their lists with lines - each line represents a class (i.e. the top group is the methods from the Generic class, the next is the GObject class and so on), so you can expect the class-specific methods to be at the bottom of the list.

As said before, it's also important to keep track what you're dealing with (a constant, a terminal, etc.) - if it helps, keep a diagram in front of you so that you can compare the scripting code to what you expect to do. The scripting code should usually correspond directly to the LV code.

Also, I would suggest avoiding clusters - the 4-2-2-4 pattern should allow you 6 inputs easily, if you assume that the .NET methods only have one return param (technically, they can have more, but I believe that's only if they're configured as pass-through, and I think that means the value can't be changed, meaning you don't need to output it, although you would want to check that). If you do need to use clusters, you might wish to create a builder VI for each cluster - the VI will have all the inputs and will outout the cluster. This might make it easier for the end user.

[Darin.K]

How do you find out the names of the terminal / object that is in the cluster and is it the same if you are working with a front panel control, BD terminal or constant?

If you wire it to a named (un)bundler there is an AvailableElements[] property.  This will not list elements in nested clusters (perhaps that is ok for you).  Likewise, you can just use the Cluster's Controls[] property to get all of the Labels (which are the names).  If there are nested clusters and you are up for the challenge, I show a couple of ways of dealing with nested controls here:

http://forums.ni.com/t5/LabVIEW/Search-through-a-cluster-or-clusters-in-cluster-by-label-name-of/m-p...

How do you expand the bundle / unbundles to list all of the terminal connections?

A shortcut I often use is to connect a normal (un)bundler and then replace it with a named (un)bundler.  Works especially well when there are no nested clusters.