Programmatically change a Text Ring

[RTSLVU]

---

@JÞB wrote:

---

@RTSLVU

---

Well, let's look at that snippet 

The run arrow is broken isn't it?  Why init and do have required inputs that are not wired. So, drop a diagram disable around them and look farther.

---

Yeah okay, that was merely an example of how I would just use the AE and set the enum to init, coerce, or close instead of making an init vi, coerce vi, and close vi that just have the AE inside them 

I don't know maybe this AE was not a good example for lvlib because I hear what you are saying but still do not comprehend the benefit. 

How far does abstraction need to go? I mean if I tried I could probably make everything a sub-vi all the way up until my top level VI is nothing but one icon on the block diagram. I don't know what that would gain me beside a very tidy looking block diagram, and I am sorry but that's kind of what I see here.

As for the rest you are probably right, I imagine the majority of LabVIEW programmers are like me, not programmers at all, but Engineers and Technicians. Sure EE's pretty much have to learn some form of C these days, but the closest thing I did to programming in college was punching a few lines of Assembly into an 8085 dev board to light some LED's

But thanks for taking the time here, maybe someday lvlib will click for me.

[JÞB]

---

@RTSLVU wrote:

---

@JÞB wrote:

---

@RTSLVU

---

Well, let's look at that snippet 

The run arrow is broken isn't it?  Why init and do have required inputs that are not wired. So, drop a diagram disable around them and look farther.

---

Yeah okay, that was merely an example of how I would just use the AE and set the enum to init, coerce, or close instead of making an init vi, coerce vi, and close vi that just have the AE inside them 

---

Which Enum?  If it isn't private to the library and encapsulated in the API calls (Hidden) any numeric will work!  And yes, most of them will coerce in strange ways.  How do you know that you have the right enum and correct value on the calling block diagram?  You CAN'T.  you as the owner of the library left that implementation detail to the consuming developer,  Who, didn't come back to you and say "Nice, now go wrap that in a lvlib!" 

So, that developer just might just be unskilled enough in LabVIEW to do other silly things like: disconnect from typedef, use the wrong type def (say from an AE that has "Null,Init,Do,Clear,Close," values) forget to wire  Time per division in the Do Coerce call (check the math, Sample rate will be 0). 

Your AE has specific use case rules.  Enforce them with the API around Core and you never have to require the consuming developer to remember them all and execute each decision repeatedly and flawlessly every time they use the AE.  And they can't cross the blue wires!  its like Ghostbusters crossing streams- rarely useful and always dangerous.

The API wrappers don't just add another level of abstraction, they enforce inherent usage rules!  Developing the callers now does not require the details you already wrote once to be written again and again distracting you from meeting the requirements of the caller which you should be writing by worrying about minutiae you should have already written and wrapped in a nice Public API method.

[RTSLVU]

Not sure how I accepted that as a solution and I now I can't unaccept it but ...

I see your point and if I ever had to write something that is going to be distributed to other developers I would probably better understand the benefits.

[crossrulz]

---

@JÞB wrote:

Your AE has specific use case rules.  Enforce them with the API around Core and you never have to require the consuming developer to remember them all and execute each decision repeatedly and flawlessly every time they use the AE.

---

One of the few times I whole-heartedly agree with Jeff. I was in a User Group at a previous company and went over these concepts and my boss just stated "We are a small team, so the protection should not be needed."  My reply was "I am protected me from myself."  I can't count how many times I accidentally used the wrong enum value for an AE's task.

And once you get this concept of having private VIs and a public method API, you are just one little step away from going OOP (just add private data that is stored in a wire instead of an AE).

[JÞB]

---

@RTSLVU wrote:

Not sure how I accepted that as a solution and I now I can't unaccept it but ...

I see your point and if I ever had to write something that is going to be distributed to other developers I would probably better understand the benefits.

---

But,  you are the other developer!