Is it possible to build a cluster dynamically at run time

[Chris_Ng]

Hi Gregory,

We could build clusters by indexes or by element names. It would be nice if we could have a native API that allow dynamically generating clusters. At the moment, it seems the best solution is what @aartjan has suggested: cluster toolkit by Autotestware. This solution leveraged variant data type conversion. At the end, I still have to manually prototype and build my cluster control.

[TiTou]

I would suggest a variant

I've used variant with the open g toolkit to stuff a cluster in the variant and add/remove/rename element

And if you need a display, the variant probe to be foun on the lava repo is a great tool

[JÞB]

---

@Chris_Ng wrote:

Hi santo_13,

I create a program which depends on user input, will produce different collection of data (sizes and types). At the moment, I use map to hold the variable names and values (in string format). I think of a solution where I could loop through my map collection to parse the data and somehow insert them into a cluster. With this method, I could dynamically generate cluster for my code but I guess that is not the right way. Therefore, I manually parse each item in my map collection into a defined cluster. I wonder if there is a better way to minimize the "manual" process in getting the output.

---

This is probably the wrong question to be asking.  There is simply no way to program a computer to do whatever the user wishes it do do by simply entering disorganized information.  Basically this is a, Garbage In - Garbage Out (GIGO) problem.

You need to "Get the User Story."  Speaking with them about how they want to help themselves achieve their goals with your software is the first step.  From that discussion you can define the software requirements.  Those requirements will help define the Datatypes of the information that the User will need to supply as program inputs.   After you have done all of these steps, your code will be able to manipulate the information and give the User a meaningful result.

You just cannot skip the first discussion with the User and expect them to be happy with the program!

Remember that you are a software developer, not a priest! You are writing code, not praying for them to get whatever they want right then.

[wiebe@CARYA]

---

@Chris_Ng wrote:

 At the end, I still have to manually prototype and build my cluster control.

---

You can build (script) a cluster in the development environment. This usually won't do you any good, because all access to it's elements would be through variants, references, or scripted code (or malleable VIs).

If you just need a container, there's not much wrong with a map. Except speed. Map uses a binary tree for searching a key (probably log(O)), but an array using an index will be (much) faster ((1)). You can store variants in an array and also keep a map of keys (names) vs index. You'd have (1) speed if you have an index, and log(O) if you have a name.

If you want to store variants, you might actually benefit from using the old variant attributes in stead of maps. Variant attributes have a default input that converts the output to the desired data types. Maps always return variants and it takes an extra conversion to get your data type.  For speed it won't matter much, but it's less code. This only works if you store variants and if the key is a string.. 

If the names are known at development time, but flexible (e.g. you have several applications using the same value data buffer) you can use an array and an enum as index. Strings convert to the enum nicely. You get to lookup names by string and very fast by index while having a name in the (type def) enum.

[TiTou]

here's a simplified example of what I did :

Let me know if you want to dig in this direction.
And here's the link to the latest variant probe package : https://lavag.org/topic/13748-cr-variant-probe/?do=findComment&comment=128031

while looking for the latest version, I saw this package that might also help : https://www.vipm.io/package/hooovahh_variant_repository/

[XM43]

---

@Chris_Ng wrote:

The error cluster is the collection of different data types.

---

Great! But what would it look like in your case.

Regardless, I have customers asking for UI additions quite frequently and it contains all sorts of data types, enums, booleans, string, ring, arrays, clusters and god knows what.

My approach is handling variations in string format for the code and convert data as needed. For UI, I keep either moving the controls and indicators as needed and naming them as needed. Sometimes hide them. Basically re-organizing the UI as per specific requirement.

You may want to consider looking at your problem from a different angle. If not, you can probably get as far as what wiebe@CARYA said. Otherwise its like what JPB said.

[Chris_Ng]

Hi all,

Thank you all for valuable suggestions. I can't wait to try them all out. This has helped me to rethink about LabVIEW. 

Best,

[Eric1977]

Have you looked into JSON? Can't you have different data types in a JSON file or kept in memory?

Perhaps I skipped over something or don't know what the requirements are and maybe JSON isn't the right fit but, based on what I've read, this would work. Couldn't the OP have a node for the data type?

An example would be:

{"datatype":"double", "value":30.03}