Jump to content

dcoons

Members
  • Content Count

    9
  • Joined

  • Last visited

Community Reputation

0

About dcoons

  • Rank
    LAVA groupie

LabVIEW Information

  • Version
    LabVIEW 2018
  • Since
    2007

Contact Methods

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Looks like this is what I need - here is updated project with some implementation to prove it out. Thanks @Darren Example Project.zip
  2. Here is an example project to entice you more. Template gets copied, library gets renamed, a few edits to the PPL build, and then I need to edit the installer. I am pretty sure I can use the tags like below - but I know that isn't the best way to do this. Example Project.zip
  3. Has anyone used the functions located in vi.lib to programmatically edit Installer build specifications? I have used the functions in AB_API to edit Packed Project Library build specifications (in PPL subfolder) but cannot find anything equivalent for Installers. The classes in this hierarchy inherit from NI_AB_API_Build.lvclass which has a generic open method, but installer is not in the list of selectable build types to open. I also found IB_Classes subfolder which has functions for interacting with Installers maybe, but there's no clear function to open an Installer build specification
  4. As an update, here is an example code project demonstrating to a minimal degree what I am trying to accomplish. In this case the VIPM package will go to user.lib, but the same issue still applies. (Also, I made a .vip file, but you can just take the built packed library and put it into user.lib instead of using the package and it will still demonstrate the issues) -Common Code has a reuse function I want to use and it is built into a packed library -Parent defines a parent class that uses a function from common code and is built into a packed library -Child class inherits from
  5. The Limits.lvlibp stays Not Loaded even when Controls.lvlibp is added to the project. It doesn't make anything worse, just doesn't change anything.
  6. Inspired by my question from this post: link, I started off on a path of packaging project dependencies into vi.lib as suggested by @smithd and @Darren however I have started down a rabbit hole of packed project library (ppl, *.lvlibp) head scratchers that have left me a little confused on what is going on in the background. Most of my components are built into packed libraries because I am following plugin models for extensibility when building as an EXE. To make packed libraries work with dependencies, you basically have to build those into packed libraries as well to avoid the namespace i
  7. I think I am comfortable with the idea of creating packages and putting into vi.lib - that is a good idea except there is one dependency library that is a little different. The one that I am not sure about is a plug-in type that loads the correct child plug-in based on the configuration file for the application. So for that one I would still need to do a little directory trickery. I will do a little playing around and see what I can get to work (and I will try to remember to reply back with how I handled it).
  8. For a lot of my LabVIEW projects, I have been developing scripting tools to help team members get to a good starting point for their code or to remove human error when following templates. After seeing Becky Linton's presentation at NI Week in 2016 (link), I was inspired to use Project Templates to make it a little easier for the developers to get to. I have been able to get it to work to varying degrees at this point, but I have a question on how to handle project-specific dependencies. If I have a team working on a larger development project that has shared core code and we have it in
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.