Bug: Constant of reference of Image Display in typedef cluster for FGV doesn't work

[Agr1gor]

Hi there,

I think there is a bug at least since LabVIEW 2010 with the Image Display in the Vision Toolkit.
I use a Producer-Consumer-Architecture and handle my references of all frontpanel elements inside a typedef cluster inside a FGV to get access to their properties in subVIs. At the moment I use Labview 2018 SP1.

The regular way to get a new frontpanel element accessible by a subVI is as follows:

1. FGV with a typedef cluster of constants of references
2. Create a reference of the indicator/control in the block diagram 
3. Create a constant of this reference
4. Cut the constant
5. open typdef cluster
6. paste the constant inside the cluster
7. Save the typedef cluster
8. Call the FGV with the "get" command inside a subVI
9. Connect a "unbundle by name" node
10. Connect a property node
11. There you are: You got read and write access to all properties of the indicator/control at the main frontpanel

This works for all indicator/controls I ever used, BUT for the image display. If you do it like described above, it behaves as follows:

1. FGV with a typedef cluster of constants of references
2. Create a reference of the indicator/control in the block diagram 
3. Create a constant of this reference
4. Cut the constant
5. Open typdef cluster
6. Paste the constant inside the cluster and ooops.... there is nothing, it simply disappears... whoat?!?

Possible solution:

Connect the reference to each subVI you want to use it inside, but it's not that beautiful, handy and consistent as to call a FGV for everything.

Does anyone have another solution or why is it that way or why isn't that fixed yet?

Thanks in advance and kind regards,
Agrigor

[paul_cardinale]

I'm surprised that works for any controls at all.  I would expect reference values to be assigned dynamically, and not necessarily be the same the next time the VI is loaded.

[Ben]

The image control is a special animal.

Info can flow backwards through an image wire.

Post an image to go with your verbiage to help us SEE what you are doing.

Ben

[Agr1gor]

You can find my "verbiage" in code in the attachment.

There is a simple Producer-Consumer-Architecture with 3 elements on the frontpanel:

• Quit-Button
• Intensity Graph
• Image Display

I created, like in my initial post described, a reference of the indicator and a constant of this reference to move this one in the typdef cluster for the FGV. I placed them below the structure, so you can find it without searching.
Please test, if you can move the reference constant inside the fgv cluster.

Chriss

[rolfk]

You can't! There is no object refnum for the IMAQ control. For some reason you can create a constant for it but not a refnum control.

But I'm anyhow not a fan of an application structure that puts all the controls in one big cluster to pass to everything. That's almost the perfect violation of separating the UI from the application logic.

You will have to live with this if you want to program now.

[paul_cardinale]

---

@rolfk wrote:

You can't! There is no object refnum for the IMAQ control. For some reason you can create a constant for it but not a refnum control.

---

It works for me.

[rolfk]

---

@paul_cardinale wrote:

---

@rolfk wrote:

You can't! There is no object refnum for the IMAQ control. For some reason you can create a constant for it but not a refnum control.

---

It works for me.

---

Show us a VI with that! I can't do it and I tried it on several LaVIEW versions between 2009 and 2016, so I assumed it's a LabVIEW thing but it could of course be an installation issue (such as having more than 1 LabVIEW version and IMAQ Vision version installed maybe?)

Still the architecture with one big cluster with all the GUI refnums in it definitely isn't a great design.

[Agr1gor]

At first: Thanks for all the comments so far!

@paul_cardinale

I also want to see a working example, I can't imagine that... 😕
At the moment, I got a clean PC with only LabVIEW 2018 SP1 installed.

@rolfk
If this is a design fail or not, it's your personal sideshow and does not lead to any constructive solution of the problem. In addition: TBH, you know nothing about my entire sofware architecture, only the example, and it's maybe hard for you: but you can seperate application logic and UI logic even if you use FGVs with a cluster of references. I could even say: I just use this design to gain such a seperation and in the end it fulfills all the needs, we want as good programmers: Readability, Maintainability, Efficiency and simply good code, trust me 😉

