Handeling Control references inside a cluster, change properities of a specific control inder a cluster.

[N_743]

Hi,

Control and Indicators are mentioned as (CI) in this post.

I am working on some UIs and they generally have a minimum of 30 CI, some, I put in tabs (easy to show and hide, just switch to an empty tab), some in cluster and some placed directly on front panel.

I am trying to find  a better and scalable solution to handle front panel CI. For this post, I am focusing upon the idea of putting everything inside a cluster and use "Control[]" reference array to further handle each reference as per requirement. Generally, following changes are required in their property:

1) Enter a specific value to CI

2) Reset control to default value

3) Enable & Disable Specific control/indicator

4) Check if all the controls are populated by user, some value other than the default

5) Change color of specific control, if required

Above mentioned tasks are triggered per case/state requirement of the program. So each state would require some changes in properties of a CI.

In the attached VI snippet, Below is what I came up with for the bullet 1,3,4, named as Case1,2,3. I believe same logic can be applied for other bullets.

I was wondering if any one has any suggestions to better handle FP CI.

PS: I store control reference in an FGV at the start of the program for a cleaner diagram and use a subVI that has different hard coded cases triggered by a enum when required.

EDIT: Changed "Under" to " Inside". Update made to subject and body as corrected by @altenbach.  

[altenbach]

I assume you mean "inside a cluster", not "under a cluster".

[N_743]

Hi altenbach,

Yes, I meant inside. 😬

[altenbach]

I am still trying to figure out what problem you are trying to solve. WIll this be in a generic subVI that can deal with all kinds of clusters?

In the meantime, here's a much simpler version for your string array processing (I know, you did not ask for that;) )

[N_743]

Thanks you for your response!

---

@altenbach wrote:

I am still trying to figure out what problem you are trying to solve. WIll this be in a generic subVI that can deal with all kinds of clusters?

---

EDIT:

Yes, that is the idea to make it re-usable, as much as possible. Like a plug and play VI with minimum manual changes required. (Not considering changes in cases, those will be needed)

I am looking for exactly what you did with creating string, you did it less steps. I usually find myself creating a RUBE GOLDBERG code and then correct it later on.  I forgot to mention string conversion but thanks for showing me how it can be better done. I will study how it is working.

Similarly, since I am not sure, I basically posted my approach on forum for critique and/or suggestions.

EDIT: This is what I was doing in a previous version:

[N_743]

Hi altenbach,

I created a VI that currently meets my expectations (almost):

1) Handel multiple control/indicator properties with least complexity, steps and complication.

2) VI that can be used as plug and play (currently it is more like a template that would need modification in cases, ideal would be to have something like a polymorphic VI).

3) Should be easy to read and follow by a new programmer.

Would you have any improvement suggestions or comments?

P.S. I came across really cool way to create enums in the VI edit mode, never knew you could do that, opens many possibilities. This simplified creating cases based on labels names and eliminates possibility of topological errors with string based cases.

[altenbach]

Thanks. Your snippet is broken because all type definitions are missing. It would be preferable if you could zip up the VI and dependencies (VI, typedefs, etc.) and attach it here once more.

[N_743]

My bad, hopefully this is all that is needed. Please find the attached zip file and sorry about bad naming, rushing through a lot right now.

Thanks

[altenbach · Accepted solution]

---

@N_743 wrote:

My bad, hopefully this is all that is needed. Please find the attached zip file and sorry about bad naming, rushing through a lot right now.

---

Sorry for the delayed response. Just saw this during weekend breakfast. 😉

A few comments:

You have way too much duplicate code, most identical, some differing maybe by a few strings or booleans. This is very hard to maintain! Feels inside-out!

You don't really need that big case structure. Just create an array constant with one entry for each state as a cluster of all needed values (you can easily e.g. add the text color back, but since everything currently is (and remains!) black there is no need). Index into it with the state and process the cluster values accordingly.

The following code does exactly the same as yours (unless I mis-clicked something), but with only one FOR loop (and inner code) instead of eight!

(Note that I am not saying that this approach is great overall. I just made a literal rewrite of your code to give you some ideas. With 8x less code, maybe you won't need to rush through as much 😄 )

[altenbach · Accepted solution]

If only a smaller fraction of states require an action, it is sufficient to create a solution that only contains those in the array constant. (with the default action as last element).