Updating front panel controls and indicators by reference

[Ongelofeloos]

Imagine that the image below is a SubVI that is called by the main VI to update an indicator with label 'Z2Position' on the front panel of the main VI. Is it ok to do it like that? The input of the subVI would be the reference of 'Z2Position'.

[Mark_Yedinak]

That's is a very valid way to handle your UI. When it becomes an issue is when you start mixing UI elements with core logic. All of the UI handling code should do nothing other than handle the UI. You business logic (the code that actually does the work) should not be concerned about the UI at all. Once you start mixing the code for the UI and the core functionality you end up with highly coupled code which is more difficult to update and maintain. In addition, you significantly reduce the amount of re-use you will have.

[JÞB]

I don't know why you would want to create a data value reference to a reference to an object but, simply passing a reference into a sub vi is certainly a good way to hand off updates like that.

I'd use an Action Engine myself

Ben's famous Action Engine Nugget is always a good read. http://forums.ni.com/t5/LabVIEW/Community-Nugget-4-08-2007-Action-Engines/m-p/503801

[Ongelofeloos]

---

@JÞB wrote:

I don't know why you would want to create a data value reference to a reference to an object but, simply passing a reference into a sub vi is certainly a good way to hand off updates like that.

---

I wanted to use the element structure since it is non reentrant and I am not sure if a property node has the same aspect.

---

@JÞB wrote:

I'd use an Action Engine myself

Ben's famous Action Engine Nugget is always a good read. http://forums.ni.com/t5/LabVIEW/Community-Nugget-4-08-2007-Action-Engines/m-p/503801

---

If I use an Action Engine I would have to put 'Z2Position' in a while loop in the main vi, right?

[Ongelofeloos]

---

@Mark_Yedinak wrote:

That's is a very valid way to handle your UI. When it becomes an issue is when you start mixing UI elements with core logic. All of the UI handling code should do nothing other than handle the UI. You business logic (the code that actually does the work) should not be concerned about the UI at all. Once you start mixing the code for the UI and the core functionality you end up with highly coupled code which is more difficult to update and maintain. In addition, you significantly reduce the amount of re-use you will have.

---

Could you elaborate on when it becomes an issue or do you have some examples?

[JÞB]

---

@Ongelofeloos wrote:

---

@Mark_Yedinak wrote:

That's is a very valid way to handle your UI. When it becomes an issue is when you start mixing UI elements with core logic. All of the UI handling code should do nothing other than handle the UI. You business logic (the code that actually does the work) should not be concerned about the UI at all. Once you start mixing the code for the UI and the core functionality you end up with highly coupled code which is more difficult to update and maintain. In addition, you significantly reduce the amount of re-use you will have.

---

Could you elaborate on when it becomes an issue or do you have some examples?

---

---

@Ongelofeloos wrote:

---

@Mark_Yedinak wrote:

That's is a very valid way to handle your UI. When it becomes an issue is when you start mixing UI elements with core logic. All of the UI handling code should do nothing other than handle the UI. You business logic (the code that actually does the work) should not be concerned about the UI at all. Once you start mixing the code for the UI and the core functionality you end up with highly coupled code which is more difficult to update and maintain. In addition, you significantly reduce the amount of re-use you will have.

---

Could you elaborate on when it becomes an issue or do you have some examples?

---

At the risk of repeating myself.... a further detailed discussion of this is  found in the Nugget I linked earlier. 

Ben's famous Action Engine Nugget is always a good read. http://forums.ni.com/t5/LabVIEW/Community-Nugget-4-08-2007-Action-Engines/m-p/503801

[JÞB]

Ironically,  I caught the double quote bug

[Mark_Yedinak]

For example, let's say you have a basic producer/consumer application. You should not put your data acquisition code in the same VIs as your UI code. The data acquisition code should do nothing more that acquire the data. It should pass the data to other modules which would handle the analysis or UI updates. Let's say you create a library to interface with some piece of equipment. That library should only be concerned with interacting with that particular piece of equipment. Often you will see people passing UI references to this library so it can update the UI. Now your library is tightly coupled to a particular UI design. This makes re-using that library in another project more difficult because that UI will need to have same control types  for the UI references that were passed to it. As a result, you may not be able to use the library in a headless system that doesn't have a UI because the library needs the UI references to work. You could put all kinds of verification code in the library to work even if the references are invalid but why burden it with that responsibility. It shouldn't care about the UI at all. All it should do is interact with the specific piece of equipment it was designed for.

[Ongelofeloos]

---

@Mark_Yedinak wrote:

For example, let's say you have a basic producer/consumer application. You should not put your data acquisition code in the same VIs as your UI code. The data acquisition code should do nothing more that acquire the data. It should pass the data to other modules which would handle the analysis or UI updates. Let's say you create a library to interface with some piece of equipment. That library should only be concerned with interacting with that particular piece of equipment. Often you will see people passing UI references to this library so it can update the UI. Now your library is tightly coupled to a particular UI design. This makes re-using that library in another project more difficult because that UI will need to have same control types  for the UI references that were passed to it. As a result, you may not be able to use the library in a headless system that doesn't have a UI because the library needs the UI references to work. You could put all kinds of verification code in the library to work even if the references are invalid but why burden it with that responsibility. It shouldn't care about the UI at all. All it should do is interact with the specific piece of equipment it was designed for.

---

I see, thanks for your awesome explanation. 

[altenbach]

Maybe you can give a more global perspective why you even need that. An indicator is a data sink and should typically receive data at the terminal directly.

Your code only makes sense if this "indicator" is not even connected in the main code or is abused as data storage (i.e. fake "variable"), later to be read vial local variables or value property nodes elsewhere (yuk!).

Please explain.