Bind VIs to Object to access private data (with possible side effects)

[LabViewTinkerer]

I tried to implement a VI which is part of a class and should access the private data after an asynchronous call. This is not possible, because, when I wire an object to a VI it is call by value and not call by reference. What I would like to have is something like this:

See the little key for referencing the private data. Just like a global one. I'm totally aware that this may cause side effects, but by this I could easily create a actor model OOP based. This would mean better encapsulation than other approaches.

In my example I wanted to create a control system for an oscilloscope. All settings should be stored in the object. For each oscilloscope there should be an object. Unfortunately, there is the need of running a while loop in the background. This needs an asynchronous call. But as the background loop is running, changes in the setting should immediately impact the behaviour. If I wire the object to the asynchronous call, a copy is made and changes in the object wont affect the behaviour. Therefore, I would need life access to the private data. 

I hope it is clear, what I want and why I want it.

[crossrulz]

Perhaps you should just look at using the Actor Framework, which has been a part of LabVIEW for a long time.

[Intaris]

Instead of moving to the actor framework (Which I think is overkill for what the OP wants to do) just make the data field in the Objects a DVR, that way they'll all point to the same address in memory (and will then be by-reference instead of by-value).

[AristosQueue (NI)]

Moving to a DVR won't do binding. LabViewTinkerer would still need an event trigger every time a field changes or a polling loop.

> I hope it is clear, what I want and why I want it.

Yes, that's clear. But community experience of the last decade strongly indicates that architecture that you are asking for is inherently problematic in a multi-thread environment, which is why Actor Framework or DQMH or LapDog or several other actor-oriented frameworks have gained popularity.

I encourage you to go investigate the tools that have been developed to address this issue.

[Intaris]

In respect, he states he needs live access, not live notification of changes. Not neccessarily the same thing.  One solution is orders of magnitude easier to implement than the other.

In addition, how does utilisation of Actor Framework or LapDog help with binding in any way?  Not being facetious, honest question.

[drjdpowell]

By-reference data sharing explicitly breaks the "Actor Model", which was motivated partly by avoiding all the issues with such methods.  

With Actors, access to settings is done by messages.   In "Messenger Library" (which might be what AQ meant with "LapDog") I change settings with command messages and read settings either by Reply messages (Request-Reply), or by Notification messages (Register-Notify aka Publish-Subscribe).

The OP is asking for a by-ref version of LVOOP to support what I would call an "active object" architecture.  For that, I suggest a DVR containing a by-value Object.  Not sure why the OP doesn't think this a good idea. 

[AristosQueue (NI)]

I had a reply written out. Stupid ni.com system trashed it instead of submitting it because of timeout. I do not have time for regenerating. Sorry... other priorities.

[wiebe@CARYA]

See this post:

https://forums.ni.com/t5/LabVIEW/LabView-OOP-nest-independent-running-VI-in-Object-bind-vi/td-p/3778...

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.