Iterating in an event structure over subset of control items

[RavensFan]

How are you actually using this VI?  Is it behaving like a pop-up dialog?

First, you can't have two event structures in the same loop.  The loop won't iterate until an event has fired in each event structure.  You'll probably have the loop stuck waiting for the send button to happen. 
Worse, because you have events in both structures to lock the front panel until the event completes, you are going to lock up your VI when you go and click more than one checkbox and haven't hit the Send button.  And you won't be able to click the send button because the front panel is locked.

The send button should be a separate event case in the same structure.

But it still depends on how you are using the VI.  What else is it interacting with?  I don't even think you need an event structure for the checkboxes because you are essentially processing all of them any time you click on any of them.  The only reason to have an event structure is to just wait on the Send button assuming that sends the data onto another VI and exits the loop on this VI.

Read Caveats and Recommendations when Using Events in LabVIEW

[EngrStudent]

And now it is working.

Disclaimer - I use single frames to group and allow what I think of as "non-text annotation".  

Final form:

Thank you for the links on events.  I am much happier with this. 

[Gregory]

You can use "Flat Frames" to decorate your block diagram.

[EngrStudent]

Gregoryj - I must be doing this wrong.

When I start with this:

 

And I clean up the block diagram, I get this:

If I do this, however:

And I clean it up, then I get this:

This means that I can take vast and hairy VI's, some of them so big that the cleanup actually causes them to break, and I can put down a truck-load of single-frame flat sequences (highly constrained, typically SISO) and I can both retain the important human readability and executability after cleanup.  If I can do that with the cleaner "flat frame" then I would like to.  I just don't know how to make the flat frame retain wires.

[RavensFan]

While I don't agree with using the sequence structures to fence off unused controls, I can understand it.

But the error constants there are completely unnecessary. They are just creating a dataflow dependency between structures that don't do anything with the structure that starts the program by gathering up all the control references into arrays.

EDIT:  Decorations are strictly decorations.  When you do the block diagram cleanup, you will get what you are seeing.  There isn't anything you can do to prevent it.

---

@EngrStudent wrote:

 I just don't know how to make the flat frame retain wires.

---

I don't know what you mean by that.

[Gregory]

I see, I don't think you're doing anything wrong, that's probably just how it behaves. Personally, I do not use cleanup on larger block diagrams (unless it is someone else's code with an incredibly high wire density!). 

Perhaps I am missing something, but if you just want to copy values from one cluster to another, maybe you can try something like this:

[EngrStudent]

@RavensFan

Clarifications:

• I use single frames of flat sequences all the times.  When I say "retain wires" I mean the wire relationships on the borders.  
• The error constants, like the single-frames of sequences, enforce structure with minimal hit to runtime.  I don't like them either because they are klugy.  I bet the compiler looks at them, and throws them away.
• Fence off is not what I am doing.  Corraling similar objects into a single bucket is what I am doing.  

>> When you do the block diagram cleanup, you will get what you are seeing.  There isn't anything you can do to prevent it.

If I start with this:

And I use the single frames like this:

then upon cleanup I will get this:

Instead of this:

I cleaned and "excluded" the boxes individually, so the row and column information is retained.  You can see that when building the array I have transposed column three, rows 4 and 5.  I have also rotated column 5 rows 3,4,and 5.   These leap off the page because it is they are the only crosing wires going into the array.  If I had put the wrong operation for column 2 row 3, I could go and replace it or edit it without issue.

Personally I find it easier.  It is like annotating the  code, so in 6 months or more, when I have to edit it, I can quickly figure out what I did, and make the changes that I need to make.  

[EngrStudent]

@gregoryj 

I am selectively resetting the values, and I need to allow the user to "dither" or "wrangle" until they are happy.  😉

[RavensFan]

Anytime your code gets that complicated that you need sequence frames to maintain wires in order, your code is getting too complicated.  To me, your top code in the last pair isn't any better than the bottom code without frames.

When the number of entities go and you are doing like operations on different things, it is time to start using subVI's.

[altenbach]

---

@EngrStudent wrote:

then upon cleanup I will get this: ....

Instead of this: ...

---

This code (And all other code you posted earlier, but that's a different discussion) just smells bad! There are so many symmetries that I am sure it could be done with a stack of FOR loops and a single instance of each bitwise operation. I can't really tell what's going on from a picture, so an actual VI would help.

Also a real blemish is the abundance of coercion dots. Doing bitwise operations on orange data makes no sense, so why are the controls not integers?

Can you attach this code as a VI?