Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 07/14/2024 in all areas

  1. I was fairly sure that there was actually an application event for file open events passed from the OS to the running application, but seem to have dreamed that up. It shouldn't be to difficult to add although might have some implications. Would have to be a filter event that can check the file name and then indicates if LabVIEW should further handle it (for LabVIEW known file types), or if it should be ignored (potentially handling it yourself). Ahh, it's super secret private special stuff: And seems to have trouble in some newer versions than 8.2! Although Ton says he got it to work in 2009 again.
    1 point
  2. That sounds like the LabVIEW Solution Builder, which I use. It works quite well.
    1 point
  3. Not sure about 2011 to be honest, but no you do not have to have all dependencies included in a PPL. You can have a PPL depend on other PPLs and configure the build to exclude that dependency from you PPL build, so that it remains external. This has of course to be down from bottom up, which is quite a work. Only PPL dependencies and other binary dependencies can be excluded from being pulled into a PPL. So if you want code that has to be shared between your PPL and other PPLs or your exe, that code needs to be in its own PPL, so each of those can refer to it. Yes it is not trivial and you need to plan before you start programming. You need to have a clear hierarchy overview and be able to cleanly modularize your code into different PPLs. Tools like the MGI Solution Builder definitely help with that as you can script the creation of a whole hierarchy of PPLs to be compiled in the correct order. Someone from NI was busy creating another solution that could build PPLs and in the process of building them also relink any dependencies on lvlib's into dependencies of lvlibp's but that didn't quite finish.
    1 point
  4. Now I don't think it is completely fair to take what someone said during a presentation, and quote them out of context. But I just love this from Darren's presentation: If NI had a replacement for Project Providers that was documented and stable and all that, then I won't suggest anyone make a Project Provider plugin. Until then I say there is a time and place for them, just knowing the edge cases, documentation, and support issues. I think Darren's presentation does a good job of cautioning others.
    1 point
×
×
  • Create New...

Important Information

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