03-22-2011 08:30 AM - edited 03-22-2011 08:31 AM
carloman wrote:Im using LEDS as they look good and are easy to turn on & off directly with boolean data.My final code will have about 80 LEDS,so I need it to be easily scalable.
Is this really necessary? Eighty controls is a very crowded and complicated UI. I would see if there is a better way to give your user control over the actions instead of using so many boolean controls. Two ring controls come to mind. The first provides condition A and teh second condition B. This approach is also more managable and maintainable. That many controls will be difficult to maintain even using the single event suggestion altenbach suggested. The UI itself will be a mess.
03-22-2011 08:48 AM
I fully agree!
However, 80 booleans are easily manageable with clean code if done right. For example it could be arranged as a 10x8 2D boolean array with the rows and columns nicely labeled and an ON would indicate a connection (such as in a crossbar switch).
Instead of booleans, it could be an array of color boxes with off=black, state1=red and state2=green. Depending on what it represents, it could be quite usable. 😉
03-22-2011 08:54 AM
Yes, it does depend on the specific use and it could be done in a way that was usable. However since the OP was talking about using them because they were easy I suspect that their UI may not line up with the grid approach. Its still worth mentioning since we may steer them to a better approach.
03-22-2011 06:13 PM
Thanks altenbach for yoru code and Mark for your comments.
I havent quite got the hang of events yet...hard to believe !
-Using the boolean references is new for me and is a great improvement..thanks.
-I created a new event for state, to do my processing, but I believe it is conflicting with the mouse down events.
How should I define this "processing" event to avoid this.? Then I can place my "processing" code in that event..Great !
Regarding the many booleans. My FP is similar to an old switchboard, with 80 terminals (LEDS) which will have "wires" drawn between the 2 selected terminals. They are spread out all over the FP...not in a grid format.
I will aim to merge them all as either an array or cluster, though beyond turning them on or off, I dont need to do anything else with them.
This UI code then passes parameters to a loop running a simulation, graphs etc, which is working well, though refinements needed.
Regards,
carloman
03-23-2011 09:16 PM
"Now simply do the further processing in a new event and ignore if the state is not right. Modify as needed."
----------------------------------------------------------------------------------------------------------------------------------------------------------
Hello again,
What should the further processing event be ?
Should it be triggered by "state" value change ? This seems to be ignored due to conflict it seems ?
Or should the "processing" be placed inside the boolean "mouse down" event case...in a subVI ?
Thanks for any further pointers.
Much appreciated.
carloman