Risks of setting controls programmatically

[Bertha]

Does anybody know what are the risks(if any) of setting the values of a control of a vi programmatically from a different vi?

I'll appreciate the help. Thank you

[Ben]

1) race conditions - If the VI is itself is writting to that control, that last writter wins.

2) Use value Signalling if the control is read by an Event struture.

3) User Interface is a bottle-neck

4) Data buffers are copied.

I'm sure there are more. Of cocurse if you have access to the source code for those, You can investigate both of those issues.

Ben

Message Edited by Ben on 02-26-2010 01:58 PM

[Mark_Yedinak]

Ben hit the main issues that come to mind. Lately I have been very focused on decoupling my code and when different components need access to data I use either a message passing scheme or some type of accessor function to get the desired data. The only exception would be subVI specifically designed to update or interact with the user interface. In this case the sole purpose of the subVI is to manipulate the UI so I will allow it to directly interact with the controls or indicators. The primary reason I have adopted this strategy is to increase reusability and modularity of the code.

[TerraNova]

Hi!

There can be no risk when you control all the components of the whole program. In other words, it's o'kay if you're the only who writes the code .

Just keep in mind all the things Ben have mentioned.

And, by the way,  setting controls programmatically is what object-oriented programming is about , so just do it!

Enjoy!