Basic question about local variable and reference label/icon creation order

[princelog]

When I dragged over several indicator/controls and try to create local variables or references, the order of the created icon does not align with the order the original labels are placed.

I am well aware that I can press SHIFT key and click to pick, in this way the created label will be in the order of my clicking, but if I just drag over say 100 controls, what is the logic behind the order of created local variable and reference label/icons?

This might provide some good clue for naming the variables, not as trivial as someone might think, so please only reply if you have an answer, thanks.

[raphschru]

Hi,

When you select multiple objects by drawing a rectangle around them, their order in the selection is arbitrary, which is mostly the order (direct or reversed) in which they were originally created. On the contrary, when selecting one by one by maintaining the shift key, the order in which you selected is retained.

So there is no naming logic that can change that. If you really need this for hundreds of controls (which you shouldn't if your code is reasonably structured), you could also develop your own right-click plugin that could take into account the 2D position of the objects to deduce their order before creating the locals/references.

Regards,

Raphaël.

[princelog]

Dear Raphaël,

Thank you for your feedback. And before I take yours as solution and appreciate your help with a KUDO, there is one more thing I'd like to learn as people keeps telling me what I am doing is wrong.

I have a large screen (or a projector), I have 100 channels to run some process, and each channel 100 steps. 100 channels can either run in parallel or sequential order, each single channel will need to run in a sequential order of the 100 steps, and I need to light up the corresponding LED indicator to show which step of which channel (sequential) or which steps of which channels (parallel) is running right now, the rest of the indicators must be dark when that corresponding process is not running.

To avoid 100*100 = 10000 wiring, I used some techniques such as local variables and reference, to reduce the wiring from 10000 to 200, I'd like to learn how to make this code design better to further reduce the wiring, as you said, "which you shouldn't if your code is reasonably structured", so I'd like to learn a better way to do this.

Due to credentials, I cannot share the exact code.

[altenbach]

Maybe a 100x100 2D array of LEDs (and reasonable code architecture!) would be sufficient. One single terminal!

The entire thing could be encapsulated in an action engine where the 2D array is kept in an uninitialized shift register or feedback node.

[princelog]

Could you please show an example? What would be a reasonable code architecture for this kind of application?

If you could, please estimate the wiring you need to do, as a comparison, thanks.

Also, some channels will be deactivated halfway, and we want the indicator LED light up and stops there, and some of the process will be jumped over if not necessary. What would be a better structure without local variables and references?

"Maybe a 100x100 2D array of LEDs (and reasonable code architecture!) would be sufficient." How do you create 100 by 100 array LED, not copying? If copying, would naming be an issue?

[princelog]

To be honest, my application is one of those extremes that local variables and reference works the best, just a heads-up for other readers.

[altenbach]

---

@princelog wrote:

How do you create 100 by 100 array LED, not copying? If copying, would naming be an issue?

---

You drop an LED into an array container, change the dimension to 2D by dragging the index terminal down to show two indices, and resize the container to show 100x100 elements.

If you keep that array inside an action engine you can

1.  update it from anywhere in the code
2. read out the content anywhere else.

No local variables needed at all. Here's a very simple example. Of course you would add more modes to the action engine and an enum input to select it (modes could be read content, init to set size, toggle, set FALSE, set TRUE, query element, etc.). Make the most used mode the default so you don't even need to wire the enum in these instances.

For 100x100, a more lightweight solution would use a U8 intensity graph. Now you could even give each element one of 256 different colors (not shown).

[altenbach]

---

@princelog wrote:

To be honest, my application is one of those extremes that local variables and reference works the best, just a heads-up for other readers.

---

Just as a heads-up to all, It is actually the other way around: The use of local variables and references turns a simple case into an extreme case. 😄

Study my example above. I made it especially for you!

[princelog]

Thank you for the excellent model, but it won't work here.

First, we could not use a LED array, I didn't know what that was before, but for indication and visualization reasons. you could imagine the display we will be using for this application, it is required to use separate LEDs.

Also, your solution is specifically complex, no offense, to introduce for undergraduate interns within 20min and make sure they fully understand.

Third, the way you did it will kill future flexibilities to easily change and verify the steps, also there is an overall initialization, and single channel initialization, prevention at halfway, halt, restart, etc. It will change the code over time, and when the intern is gone, it will become more and more hard to explain for the next intern.

No matter how, our issue has not been resolved yet, because we still curios about the order icon/labels are created, once I have a chance to talk to NI representatives, I will update you all, not need to try to change our code structure, it's something out of your horizon, I mean it's credential.

[Mark_Yedinak]

Personally I would avoid the action engine and use a class instead. Classes are more versatile and makes the code more readable as you are calling methods to perform your work rather than using an ENUM into an action engine to document your work. When it is a class it is easier to add more specific implementations through inheritance. And just like the action engine this results in a single wire needed to be passed through your code. Hopefully that is some type of state machine or queued message handler and not a bunch of flat sequence structures. There are lots of examples of state machines or queued message handlers available.

Should you use either method, action engine or OOP, I would recommend that no UI activities occur in either the class or the action engine. You should architect the system in such a way that the business logic (the stuff that actually does the work) and the UI are kept separate. They are two very distinct things. This results in cleaner code and best of all it allows for significantly more code reuse. Once application specific stuff works it's way into the business logic it makes re-use much more difficult.

Regardless if you use OOP or not, you should look at the SOLID programming principles. While they do indicate that they are for OOP the basic principles can apply to other coding paradigms as well. For example, the first principle of Single Responsibility means your code blocks should do one thing and one thing only. In the LED example in this thread the code handling the LED stuff should just concern it self with maintaining the state of the LEDs. It should not be concerned with how they will be displayed for example. This is another reason I recommend the OOP approach because the action engine by design breaks the Single Responsibility principle since it contains all of the logic.