Programmatically change a Text Ring

[mcduff]

I have not used private methods,  nor libraries at all. Most of my projects are smaller and are not shared, so no real need. Also, since I don't use them, I can't say anything to benefits, drawbacks, etc.

Here is another method to get the time scale, using an enum, not a text ring. It seems a little Rube-Goldberg, and may even make that thread on the side discussions. You can create a subVI for the math, and inline it, if you want, no private methods, no libraries, one "simple" subVI.

It assumes you enter the time/div in the enum and it gives a DAQ time of 10 time divisions like an oscilloscope.

How do you like them apples JeffB?

2017 version attached.

mcduff

[JÞB]

Here is a screen capture of the lvlib owning project  The one you use to edit, debug, document, and regression test the lvlib!  you then would use the lvlib in your target project by either just adding the lvlib or allowing it to sit in dependancies

In this case I would put it in the project because I can see right now that I will want to load that ring with values from a file and maybe that library will have friends in this library.  Depends on the project hierarchy.

[Kevin_Price]

llb's:  these should now be considered archaic.  They served a useful purpose at an earlier time in the development of LabVIEW and common OS'es (8.3 filename restrictions, anyone?), but the problems they solved can be solved other ways equally well or better with less risk (search "corrupt llb" sometime...) 

lvlib's:  I should probably use these more.  I'll give you some of my informal, seat-of-the-pants thoughts and let others weigh in on their more formal comp sci value (also important!  I'm just not so qualified to comment).

   I used to be a big-time user of Action Engines.  They were the joints that helped to bind together separate parts of my code (acquisition, analysis, logging, display, etc.).  My first major usage of the lvlib was to make a big improvement to my AE's.  As referenced by Jeff·Þ·Bohrer, I started making lvlib versions of my AE's.  The AE itself became the private core that the rest of my app was not allowed to call directly.  The public API functions were the only way for my main app to use it.   So, why was this a Good Thing?

• All possible inputs and outputs for *any* action of the Action Engine were always present.  The combination of required, optional, and ignored inputs & outputs might vary from one action to the next.  It wasn't intuitive to know what *needed* to be wired.   Further, I might have an output named "result" for data processing AE.  The meaning of that result could vary from one processing action to another (peak force, total time, median, RMS, etc.). 
• It was *much* nicer to have a public API where *only* the relevant inputs and outputs were exposed and could be named with more intuitive relevance.  I could also make a kind of macro out of sequence of actions.  I'd make private API-like functions for each step in the sequence and a public API function that exercised them in the correct order, chained the relevant data through them, and combined their results into more meaningful outputs.

With that as a starting point, I found that there were other benefits of thinking about little utilities and modules in terms of a set of (private, hidden) core functionality and a limited (public, visible) API for using them.  A fair amount of the value for me was the simple self-discipline involved in defining a public API.  It helped make me take a moment to think before plunging in and coding.

Getting used to lvlib's and the distinction between private internal code vs public API functions were a great benefit in learning to dabble with LVOOP.  An lvlib has a lot in common with an lvclass.

-Kevin P

[JÞB]

So lets look at that API,  I did add a private tree.vi Not shown above

Don't all those VI look like they work together even from just the icons?  And yes Tree.vi is broken because the Init and Do vis are missing required inputs. SEE the error chain merge in Close?  Close Closes typical for "Close/Destroy" operations

Core looks like this.  Just an Action Engine (Feedback Nodes rather than Shift Registers) 

The project even comes with a Demo! or Soft Front Panel (Every library should have one!)

And room for unit tests..... Can't have them here because there are no written requirements!  I just have a personal aversion to writing tests that have no written requirement!  So, you'll note that the vi documentation is lacking too!  When I get the requirements I'll add those oh so nice features.

(Read that as you get what you pay for) 

I haven't even gotten into how a lvlib improves navigation of the VI Hierarchy view yada yada.  Ben will probably add a link to his blog post about that anyway no reason for me to misquote that gentleman here.

I did zip and attach the source. Enjoy

[crossrulz]

---

@Kevin_Price wrote:
I used to be a big-time user of Action Engines.  They were the joints that helped to bind together separate parts of my code (acquisition, analysis, logging, display, etc.).  My first major usage of the lvlib was to make a big improvement to my AE's.  As referenced by Jeff·Þ·Bohrer, I started making lvlib versions of my AE's.  The AE itself became the private core that the rest of my app was not allowed to call directly.  The public API functions were the only way for my main app to use it.

---

This is one of my biggest uses of libraries as well.  Otherwise, they are just so useful for breaking up modules/actors in your project.

---

@Kevin_Price wrote:

Getting used to lvlib's and the distinction between private internal code vs public API functions were a great benefit in learning to dabble with LVOOP.  An lvlib has a lot in common with an lvclass.

---

Which is why they are a lot more closely related in NXG.

[JÞB]

Now, compare Coerce Core with this attachment.

Spoiler

Oh, when I ran Coerce SFP.vi I noticed something....

But because I'm Soooooooawesome!  that was a 2 minute fix since the demo isolated the library key functions and gave me the tool I needed to do what needed being done without worrying about the rest of the system.

[RTSLVU]

Hmm.... I guess I still don't understand why having the lvlib with the core being "private"  three separate VI's each with the core and the Enum inside for common tasks is better than just having the core as a sub-vi in my project and using it like I would use any other AE or FG.

[RTSLVU]

I thought about this while I was eating lunch and I guess I could see using an lvlib if I was making something like an instrument driver for distribution. 

But since %99 of the programs I write are custom programs written for me to use on a specific project and never used again. I have never have to even think about packaging things up neatly for distribution.

[crossrulz]

---

@RTSLVU wrote:

But since %99 of the programs I write are custom programs written for me to use on a specific project and never used again. I have never have to even think about packaging things up neatly for distribution.

---

You really should rethink your processes then.  If you broke down your programs, it is very likely you will find commonality.  When you find those, that is when libraries and classes help a lot.

[JÞB]

---

@RTSLVU wrote:

Hmm.... I guess I still don't understand why having the lvlib with the core being "private"  three separate VI's each with the core and the Enum inside for common tasks is better than just having the core as a sub-vi in my project and using it like I would use any other AE or FG.

---

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.

In which order do the vis execute?  Ok, wire up the error chain.  

Oh, now when you run the vi that has no warning from the compiler you get an error! Why? what is the error?

Something blah blah arg1 property node in Coerce Core.vi...the refnum might be invalid...... which pnode? That subvi was called 3 times with the exact same call chain!  This is a simple 3 method engine.... how many times would your project call coerce core from the qmh that uses it?  Make that core vi a RFmx resource and get ready to troubleshoot hard!  Breakpoints....nah too slow,  conditional probes only! And drill up through the call ring to find which call through the error.  Worse, a good 50percent of you all reading this are digging through the help file for call ring.  And you are the ones who use these forums! Over 80 percent of LabVIEW Development is done by people who don't know what that ring control appearing on the toolbar when a vi is paused does .

Ok, so we went about everything the hard way but still we have to find why that instance is throwing up errors.  Holy cow there is a required input missing! Or, did the enum say close when we ment init?  And look at those red coersion dots!!!!! That is not the type defined enum the engine needs!

The other argument you hear it why bother with the extra work....

I'll challenge you to look at timestamps on my posts for this thread.  BRB meant I put down my phone, unpacked my laptop, re read the thread opened 2018 and backsaved mcduffs snip to the 2017 version you use, opened 2017 which has rt vision fpga and all the bells so it takes some time to open (I really need a solid state drive) wrote the project complete and created the project picture post.  I wasn't rushing.

It took more time to create tree.vi and capture the inlined snips than designing and executing the lvlib development.  I already made the justifications in ease of use maint integration and debugging.  It does not take additional time...it saves it by the bucketful.  Damned shame I get paid by the hour!