From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Cluster of objects at edit time

Real quickly on my way out of town (which is never a good way to write when there are existing clarity issues):

 

Classes are tremendously great for our project. Everywhere from inheritance heirarchy through automatic casting through hiding of implementation details, it's a fantastic fit. The only issue is this initialization, and it's more an annoyance than a showstopper.

 

We're trying to take advantage of LabVIEW's clusters with their named unbundling to keep everything well-labeled and flowing throughout the application. To take the car example, we have a single cluster flowing throughout the application with "boss's car" "delivery truck" and "janitor's car". With a single cluster there's no chance for race conditions where two different parts of the program will attempt to dispatch the "delivery truck" simultaneously, and with the clusters bundeled/unbundled by name there's no chance of confusing the "boss's car" with the janitor's.

 

Like I said, this is all working great, and I wouldn't dream of comparing it to any other language. The visual nature of the named clusters is the real feature here.

 

Back to objects: I can imagine a few ways that it COULD work that are not implemented. For example, right now a class constant on the BD is effectively a cluster shown as an icon. It seems consistent with LabVIEW programming to enable the option of toggling that the other way. But maybe there's some internal reason that can't be done.

 

In any case, right, it sounds like there's no tricks that can cleanly combine the list of values with the list of types/classes. I plan to just make a list of values and classes in a single structure and carry the values around redundantly for the rest of the program. It's rough, but the best solution I can think of.

0 Kudos
Message 11 of 14
(880 Views)

There is a work-around to get what you want.

 

Write some code which initialises the objects to the values you require (you can't get around this step).  Then write to a cluster indicator.

 

After running the code, the cluster indicator (cluster of objects) will contain the data you require.  Now right-click the indicator and choose "Create Constant" and you now have your pre-initialised constant.

0 Kudos
Message 12 of 14
(873 Views)

BTW, the code to initialise your objects (before writing to an indicator) could theoretically be reading data from an object you have previously written to XML and going all Factory Pattern on it.  This way, the XML file allows you to edit the values of the thusly created constants outside of LabVIEW.

0 Kudos
Message 13 of 14
(860 Views)

@Intaris wrote:

There is a work-around to get what you want.

 

Write some code which initialises the objects to the values you require (you can't get around this step).  Then write to a cluster indicator.

 

After running the code, the cluster indicator (cluster of objects) will contain the data you require.  Now right-click the indicator and choose "Create Constant" and you now have your pre-initialised constant.


Thanks Intaris!

 

I followed those steps and got the class constant with a black border (the space around the icon on the face of the cube is black) as described in in the link below. 

 

I'll have to ponder ways to use this trick. For example, I wonder if it can somehow be combined with scripting.... but at least it's a good puzzle piece!

 

http://labviewwiki.org/LVOOP_Frequently_Asked_Questions#My_LVOOP_class_control_has_a_black_border.2C...

0 Kudos
Message 14 of 14
(825 Views)