ABAPI Examples 2013.zip

[Wire_Warrior]

Perhaps this is a bit simplistic approach but couldn't you just copy the build script manually and then change the one parameter (or more I suppose if you wanted) in the IDE.  Then you could wrap the ABAPI in a VI that allowed you to select your build that way.

Wire Warrior

[smithd]

That will all definitely work. However, the specific thing I am trying to build is a script to automatically generate multi-target builds for plugins to a system. Its not necessarily something hard to generate in the first place, its just nice to have script so that if my dependencies (and thus "always excluded" files) change, I can just rescript everything in a few seconds. It also means anyone making a new plugin will always have the "correct" build specification. Sounds like will not be possible (without using another mechanism).

[Daklu]

More noob scripting questions...

We have a fairly complex sbRIO source distribution deployment with lots of shared code (including vi.lib and RT/vi.lib) so my build script needs to create a new project and, after the top level vis are added, automatically add all dependencies (even those in vi.lib and RT/vi.lib) and set them to a specific destination.

The problem I'm running into is obtaining a reliable list of dependencies and adding them to the project at the correct location.  Right now I'm using the 'Get VI Dependencies' method to obtain the paths to the dependencies, and I'm seeing some unexpected behavior.

The first problem is occasionally the path to a dependent vi will be duplicated with the addition of "\0" to the end.  For example, I might see two items like this:

c:\scc\MyProject\src\PlainVanilla.vi

c:\scc\MyProject\src\PlainVanilla.vi\0

That looks like a clone to me, but I have no idea why the method would return clones.  I have that option set to 'Include original reentrant vi instead of the clone vi."  On top of that, some of the vis aren't reentrant, and some are dynamically reentrant, so it's not clear to me why there would be clones of these vis anyway.

I'm removing those paths from the list of files added to my project.  Q1: Is there any reason *not* including clones in the build spec would screw up my build?

The second problem is I need to get ProjectItem reference to each file in the list of dependencies.  To do that I'm using AB_API Get Project Item Reference.vi, similar to how Darren is using it in the example code.  Unfortunately, nearly half of the dependencies are being returned with the ProjectItem reference not found, and since I've start using that vi I've been getting a perpetual error somewhere from the bowels of the system:

This error is occurring when my build script is paused and I try to view the project my script is using.  It usually ends up crashing Labview or locking it up hard.

Previously I had tried getting the project items by opening the top level vis and calling 'Get All Descendents' on the Dependency project item.  Unfortunately opening the top level vis didn't cause the Dependencies section to get populated.

Q2:  What are my other options for getting a list of a project's dependencies' Project Items?

[rolfk]

I don't think clones use a backslash in the name. That rather looks like escaping which would mean that the path has for some reasons a NULL char appended. Why it would do that I'm not sure but a simple equals comparison to filter out duplicate paths before returning them would certainly not recognize these as equal paths.

[Darren]

I took a look at the diagram of AB_API Get Project Item Reference.vi. It doesn't do the best job of closing references...I don't know if that could be the cause of the 1055 error, but it wouldn't hurt to try a more robust version of the VI. I have posted one here. It is saved in LabVIEW 2013, no password, and it closes all the ProjectItem references it opens:

https://decibel.ni.com/content/docs/DOC-36260

As for the \0 at the end of your dependencies paths, I have never seen that before. I'll see if I can get the author of that method to come take a look at this thread.

[Daklu]

Yeah, what I ended up doing for filtering was checking the file extension.  If it wasn't vi, ctl, etc. I discarded it.  In any event, "Get VI Dependencies" wasn't working very well for me so I went back to try and pull the dependencies directly from the project window.

I was able to figure out how to populate the Dependencies folder.  It turns out...

Even though opening the vi causes all the dependencies to load, they don't show up in the Dependencies folder.  With VIReference, I don't even have to do anything with the reference.  Asking for it is enough to populate the folder. 

There is probably a reasonable explanation for this behavior... anyone know what it is?

[Darren]

Daklu wrote:

There is probably a reasonable explanation for this behavior... anyone know what it is?

                   

I don't know for sure, but my best guess is that, since you don't have an "application reference" wired to Open VI Reference, then the VI is being opened in whatever application instance your scripting code is running in. But when reading the VIReference property, the VI is opened in the appropriate application instance (i.e., the appropriate target) under the project.

[Daklu]

You are right... that is a reasonable explanation.  (I had a Doh! moment when I read it.)  Oddly though, it doesn't appear to be the correct explanation.  The dependencies still didn't show up after I wired in the app reference for my build project.  Go figure...

I tried out the version of AB_API Get Project Item Reference.vi you posted, and it appears to have solved the problem with the errors.  It turns out removing the bad items (\0) from the dependency list requires more than just a simple filter.  I can't discard items without file extensions because several vis and controls in NI's libraries do not have file extensions.  (The internet toolkit is chock full of them.)

I'm not sure I'll end up using the 'Get VI Dependencies' node anyway.  That method returns just under 700 vis, while grabbing the vis from the dependency folder after acquiring a vi reference gains me on the order of 2500.  Any idea why the difference?  (Nearly all the filters are turned off for Get VI Dependencies, and I collect any owning .lvlib and .lvclass files the vis belong to.  The lists should be very similar.)

The big problem I'm running into at the moment is all my builds are failing due to invalid characters in the filename, and it seems the build engine isn't smart enough to rename them.  (Thanks again Internet Toolkit.)

I ran into about half a dozen files with this problem.  Most of them I have project items reference for, so I just change the invalid characters to something else.  But even when I use the VI Reference to get 2500 dependencies, it doesn't pick up all the dependencies.  ('Not An HTTP Session?' is one of them.)  After my build script is done the dependencies section is empty, as it should be.  If I open up the front panel of my top level vi several hundred more items will appear in dependencies, including 'Not An HTTP Session?'

I sure wish Labview was more transparent about what is loaded and what isn't.

[Daklu]

Daklu wrote:

If I open up the front panel of my top level vi several hundred more items will appear in dependencies, including 'Not An HTTP Session?'

After posting this I figured, "why don't I just open up the front panel via scripting prior to adding the dependencies?"  Easy enough to do, but it doesn't work.  When the script finishes I still get the same error and the dependencies section is empty.  Those extra dependencies don't show up in the project until I manually close front panel window and reopen it.

At this point it looks like I'm dead in the water.  I can't build the project at all because of the invalid characters in the file name, and I can't acquire all the project item references I need to set up the build correctly.

Any ideas?

[Darren]

I just talked to one of our App Builder experts here. Since the files with invalid names are dependencies, the only way to build without the invalid file name error is to set a custom destination (that is an LLB) for those dependencies. If you move the internet toolkit files out of Dependencies and into your project, then you have the additional option of renaming them as part of the build.

As for acquiring all the project item references, have you tried using this VI (also discussed in the hidden gems presentation):

vi.lib\Utility\EditLVProj\Open References To All Libraries And VIs In Project.vi

I have definitely seen weirdness in the past with how the Dependencies node in the project gets populated. I would hope that this VI would truly retrieve all project contents (including dependencies), since I depend (haha) on that behavior from this VI in some of my code.