Having trouble reordering elements in class data cluster

[Quantum_Code_Monkey]

I have a LabVIEW class whose private data cluster includes a cluster of smaller clusters.  (It's not as bad as it sounds).  I have reordered the elements of one of the smaller clusters in the class control.  When I recheck the order (by selecting "Reorder controls in cluster...") I can verify that the order has indeed changed.  However, when I unbundle the data cluster from a member VI, the order hasn't been changed.  I have resaved the control, the class, and the project, restarted LabVIEW, and created a new member VI after updating the cluster order, and the unbundle nodes are still in the wrong order.  Is there somewhere else that I need to be changing the cluster order besides just in the control?

Any help/suggestions would be much appreciated!

[xntricity]

Hi Quantum,

I'm not too sure exactly why your cluster order hasn't updated as it should, but there are a couple of easy workarounds you could do to solve this. Firstly, you could always use the 'unbundle by name' function in your member VI's to guarantee you retrieve the correct data. Second, change your cluster of clusters into an array of clusters in the object class and use the 'index array' function in the member VI's. Thirdly, and my favourite way of keeping consistent data types is to create a control in your project with a strictly typed definition and then use that control in your class definition and all the member VI's. In doing this, if you need to change the data type or order of clusters in any way, you can simply edit the control itself and all instances of that control should get automatically updated.

Regards,

Andy

[Quantum_Code_Monkey]

Thanks, xntricity, for your reply.  I will try using strictly typed custom controls - that looks like it will be generally very helpful anyway.

I am still confused as to why the cluster order isn't updating in the class, but your advice should work.

[Ben]

---

xntricity wrote:

Hi Quantum,

I'm not too sure exactly why your cluster order hasn't updated as it should, but there are a couple of easy workarounds you could do to solve this. Firstly, you could always use the 'unbundle by name' function in your member VI's to guarantee you retrieve the correct data. Second, change your cluster of clusters into an array of clusters in the object class and use the 'index array' function in the member VI's. Thirdly, and my favourite way of keeping consistent data types is to create a control in your project with a strictly typed definition and then use that control in your class definition and all the member VI's. In doing this, if you need to change the data type or order of clusters in any way, you can simply edit the control itself and all instances of that control should get automatically updated.

Regards,

Andy

---

I prefer the "by Name" versions myself since it clearly documents what value is bieing touched. 

I would think that the "strictly" part is not required.

Make sure you put the type-def in the same folder as the private data. There were issues in early version of LVOOP if the type-def was not nearby.

Ben

[Quantum_Code_Monkey]

The Problem Continues.....

I tried the strict type def thing, by making some of my clusters into custom controls set as strict type definitions.  I've updated all my VIs and the class control to use the strict type definition.  When I open the class control and look at the contents through context help, I can see that the control does indeed contain my new strict type definitions.  However, when I drop an instance of the class in my member VI (either as a constant on the block diagram or as a control on the front panel) it does not contain the new strict type definitions, but the old clusters (with the wrong order).  It seems clear that for whatever reason, the .lvclass file is not updating to reflect changes made to the private data control.  Again, I have saved all the VIs, and the class directly, and it just doesn't seem to update with the new data types...

If anyone has any ideas on what is going wrong, I'd appreciate any suggestions.

[Quantum_Code_Monkey]

Thanks Ben, for the reply. 

I do use unbundle by Name for the larger clusters, but for my setter method for the class, this would require unbundling each of the large clusters by name as well, and since there are 91 small clusters (at current count - this will probably increase later), having to wire all those individually by name in the setter vi is a pain.  Especially since the class should automatically update so that I should be able to just wire the individual large clusters (only about ten of those, much more managable) and have all the individual elements of those update correctly.

I did put the type-defs in the same folder, and also added them to the class, and the class data still doesn't update....

[Ben]

I do not have the time to play a game of 1000 questions to narrow this issue down, so let me suggest you zip-up enough files to let us "play along". Give us a step by step on what you are trying and someone will try to duplicate the process.

Please let us know which version of LV you are using so we use the same version you have.

Tryin to help (with out making you work to hard),

Ben

[Quantum_Code_Monkey]

Thanks again, Ben.

Hopefully, this is enough.  Let me know if I need to attach anything else.

Basically, what the code does here is collect a whole bunch of data as entered by the user in another main VI, then uses the data there to create a new Notes Generator class.  The missing member VI (not included for simplicity) then does a lot of calculations on that data and spits it all out as a string, optionally saving it to a file, in one of two different formats depending on user input.  What you should be able to see in the New Notes Generator member VI is that the input clusters use the strict type defs (for the first three subclusters) just like the control for the .lvclass file, but that the class constant on the block diagram does not contain any strict type defs (just regular classes).

[Quantum_Code_Monkey]

Here's a more usable version (with the missing routines removed entirely to avoid errors).

[Quantum_Code_Monkey]

Oh, and I forgot to mention - I'm using LabVIEW 8.5