Does anyone else know another reason for this behaviour of LabVIEW?

Kind regards,
Chriss

[Ben]

---

@Agr1gor wrote:

At first: Thanks for all the comments so far!

...

Does anyone else know another reason for this behaviour of LabVIEW?

Kind regards,
Chriss

---

I have had associates that specialize in vision application work with me so the image functions are something that I have not played with in many, many years.

From what I recall (maybe LV 6.1 or LV 7.0 ?) the image control and it's wire "looked like a duck, but did not walk like a duck". The code looked like the normal data flow paradigm but it ended there. The image control itself seemed to be a lot like a an ActiveX container that the image lived in. The wire seemed to have been a reference that pointed at the image control. As I watched the code run I could see the image control that was at the left side of a diagram being updated and changed as the image processing functions executed. This stuck me as strange since the updated image info seemed to flow backwards through the wire to the image control.

So a reference to the image control... not sure what that would actually point at.

The image control wire itself... that is a different animal, but not a duck.

Now about the architecture question... I will bury that in a spoiler because I would like to rad more from my mentor Rolf.

Spoiler

Hi Rolf,

You words about the idea of using a cluster of control references struck a nerve with me because I have gradually over the years, and working a typical "LV_Developers_Bubble" developed a method pushing low level GUI functions down into sub-VIs where the tedious functions are handled. This lets my "top level VIs" present themselves as high-level and allows myself and readers of my code to see how the architecture is structured.

This is an old application developed back IN LV 8.2

What is the fancy OOP word? Cohesive? that says someone familiar with the function of the application should be able to recognize the implementation? In that application, we had a choice of two operating modes, or to exit.

But look to the left of that diagram we see a cluster with a bunch of control reference being pushed into and Action Engine that is labeled "GUI Cnt - Init" (GUI controller - Initialize).

If we take a look inside the VI that implements the "Analysis" mode of operation we see the sub-set of controls that are used in Analysis mode are registered using dynamic event registration as shown in this image.

This approached has served me well in many of may applications. I freely admit that most of my projects are "simple" in that they are one of a kind application that will seldom be duplicated and rarely enhanced. The customers I serve need  a specific application to do what they need and there is no intent to duplicate or sell it to others.

I also realize that there is very tight coupling between the code and the GUI. But for one-off applications the GUI and supporting sub-VI are useless without the other so tight coupling is not a problem.

The "Readers of my code" are generally people that have taken the NI training course but do not spend all of their time stringing wires. Once I introduce them to how I structured their code, they seem to catch-on quick are able to "tweak and peak" their code themselves with little or no help from me. Do you by any chance remember the old poster in the back of Spencer's gift shops where they had the black lights and the smell of incense that read "If you love something set it free. If it does not return it was never yours. If it does it always was." I take that attitude with my customers and attempt to enable them to move on without me. The insight I shared above are part of that intent.

As a trailing thought I will finish by saying that I once came to the conclusion that the closer to the GUI I got the harder it was to stay uncoupled.

In greatest humility, I look forward to your insight and wisdom.

Ben

[rolfk]

If it works for you, by all means continue to do it like that. For me it doesn't and I have in the past refused to maintain applications written like that for this reason.

While I"m not exactly a fanatic in implementing the so called separation from presentation and logic to its purest form, putting the whole UI into one big nasty cluster is more or less making such a separation impossible. Your top level VI will look neat and clean but especially the intermediate level VIs will tend to combine lots of logic that is interwoven between different controls that have little to do with each other. That can work if an application is either simple or while you initially develop the application, as you have a pretty good idea about the details of where this specific control is disabled/enabled and changed in various places. But when someone else has to maintain that software later, or even yourself in a year from now, it will be pretty hard to figure all these dependencies out and will take a lot of time to do if you need to add some new functionality.

Also reuse of functions for other programs, other than the most basic low level functions, is often impossible with such an appoach. That may not be of any concern if you plan to write one single application, but I write on average at least half a dozen or more LabVIEW applications a year, which tend to contain several subpanels with various functionality, and then reuse of software components definitely is a concern.