Structuring code for reuse

[andrewDJ]

I'm very new to LabVIEW and I'm kicking off with a reasonably complex framework, using OO, to get to grips with the product.  It's the best way I learn and I'm under no time pressures so can evolve it, re-factor it, and even scrap and rebuild when I understand more.  I've got some experience with LabVIEW NXG in which I built the same framework but clearly that's a dead-end path.

I've become a bit confused about the best way to organise the code for such a purpose.  I want the Framework to be reusable across application projects and I've been searching the forum, papers, help and so on for a couple of days now but I don't seem to be coming across very clear answers (to me) so I'm looking for help.

My current thoughts, based on my research, are this:

• I create a project that is used to develop the framework, and save it to a directory \LabVIEW\Library\Framework.
• I point User.Lib at that directory. I will use LabVIEW across more than one computer and this is a shared space so makes sense
• I create a VI (and sub-VIs etc) that is an example usage of the framework under the project
• I create a library to hold the reusable framework classes
• Within the library I use virtual folders as Packages (in the UML sense) to aid in namespacing and protection - public and private at the top level - such that usage of the library by other applications is restricted to the classes in Public.  There is dependency between classes in Public and classes in Private obviously, but no recursive dependency (i.e. classes in Private are not dependent on classes in Public)
• When I want to reuse the framework in another application, e.g. one built and stored in \LabVIEW\Projects\MyProject I create a virtual folder (for organisation) and add the library file into that folder (not the project, because I don't want the example APP stuff in it) <- it may be that storing the library in what is effectively user.lib makes it available anyway??
• Any maintenance of the Library is done through its project and changes are then available to any consuming application (I understand the potential semantic and syntactic problems that may arise with this but for now I'm ignoring them.)

It's just me at this, I'm not involved in any commercial environment so I don't need to bother with VIPM to create packages for distribution (at least I don't think I need to!)  Here's what I'm thinking in pictures:

Firstly, the framework development project

Secondly, a project that reuses it

Anyone have any feedback and/or better ideas?  Could I, for example, not bother with a project and just create a library straight off and still have the example VI app? 

[JÞB · Accepted solution]

Two Words: Project Templates 

(Sometimes known as "Playing Simon Says.")

[andrewDJ]

So this would be a great way of creating the "consuming" project as it would set up the new project with the framework already embedded?  That's a great pointer, thanks.  

Would that leave the framework in the same location, so future updates/bug fixes could be used, or copy it into the new project's folder structure?  My preference is to be able to maintain the framework in one place and have those changes reflected wherever used - subject to opening the application and recompiling I guess.  

[JÞB]

---

@andrewDJ wrote:

So this would be a great way of creating the "consuming" project as it would set up the new project with the framework already embedded?  That's a great pointer, thanks.  

Would that leave the framework in the same location, so future updates/bug fixes could be used, or copy it into the new project's folder structure?  My preference is to be able to maintain the framework in one place and have those changes reflected wherever used - subject to opening the application and recompiling I guess.  

---

Well, Project Templates go in their own location (or the version agnostic location)  what you are calling "Frameworks" are VI Templates and do save in the <LabVIEW\User Data\Frameworks\> folder.  Frameworks are actually things like AF, DQMH, UTF or TSVN TK that interact with the IDE itself.  THEY are not anything a newbie should be looking into yet.....

When you Create New... and get that dialog you actually script out a new vi from a vit (or ctt control template etc...)  that creates one instance of a new vi from the template stored at the time.  Updates to the template vi do not pass to any existing vis (Thankfully!!!)

[andrewDJ]

---

@JÞB wrote:

Well, Project Templates go in their own location (or the version agnostic location)  what you are calling "Frameworks" are VI Templates and do save in the <LabVIEW\User Data\Frameworks\> folder.  Frameworks are actually things like AF, DQMH, UTF or TSVN TK that interact with the IDE itself.  THEY are not anything a newbie should be looking into yet.....

When you Create New... and get that dialog you actually script out a new vi from a vit (or ctt control template etc...)  that creates one instance of a new vi from the template stored at the time.  Updates to the template vi do not pass to any existing vis (Thankfully!!!)

---

I definitely don’t need to interact with the IDE and I agree that I should leave that well alone!  

The framework I’m talking about is made up of circa 50 classes with the only VIs implementing the methods and a few supporting VIs (common routines etc.). There is the example usage VI as well of course but I don’t see that as re-usable per-se, although it could be copied.  So that whole library (as I have it in the original post) needs to be used, with the public facing classes being extended (inherited from), by the consuming project.  I guess I don’t fully understand what you are saying so I think I need to try the template approach and see what happens.  Bit late here so that will have to wait until tomorrow.

[JÞB]

Try starting a New Project from Project Template (right from the getting started window)  LabVIEW ships with several common Project Templates.   Then go through the links in the thread I posted previously.   Those show exactly how to build your own Project Templates.  From what I have read from you.  You will benefit greatly from your own Project Template.

[andrewDJ]

I've given this a go today and have a test template setup and changed the location of \LabVIEW Data\ to a location on a shared drive, so I can easily access these across two computers and update, fix bugs and so on as required.

It works (and why not!!) and I like the approach so thanks for the pointer.  One further question though, related to an original point I raised:

When I create a new project from this template, all the files are copied into the new project's directory.  That means that no bug fixes, changes etc to the framework are reflected into that project (or any previously created project).  If I'm developing a consuming project and find bugs in the framework I have to go fix them in the framework project and then work out how to apply them into (all) copied locations.  

To test this, I made changes to the framework through its project: added a new class and updated an existing class with a property and method.  In the consuming project, I thought it would be a case of right-clicking on the library file and selecting Replace with... reselecting the updated library from the templates directory.  This caused an error telling me it couldn't be done because it was created in a different version of LabView or different OS (I'm paraphrasing a bit here.)  However, the project library was left in an unloaded (??) state: right clicking and selecting Load actually brought in the refreshed version of the library!

