Array: Index Values Property Read-Only

[almac]

I have Labview 8.5. I have some controls on the front panel.  Two of them are controls that are from different strict-type defs that are arrays of clusters.  The controls only display one row of each array.  I can create a property node for one of them for Index Values that is writeable or readable.  The other control only allow me to make an Index Values property node that is readable, the Change to Write option is disabled.  

I can find no explanation as to why....

[df86]

Could you post the Control

[ben64]

---

@almac wrote:

I have Labview 8.5. I have some controls on the front panel.  Two of them are controls that are from different strict-type defs that are arrays of clusters.  The controls only display one row of each array.  I can create a property node for one of them for Index Values that is writeable or readable.  The other control only allow me to make an Index Values property node that is readable, the Change to Write option is disabled.  

I can find no explanation as to why....

---

The index value property is read only for strict type def. My guess is that the first control you created the property node before changing it to a strict type def. Then you copied it to create the second control and then were unable to select the index value property. I also guess that you vi has a broken arrow! Changing the controls to type def should solve your problem.

Ben64

[almac]

Thank you for your response.

I am quite sure that both control were defined as strict typ defs many months ago and are not derived from one another.  I have no broken arrow.  

But your questions and the request for posting a sample, got me to examine my project structure a little more carefully.  The strict type def control that has the read-only propety node is defined as a public member of a class and then used by the class.  The strict type def control that has the read/write property node is defined outside of a class then used by the class.  If this is the reason for the difference I find this kind peculiar and wonder at why the difference...

Any thoughts,  is this the answer?

[X.]

This thread appears to be dead. Let's try to revive it.

I am too old for classes, so let's just follow these simple steps:

- drop an array on the FP. For instance, take the nice Silver Numeric Array with no Index Control but a Scrollbar instead:

- Make this control a Typed Def and open the Type Def.

- Make it a Strict Type Def (this step is critical)

- Go back to the FP (or Diagram) and create a "IndexVals" Property Node.

As mentioned by almac, the "Change to Write" option is grayed out (no need for classes for that).

There is absolutely no reason why that should be so,

Worse, if you disconnect the control from its Type Def, then change the PN to "Write" and replace the control again by its Typed Def, the PN is still available in "Write" mode, but now the "Change to Read" is grayed out (!) BUT the "Change All to Read" is available (!!!).

Quid erat demonstrandum.

This is a bug in my book.

Tested in LV 2013 SP1 64 bits.

[Cooking_Up_Code]

Hi X,

I don’t think this classifies as a bug. It’s because it is a strict type def that you see this behavior. If you follow the same steps you listed except all done with a regular type def, you will be able to freely change from read to write. It stems from how strict type defs are built to function. Taken straight from a National Instruments Knowledge Base article: “The only flexibility to a Strict Type Definition is the name, description, and default value, which can be different for each instance of the control. The only properties available for a Strict Type Definition control are those that affect the appearance of the control such as Visible, Disabled, Key Focus, Blinking, Position, and Bounds.” You can read more in depth about the difference between using the two type defs in the link below. Hopefully this helps you out.

http://digital.ni.com/public.nsf/allkb/1B04FD6A11E6F17286256C6300588BFA

[Hooovahh]

Okay maybe I can agree that under the definition of a Strict Type you shouldn't be able to programatically change these things.  But why am I then allowed to change the Index Values of that control when it is running?  By that I mean we are allowed to scroll up and down, which changes the index value, which is not a "name, description, and default value" which we are allowed to change and be unique between instances.

And if you are going to argue that changing the index value by using the scrollbar does fall into one of the categories of "name, description, and default value" then we should be allowed to change it programatically.

Secondly there is a bug with the usage for sure.  If I am not allowed to change a property node to a Read, but I am allowed to change all of them to a Read, then that is a usability bug, and they need to be consistent.

To be consistent with the UI I suggest allowing strict types to be able to read and write the Index Values property.

[X.]

Like Hoovahh said.

[Cooking_Up_Code]

It's looks like you guys are right, that is a bug. We've gone ahead and filed a CAR (#512512) for the issue. R&D will investigate this further. You can monitor the status of this issue through the following links.

http://www.ni.com/product-documentation/52150/en/

http://www.ni.com/product-documentation/52151/en/

Thanks for finding it.

[NateBraska]

FYI, this is filed under CAR 521512.

Best Regards,

Nathan Burke

Product Support Engineer | LabVIEW R&D | National Instruments | Certified LabVIEW Architect