Connector pane patterns for class accessor VIs

[MikaelH]

Are there any ways/plans of having other connector pane patterns for class accessor VIs than 4-2-2-4?

[JÞB]

You can suggest it on the Idea exchange-  but dynamic dispatch vi's are limited to 4-2-2-4 as of the latest LVOOP implementation

[tst]

---

@Jeff Bohrer wrote:

...dynamic dispatch vi's are limited to 4-2-2-4 as of the latest LVOOP implementation

---

Are you sure about that? That doesn't sound right at all. It is true that all DD VIs which are used together need to have the same CP, but I'm assuming it would work if that CP was different from 4-2-2-4.

[JÞB]

---

@tst wrote:

---

@Jeff Bohrer wrote:

...dynamic dispatch vi's are limited to 4-2-2-4 as of the latest LVOOP implementation

---

Are you sure about that? That doesn't sound right at all. It is true that all DD VIs which are used together need to have the same CP, but I'm assuming it would work if that CP was different from 4-2-2-4.

---

It was what I was taught-  but I can't find it in the help....Hmmm

[richjoh]

4-2-2-4 is the default when you use the Create Accessor dialog box. If you change it subsequently it break your code. I don't agree with this, it too strict on CP.

Unless you been creating your Assessor manually 4-2-2-4 is the default.

Besides the point there needs to be a way to create 1 Assessor that contains all properties on the Ctrl. Instead the dialog generates 1 property, 1 VI. Just a thought.

[tst]

---

@richjoh wrote:

...If you change it subsequently it break your code.

---

 I'm assuming you mean that it breaks the code if some of DD VIs have one CP and others have another. That's reasonable because it's a basic requirement of DD VIs that they all have the same CP. The actual CP used in the template is a matter of personal preference, but 4-2-2-4 has certainly been established as a de-facto standard (which I personally prefer as well). If you want the option of having another pattern, add an idea to the idea exchange that the CP pattern for accessors be an option.

---

Besides the point there needs to be a way to create 1 Assessor that contains all properties on the Ctrl. Instead the dialog generates 1 property, 1 VI. Just a thought.

---

The reason for having a separate accessor for each member is to isolate problems. The point is that in each accessor you can add code which will validate the input and perform other things if needed. That way, you can know the state of your object better and if there's a problem when configuring the class, you can report it more accurately.

As for saving time, LV already has some shortcuts:

In the create accessor dialog you can select as many data members as you like by clicking Ctrl or Shift and their accessors will be created together.

Similarly, in LV 2010 and later you can create a property folder for the accessor, so that it's accessible through the property node, which allows you to call as many accessors as you like in a single node on the calling diagram.

[richjoh]

---

I'm assuming you mean that it breaks the code if some of DD VIs have one CP and others have another. That's reasonable because it's a basic requirement of DD VIs that they all have the same CP. The actual CP used in the template is a matter of personal preference, but 4-2-2-4 has certainly been established as a de-facto standard (which I personally prefer as well).

---

Invalid accessor VI connector pane pattern

This VI is a member of a LabVIEW class, but the VI does not have the correct connector pane pattern to be an accessor VI. Accessor VIs in the property definition folder must have a 4 × 2 × 2 × 4 connector pane pattern.

I want the option to set my own connector pain pattern. Your all stuck with 4x2x2x4, unused connecters could lead to human inadvertant problems.

---

The reason for having a separate accessor for each member is to isolate problems. The point is that in each accessor you can add code which will validate the input and perform other things if needed.

---

I have a slight disagreement, its to get and or set the methods and any property. Methods are for adding functional code. As for saving time, it would save time to have 1 VI that clusters all ctrl values into 1 VI. I've already Ctrl+click all properties of the ctrl data and have LV auto generate X (i.e. many) VIs, each to get or set a ctrl property. Not the way I would do this if I have a choice. I'm sure someone will improve this in a latter LV version.

[JÞB]

I have a slight disagreement, its to get and or set the methods and any property. Methods are for adding functional code. As for saving time, it would save time to have 1 VI that clusters all ctrl values into 1 VI. I've already Ctrl+click all properties of the ctrl data and have LV auto generate X (i.e. many) VIs, each to get or set a ctrl property. Not the way I would do this if I have a choice. I'm sure someone will improve this in a latter LV version.

---

You are not limited to using the accessor vis to get at the data members- you can also get/set multiple data member values from a property node

[tst]

---

@richjoh wrote:

---

...This VI is a member of a LabVIEW class, but the VI does not have the correct connector pane pattern to be an accessor VI. Accessor VIs in the property definition folder must ...

---

Well, like the error description says, that's only for VIs in a property definition folder, because the assumption there is that you're going to call the VI using the property node and you're not going to see its connector pane and LabVIEW will only allow you to set one control or indicator in the CP in any case. If you really care about this, you can vote for this idea. It should be a relatively easy change for NI, but personally I think it would be a waste of resources.

---

As for saving time, it would save time to have 1 VI that clusters all ctrl values into 1 VI. I've already Ctrl+click all properties of the ctrl data and have LV auto generate X (i.e. many) VIs, each to get or set a ctrl property. Not the way I would do this if I have a choice. I'm sure someone will improve this in a latter LV version.

---

Well, you can wait as long as you like, but I highly doubt you will ever see NI changing this because of the reasons I gave before. If you really want you can have the data inside the class as a typedef cluster and then write that cluster, but for that you don't need classes - you could just use the cluster directly. Classes are supposed to prevent you from having to do that.

[Ben]

I use an non-standard connector pane patttern in all of my LVOOP stuff. Just set it up when you start and LV adapts to whatever version I selected when creating the over-ride VIs.

Goruping more than one value in an accessor will reduce the granularity posible. By stick with a single value, we can use LVOOP to pick and choose which value gets over-riden.

Ben