Programmatic Bookkeeping

[Dyskresiac]

It's cleanup time in my world, and boy are things a mess (as you can see.)  I have inherited a large program from a previous person, and now that I have finished my addition, I'd like to update the names and descriptions of files programatically.  The problem is that the guy before me didn't exactly name or describe any of the files in an intuitively obvious way.  I'd like to update this and keep track of it using an external, generic vi that simply pulls from a reference to the host.

Let me explain.

Some things to note:  1, 2, and 3 are only dependant on A and are all of level k in the hirearchy.  4 is level k as well, but is dependant on B, C, and E.  5 is dependant on B, C, D, and E

=========================================

Task 1:Rename Files Based on Hirearchy:

H_x.vi

A_y.vi

A_z_Blah1.vi

A_i_Blah2.vi

A_j_Blah3.v3

A_k_1.vi

A_k_2.vi

A_k_3.vi

BCE_k_4.vi

BCDE_k_5.vi

==================================

Task 2: Update References to point to newly renamed files.

Ex. During Renaming process.... "File named A.vi is now named A_y.vi"

      After Renaming process.... "Within  H, change VI call to look for A_y.vi instead of A.vi"

===================================

Task 3: Append info to descriptions.

Ex.   A:

ajdoajdamsdlkadm

Called by:  H

Above Caller: None
Dependancies: Blah1, Blah2, Blah 3, 1, 2, 3

1:
djaksajdkjandkjandkad

Called by: Blah3.vi

Above Caller: H, A, Blah1, Blah2, Blah3

Dependancies: None

====================================

Task 4: Import Descriptions to Excel or Database

You get the idea.

=====================================

The actual naming structure is in the works, but from my crude, crude example I hope you can probably see about the direction I'm headed in.  I'm pretty confident in my ability to do most of this, but there's two major snags. 

-Can I obtain the detailed hierarchy to DO such calculations with nothing but a VI reference to its host?  Can I obtain references VIA filename?  I could always simply save the renamed files in a subdirectory.  I guess also using the "List Dependant Files" recursively could work, even that would not account for tier-skipping.  Plus, don't believe that it checks static VI references when you do it that way either.

-Is there a way to actually update references to the respective callers such that I don't need to Browse for every file whose name has changed? 

Any input to improving the process or fixes for my snags would help immensely and be greatly appreciated.  I'm just starting to use VI referencing, so it may be a lot easier than I thought, I just don't know how. 

Thanks Again,

~Andrew

Edit: Also, I WISH my program had that few files.  It has hundreds, most of which are poorly named and incredibly redundant.  4 and 5 in the example above may do the EXACT same thing.  So you can kind of see how A is mine, and the rest is everything I haven't cleaned up yet.  But I'd hate to clean up B, and screw up C, D, and E due to codependancy.  That sort of thing.  So, yeah.  That's why it's worth pursuing a programmatic solution.  It could take weeks to do by hand.

[JackDunaway]

Important question #1 - are all these files in a LabVIEW Project? If so, continue, if not use one! Renaming files within a project is a breeze, because all callers of the file automatically relink to the new destination. By using the project, your Task 2 is rolled into Task 1! 

It seems like you are attempting to script out an automatic file naming tool, and it's likely that unless you're going to be doing this a whole lot in your career, you'll come out way ahead simply renaming them by hand.  It'll take several hours, but writing a tool would take days or weeks!

Get that much done, and then let's move forward with more specific questions.

[F._Schubert]

Task 3: You should be able to do it with VI Server. Only important thing is none of the files you want to edit is running.

Then you can use the property nodes: All Callers and Callees? to obtain the SubVIs and Caller VIs. Also you should have a property node to access the descriptor.

You could either get all VI ref's by recursively browsing the directory or using the call-chain (using Calees property recursively, make sure you eliminate duplicates from the list!).

Task 4:

Following from above, the easiest way would be to write the data to a spreadsheet. Then import the data as csv into Excel.

Felix

[F._Schubert]

To share some more from my experience:

* Creating tools takes you just a couple of hours as long as you keep them private. Without cleaning up, planning for scalability and maintanance, no pretty GUI with Event structure, documentation, neglecting dynamically called vi's... So only you might be able to use them.

* Reworking a project cries for using SCC (to keep track of changes and to be able to revert). But renaming files, moving folders etc. will make it necessary to tell LV how to relink the vi's AND tell the SCC software that they are renamed/moved. Havn't done this yet, but run into issues with SVN when reworking manually.

Felix

[Ben]

I have done similar but not to rename but for other reasons.

First a Q you will have to reslove.

WHen a VI is called from two levels and different hierachies, how does it get name?

That aside.

1) Use VI server to get a list all VI's in memory and save thes since these are not part of your app and you will have to exclude them from teh game.

2) Open a ref to the top level VI and get a list of all its "calllees". Recurse through these until you have a ref to all VIs and including all of the callees.

3) Sort all of those refs top to bottom

4) Use invoke node save as STARTING at the BOTTOM to save the VIs.

5) Close all on the way up and done.

Warning:

Windows has a something like a 256 character limit on path names. Watch out.

Mkae sure you have a complet backup of anyting important since a mistake in the code could be devistating.

Ben

[JackDunaway]

---

@JackDunaway wrote:

It seems like you are attempting to script out an automatic file naming tool... It'll take several hours, but writing a tool would take days or weeks!

---

---

@f. Schubert wrote:

Creating tools takes you just a couple of hours

---

Our conflicting answers are both correct.

If you have written many tools and are familiar with finding the right VI server properties/methods and chaining them together properly, your likelihood of writing a tool and net saving time is greater.

On the other hand, if you've never done so, it will be a great learning opportunity, but it will take days or weeks (depending on previous programming experience) to really get the hang of using references and property nodes. If you've got the time, and you want to learn, go for it!

[Dyskresiac]

Alas, it looks like I had to back out of this for now.  I renamed them by hand.  However, I will still take everyone's advice (and I appreciate it) because it will be something I will most definitely return to.  My temporary solution is to use a Method I found using my 2009 machine called "Find Dependancies" twice, once with Entire Heirarchy= False, one with Entire Heirarchy= TRUE   then recursively finding Dependancies of all of its dependant files.  Then it generated a name list for me, to which I used to manually rename the files in my Project Explorer.  I then simply used Report Generaiton Toolkit to slop together an Excel Database of the files.  However, the only thing that this file takes is a file path.  So it can be applied to other projects.

Ben:  If a function is called from two levels of the heiarchy, it lies in the layer below its lowest caller.  As for the naming, I had really only planned on going one or two levels down.  Beyond there, yeah, it does get messy. 

Jack: you are completely right.  Unfortunately, writing tools is my thing.  Everyone's brain works differently, mine operates using tools.  I call them L99's, as I typically write my files with "Level_" or "L_"  as a pre-name to distinguish how deep they are in the hierarchy.  When function call overhead is not an issue, I have a massive library of seemingly simple tasks that I combine into a subVI just to make things cleaner, then reuse them throughout the program(s).

Another reason I like tools is because while it may make these projects take longer, the ROI is actually not all that bad.  Even if it takes 3 days vs 4 hours... use it 8 times and it has paid for itself.  I know sometimes that option is a luxury that is not always available, so I'd like to make use of the fact that it is. 

Excellent advice though.  It really gives me a lot of ideas on how to go forward, once this project comes back.  I'm going to research some of the things that were mentioned.  Thanks again.

~Andrew