Jump to content

vugie

Members
  • Content Count

    7
  • Joined

  • Last visited

Community Reputation

0 Neutral

Profile Information

  • Gender
    Male
  1. New version didn't help, but I found the reason - in fact there was a VI saved for 2009, but in folder excluded from build... Bug or feature?
  2. Just a though - there are CLF nodes in my VIs, which has just "LabVIEW" for library paths. Maybe this is it.
  3. Hi I tried switching off 2009. Even after deleting .vipb file and redefining the package for 8.2 (no other version registered) following error appears: No new file in error directory. I also tried to do it on independent computer - same effect. Another thing I tried was to manually change version number spec file in vip archive (generated for 2009), and to replace all VIs to proper version. It was not possible to install such a package. My main suspection is that LV version is somehow sewed in the package ID. Is it true?
  4. I have two LabVIEW versions on disk: 8.2 and 2009. I wanted to build packed for 8.2, but something went wrong and error appeared - I don't remember now what was it. I quit all LV versions, restarted VIPM and tried again, but from this point when I try to build package for 8.2, LabVIEW 2009 starts instead and package built (without any errors) is for 2009. I of course selected proper version while defining package content. So what is going on? In package definition (attached) version is stated properly. .vipb
  5. Thanks, works and sings. What was the direct reason? The case with lvclass in lvlib is definitely sth LabVIEW does not like (vide issue with palettes). So, only LAVA is not working as for now... Oh no, not again!
  6. I wanted to make a package of lvODE library I just published on LAVA. Here is the link for source: http://lavag.org/files/file/155-lvode-01-lv2009/, VIPB file is attached below. .vipb
  7. Hi I have exactly the same problem. I want to build package of lvlib with number of classes referring to total of two DLLs. To one of this DLLs I refer directly, to second one not only directly, but also by getting function addresses using kernel32.dll calls. The error log is essentially the same as Dave's one.
×
×
  • Create New...

Important Information

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