Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 03/15/2014 in all areas

  1. That sounds like too much hard work - lol You can bulk mark VIs through the project's options or you can use VI Server and script it I tried this feature out recently and liked developing with it One thing I concluded with tho is that if I ship a tool (essentially a source code dist) I want to install compiled code with it Otherwise the tool needs to be compiled for use in its native version of LabVIEW VIPM can do this on install, or the tool can also recompile itself, but IMHO it makes for a better UX (quicker install and first launch) This was easily achieved using VI Server
    1 point
  2. Hi, I'm working on a build server to be launched from Jenkins and a plugin to smooth the use of Jenkins with LabVIEW. I hope to post some results soon! One problem I am having. I wanted to distribute the build server as source code as it will enable additional features in the development environment over a built EXE. To aid the process, rather than distributing multiple versions and have to create a new distribution for every version. The problem with this is that when it tries to exit, unless it is in the version it was created in (2011) it prompts for a save. I'm sure I saw some option somewhere to sliently close LabVIEW without a save dialog but cannot find it anywhere! Was I dreaming or is there something in Scripting/Super Secret Stuff which could do this? Cheers, Mac
    1 point
  3. Just to expand on lvbs points. If you build source plugins. i.e. plugins with diagrams so they can be recompiled on the target system when invoked from an executable. Then you must turn off compiled code separation for that VI otherwise you will get the Error 59: “The source file’s compiled code has been separated, and this version of LabVIEW does not have access to separated compiled code. And just to reiterate a point that some people often forget. The global compiled code option only applies for "New Files" so checking it won't change all the existing files to use this method. You have to go and change each VIs setting individually and recompile. DISCLAIMER: The above are not "issues" as such. Just additional things that you have to bear in mind when using the option and may fit into the the grannys' eggs category.
    1 point
  4. Separated compiled code has been working well for our team over the last 3 years. There are two instances where we encountered issues: Packed Project Library build corrupting the VI Object CacheThe VI Object cache had to be cleared after PPL builds [*]TestStand with the LabVIEW Run-Time adapter requires uni-file code if distributed as source -Brian
    1 point
  5. I jumped into the middle of two projects and converted them to subversion (I miss Hg!) and "separate". No discernible issues.
    1 point
  6. We have created a free licence key that unlocks Symbio's version of GDS in case people still like to use that: GOOP-GOOP-GOOP-GOOP-GOOP Cheers, Mike
    1 point
×
×
  • Create New...

Important Information

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