Jump to content

ColinR

Members
  • Content Count

    18
  • Joined

  • Last visited

  • Days Won

    1

ColinR last won the day on November 20 2014

ColinR had the most liked content!

Community Reputation

1 Neutral
  1. The issue and its cause: Library A would not build. Library A had dependencies on Library B. This was not a problem for previous builds, and is not ultimately a problem. Library B had a recently introduced dependency on Library A. This was not intentional, and I'm not clear that this sort of interdependency /should/ be a problem, but it is. Putting the dependent Library B into its own project to observe dependencies and eliminating the recursive dependency on Library A fixed the problem. The moral of the story, don't build a library that has dependencies on another library that itself has dependencies on the build library. This causes the 'VI already open' error observed in the original post. Thanks Jim for helping me to resolve this issue. Regards, Colin
  2. Indeed. It has been two weeks with no resolution. Fortunately, I was able to move a vi that was apparently causing problems into the only library that actually needed it, which allowed me to build my package for my customer. I still have, however a library that has been updated that I cannot package. I have four libraries waiting for release because this will not build and they are interdependent. I have tried rebuilding the library, project, and vi from scratch with no satisfactory solution. I have been informed that JKI has been able to rebuild the library from source, yet received no suggestions for what I can do to resolve the issue on my end. I have tried reinstall of the version of LV and VIPM that I'm using with still no success. The only thing different is the installation of another version of LV on the same computer, which I suppose could potentially cause linking from another vi.lib, which would line up with some sort of crosslinking issue across versions, but I've nothing in my dependencies outside of vi.lib. I do have links in several vis to vis in other libraries it depends on, but this is a requirement for my application and a very basic feature requirement: the point of being able to specify dependencies is that there are dependencies on other installed libraries. Colin
  3. Hello, VIPM 2014, LV2012. VIPM builds are aborting due to library vis that it claims are open. This occurs with multiple libraries that were previously successful. LabVIEW is closed prior to build attempt. Mass compile on all files prior to build is error-free. Things I have tried: Restart, deletion of AppData temp files VIPM reinstall Removal and reinsertion of vis from library Open and close of vis outside of library Thanks, Colin
  4. Found my stupid error. You must specify the licensed library path AND the license file path. Please delete me.
  5. I've since discovered that I delete the license on the machine that generates the licensed code and attempt to regenerate it, it now generates an invalid license. I imagine that this is the problem, and that VIPM simply doesn't transfer and invalid license C
  6. Hello, I seem to be having the problem that a license file is not being included on install, and as a result the licensing status comes up as "invalid". I have deleted the licensed directory and regenerated it using the add-ons toolkit, activated, and created a package successfully. The package then installs without problems, but the license file just doesn't show up. Is there an obvious reason for this? Thanks, C
  7. I believe so, yes. Through this and other sources, however, it seems the only options for licensing executables (outside of LV) involve another pay-to-play software package. Thanks, Colin
  8. Thanks! This is perfect. I understand about vis in the Start Menu, however if it's a fully built app that you include in a tookit with a library and API, they're two different things being bundled in the same package. So, for example, if I built a standalone app that is protected and packaged it with a library, as a user I'd be able to run the app without LabVIEW. I understand this is not the problem I posed, but another relevant one. As for expectations, I've never downloaded anything and run it from the Tools menu, so that's likely more a function of all the different ways people use LabVIEW. I've downloaded libraries and used them from where I put them or used installer packages that put my app in the start menu. Colin
  9. Best idea I have so far is to create a folder in the start menu and make shortcuts to those vis. Best way to do this vis VIPM? C
  10. Hi. I've got a couple tools libraries with utility and high-level applications built using the library vis that operate as standalone apps. These don't seem to be best included as members of a palette. Rather, if the user had a shortcut or a place in a user-specified folder to execute them from, that would probably work best. I prefer, for example, to simply open the library and use the utility vis and top-level vis as I need them. Now, I could see where if they were all stand-alone executables, you could just run an installer after the library was installed. If, however, I want to have a standalone vi with a user-viewable/editable block diagram, this would not be the best approach. So, how do I include top-level application vis with my API to make it easiest for the user to employ and install? Thanks, Colin
  11. Windows 7 64-bit, updated as patches available. LV 2012 12.0f2 32-bit. VIPM 12.0.0 build 1780 Note unchecking 'read-only' was insufficient. Advanced options and granting full control solved issue. Granted full control to all users to fix, so unsure whether a subgroup would have solved the issue. C
  12. I finally got around this by manually modifying the file permissions of the vipb file. There must be an issue with a bad exit affecting permissions. I would guess that VIPM should have a way of unlocking the file by determining whether it's actually being used or not.
  13. Hello. I periodically get the message "VIPM was unable to save your package settings. Please ensure that you have write privileges to every file in ... " where ... is the licensed library directory. If I make another vipb file from scratch, it works fine. If I delete the directory and try to use the same vipb file, it does not. This is quite frustrating, as I have to go in and redo all of the icons and hierarchy settings. I've tried running VIPM as administrator, no dice. It appears to be a problem with the vipb file itself. Ideas? Thanks, Colin
  14. Got it sorted. Had a project in a subfolder that called the library itself. I would think that LV would figure out this structure problem, but no. Anyway, all better. Thanks. C
  15. Thanks. I'll try building it piecewise. Do you happen to know if it's possible to build VIs with dll function calls without including the dll?
×
×
  • Create New...

Important Information

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