This would seem to be a way of rolling out bug changes and updates to consuming projects but given the reported error, I'm wondering if I did something wrong or there is a better way?

[wiebe@CARYA]

It would be near impossible to advice on anything architectural without any knowledge about your use cases.

It seems you're more heading towards a  plug in architecture than a Framework. E.g. .NET framework is just a bunch of libraries playing (reasonably) nice together. That is in fact how I like my application 'framework': a bunch of useful libraries playing (reasonably) nice together.

For instance, I'd prefer a messaging library over a One Size Fits All architecture if I needed 'actors'.

In my experience, architectures (also the ones I made) are either complicated (if they cover 95% of applications) or simple (but cover only 10% of applications). If simple (and specific) works for you, that is perfectly OK. If you like complicated and your applications are covered, that's also OK.

It seems the ultimate architectural goal is to have the exact main VI for every application, while I really like having everything else the same (libraries) and making a custom main for each application. (Of course you'd reuse a main or parts of it, or even make 'templates').

Why make your own architecture? Is it going to be better than AF or (D)QMH? Or is it more dedicated to your needs? Or just learning (pretty sure isn't not best for that, but YMMV)? All non-rhetorical questions 😋.

[JÞB]

---

@andrewDJ wrote:

I've given this a go today and have a test template setup and changed the location of \LabVIEW Data\ to a location on a shared drive, so I can easily access these across two computers and update, fix bugs and so on as required.

It works (and why not!!) and I like the approach so thanks for the pointer.  One further question though, related to an original point I raised:

When I create a new project from this template, all the files are copied into the new project's directory.  That means that no bug fixes, changes etc to the framework are reflected into that project (or any previously created project).  If I'm developing a consuming project and find bugs in the framework I have to go fix them in the framework project and then work out how to apply them into (all) copied locations.  

To test this, I made changes to the framework through its project: added a new class and updated an existing class with a property and method.  In the consuming project, I thought it would be a case of right-clicking on the library file and selecting Replace with... reselecting the updated library from the templates directory.  This caused an error telling me it couldn't be done because it was created in a different version of LabView or different OS (I'm paraphrasing a bit here.)  However, the project library was left in an unloaded (??) state: right clicking and selecting Load actually brought in the refreshed version of the library!

This would seem to be a way of rolling out bug changes and updates to consuming projects but given the reported error, I'm wondering if I did something wrong or there is a better way?

---

That would be a case that cannot be answered well without having a LabVIEW Consultant sitting beside you asking questions and really understanding the whole business situation and anticipating your development process needs.

LabVIEW Consultants are NI Alliance Partners that provide those exact services.   You can search the Alliance Partner directory for Consulting service providers such as 8-Ball Consulting.   (That Jay Thornby is really, really good!)  But, I do not have an availability currently.   Mark Ridgley at Radius Tex... would be my close second choice. 

[wiebe@CARYA]

---

@andrewDJ wrote:

It works (and why not!!) and I like the approach so thanks for the pointer.  One further question though, related to an original point I raised:

---

Why not use source code control for that?

Put a repo on \LabVIEW Data\ and make a local branch (on any PC).

Almost the same effort (slight learning curve) but you'll gain a huge amount option (tracing builds, bugs features, comparing with old versions, etc.).