Link Indicator to LVOOP Private Data

[NathanJD]

I've been developing with LVOOP recently and I'm loving it but one thing that I don't quite understand is the best method to display my private data in an indicator on my main VI's front panel.  In my case, I have a "vehicle" object that contains several "controller" objects.  I would like to link the private data from one of these controller objects (e.g. a position) to an indicator.  So, when I tell the controller that X is your new setpoint, the user can see the position change as it tries to achieve that new setpoint.  Another situation would be where I'm reading from the CAN bus to retrieve a specific piece of data and this CAN message could have a fairly high repetition rate.

There are two methods that I can think of for doing this:

• Polling: using an accessor in my main VI to get the data and write directly (or via a local variable) to the indicator (or control).
• By Ref:  Store a reference to that control/indicator in the private data and update the contorl/indicator via a property node in the setter accessor.

Recently I've been reading about slower execution times for updating indicators/controls via property nodes and wanted to make sure that I get the best method for the case of using OOP.

[tyk007]

Option 2 sounds like a terrible idea. Option 1 is the best option if your Controller objects are executed by your caller object indirectly through the wrapper object above (ie synchronous with your caller). Perhaps an Option 3 where the caller can register to an event when somthing happens in one of your controller objects; this is a good option if your controller objects are executed asynchronously from your calling code.

[NathanJD]

My controller objects are essentially running asynchronously from the UI which contains the indicator(s).  So, option 3 sounds like a something I might be able to figure out.  However, if my controller objects are able to trigger anything on my UI (whether it be via property node or event), I'll probably need to only do so in the event that the data changes to prevent excessive writes or events.  Does that sound reasonable in the general context?