Passing Ring from SubVI and into cluster constant

[Mitch_Peplow]

Hi all,

I'm 99% sure I'm correct on this but please could somebody confirm two things:

1. Its still not possible to directly pass out a ring via an indicator from a SubVI without loosing all the information. It has to be done via a control on the calling via and using a reference to update it

2. Once I have the control with the modified strings and values, its not possible to simply bundle the ring into a cluster constant (see picture below for both questions in pictorial form)

Cheers and thanks in advance

Mitch

[tst]

Both correct, although it's not a matter of "still". This is by design - what you're passing is only the numeric value. All the other stuff is something which belongs with the ring control itself, not with the value.

If you want to have access to that data in your cluster, you could also bundle the ring reference into the cluster, but I would suggest not relying on FP controls to store your data - if that data is needed, you can add it to the cluster.

[Mitch_Peplow]

Hi tst,

Could you post a quick screen shot of exactly what you mean regarding getting the data into the cluster as I want to clarify I'm understanding you correctly. You said I could add the reference to the cluster but would recommend against this and your very last comment implied adding something else to the cluster other than the reference and doing it a different way?

Whilst we are on the subject of references and alike, could you also confirm there is no way to update cluster labels at run-time. I don't want to modify the caption, I want to do the label itself so the unbundle by name function works correctly works.

Cheers

Mitch

[tst]

No screenshot, but it depends on the data you want - if you want the list of strings and values, then you can add a 1D array of clusters and to your cluster and take the same data that you use to populate the ring.

There is no way to change labels at run-time, but even if there was, I'm not sure how you think it would help you - you still have to statically decide which element to unbundle. If you want to unbundle different elements dynamically, I would suggest a case structure with multiple cases. If you want something truly dynamic, then maybe a cluster is the wrong tool.

[Mitch_Peplow]

Well that's it you see I want to try and make my code more dynamic rather than being so static but I do take your point that for many situations you will still statically have to choose.

By being able to update the ring at run time does give you the ability to dynamically update selections to some degree but for what I want and need its probably impossible to achieve. Maybe I'm asking too much but it feels more like I just don't have the answers (or maybe I'm asking wrong questions! )

I tried reading everything as an array then manipulating the array into clusters and all manner of things which is why the ring was required in order to provide an easy way of indexing the correct piece of configuration data but again as you mentioned most of the config data is statically selected anyway with no need for an interactive selection. The purpose of the intention still stands though.

I've had some success typecasting and using the flatten to string functions but again these need to know the final data structure to work which makes it less dynamic and essentially static again.

I'm still confused on the ring population idea if I'm honest especially now you talk about a 1D array of String and Values which is exactly what I'm passing out of the VI in the picture; the Key Indexes is purely used to index the correct array element cluster.

What would you use/do if you wanted something truly dynamic tst as it would be my preferred method going forward.

Hopefully that makes sense and I'm not missing something glaringly obvious

[tst]

No concrete advice since I don't know what you're trying to do. Your comment about the wrong questions is probably right. I think you might want to take a step back and rephrase the problem in your head, so that you know exactly what you want.

My understanding is that the specific thing you're asking about is using config params loaded from a file. If the param is supposed to be used in a specific place in the code, then you're going to need a static data type at that point anyway. If you just want the user to select between a bunch of params, presumably they will still all have to have the same type.

If your issue is with saving and loading params, you can try using something like the OpenG variant config VIs, which allow you to save and load clusters (or MGI R/W anything, or Flatten to JSON (although I'm not sure how the JSON function handles missing data), etc.).

If you want something more dynamic, I think this fits the bill, although I never looked at the details - http://www.ni.com/example/31249/en/

[Mitch_Peplow]

Morning tst,

It's not the config files specifically that I have any issues with, that was just the point I ran into the ring issue and hence the question but the reason for doing it was to make everything less static and easily scalable. However as you said certain points will by their very nature have to be static and for good reason; the wheel is round and not square after all!

I think my question may be more to do with how to make code more easily scalable (with some dynamic capabilities) which is something NI push, its just very easy to forget and corner yourself in my opinion, but maybe that's just because I don't have a defined way to stop myself doing this.

I believe some of the way I code is almost OOP based in the way it handles data but on the other hand other parts of my code are, for my liking, too static in how data is handled. LVOOP is something that I really want to get to grips with to understand it potential benefit as many developers readily preach about its power, however having never really used it in anger apart from the training course (must be over two years ago now) I've never had a chance to really test it. What about you, ever used LVOOP?

That link you sent looks very interesting so I have a sit down when I get an hour spare and go through it to see I've it reveals any golden nuggets.   

[tst]

I used LVOOP on many projects, but that doesn't mean that you should. Remember that OOP is not a magic bullet. There are things it's better for and things it's not so good at. Some people find it easy to think in OO terms and other don't. Some people write good OO code and others write bad OO code. It's important to understand that using LVOOP will not necessarily let you make your code more dynamic. It can be useful when you have things which exhibit the same behavior, but achieve their results in different ways and in other places, but it won't necessarily be useful in places where you want things to be very dynamic as OOP does tend to require that you have fixed APIs (at least if you're using inheritance to determine behavior).

Ultimately, it's important that you understand the code and be comfortable with it. If you think your code is already OO-like and you want to convert more of the code to that, then that certainly seems like a reasonable move, but you should probably get comfortable with LVOOP before doing refactoring on a large scale.