Connector pane patterns for class accessor VIs

[JÞB]

Ben, I think you're in better shape than you suspect.  The point being you'll never drop the 4-2-2-4 con pane on the block diagram- You'll drop the property node instead. 

<Set wild speculation mode=VI_TRUE>

Mike - feel free to jump in If I'm off-

The Con Pane limitation is there to predetermine the exact con pane terminals the property node points to without needing to traverse Connector Pane Pattern Reference VI for each connector pane loaded in order to dynamically determine which (if any) of the terminals is a datatype on the same type as one of the class members.  (And lord forbid what if you wanted to access multiple values of the same type without restricting the con-pane.)

As I understand the con pane it would take a serious revision to keep the same performance and allow the user to willy-nilly wire class data members (Possibly not possible at all)

[Ben]

---

@Jeff Bohrer wrote:

Ben, I think you're in better shape than you suspect.  The point being you'll never drop the 4-2-2-4 con pane on the block diagram- You'll drop the property node instead. 

...

---

I get that part (I think). ...

Never mind me. I'll find something more important to cry about.

Ben

[SteveChandler]

---

@Ben wrote:

---

@Jeff Bohrer wrote:

Ben, I think you're in better shape than you suspect.  The point being you'll never drop the 4-2-2-4 con pane on the block diagram- You'll drop the property node instead. 

...

---

I get that part (I think). ...

Never mind me. I'll find something more important to cry about.

Ben

I started using the property node accessors when they were new because I thought they were cool. Then I went back to just using VIs. I found that the property node was bigger and uglier for accessing a single element. The only time that using them makes sense is when writing a bunch of properties at the same time which is rare. It is about as useful as unselecting view vi as icon. There are extremely rare uses mostly for dealing with old code.

This just reminded me of a micronugget that I have been intending to post.

---

[richjoh]

As for the property nodes of a lvclass. Is the speed issue similar when a ctrl is visible and use of  property node on the BD (speed hit from switching data process to UI process and back)?

The property nodes are good idea, my first use of them made me not like the generation of individual VI to perform simple actions. This could be good or tedious, I don't yet know. If there was a way to manipulate programmatically the property of interest then only 1 read and 1 write property is needed. In other words, if I could programmatically select the "unbundle by name" of interest in the read VI and have it output adapt i.e. morph the indicator (have no idea how though). If not that make the VI adapt at compile time a change in cluster selection and indicator read. Same idea for write.

The draw-back is if my lvclass has 25 or 50 or 100 properties, I'll deal with 2X many VI, set get. Then again, one could break up your class made of of smaller data sets for manageability.

[SteveChandler]

---

@richjoh wrote:

The draw-back is if my lvclass has 25 or 50 or 100 properties, I'll deal with 2X many VI, set get. Then again, one could break up your class made of of smaller data sets for manageability.

---

If you have that many properties you probably should look at breaking it up and using composition. But this is not an arbitrary breaking up of properties into a set of small groups for manageability. Most of my classes have other classes as their private data.

A really really good book is The Object Oriented Thought Process. It is not one of those 1,700 page beamoths and it is not specific to any particular language although examples tend to be in Java. Even if you do not know Java, the examples are simple enough that you can understand them anyway. I knew the mechanics of OOP but struggled with properly designing classes. This book really helped a lot. I got a used copy for $3.00 on eBay. I have way too many technology books and this one is both the least expensive and best and also has the lowest page count. It is on my desk with two other books while the others sit sadly on the shelf. Best three bucks I ever spent.

[richjoh]

"richjoh wrote:

The draw-back is if my lvclass has 25 or 50 or 100 properties, I'll deal with 2X many VI, set get. Then again, one could break up your class made of of smaller data sets for manageability."

Another way around so many individual assessor VI is to create the class with a cluster (the lvclass) in a cluster with the internal cluster made of the class private data set. Now when the assessor is auto generated you can get set an entire cluster of private data. This leaves you free to set an individual value inside the cluster or many values. Going to try this next time...maybe assessors property nodes are a good idea. Do they, assessor property nodes use the UI thread? It would be nice to define the connector pattern and not fixed on 4x2x2x4.