Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 03/26/2013 in all areas

  1. That's the one! Of course the VI just makes a call to a bunch of system DLLs, so I don't think it would work on Linux/Mac/Etc. Ultimately you're really not gaining anything over .NET other than you don't need to deal with it directly. The snippet above probably doesn't require the file/directory info primitive, but I've always used it as such and not found with any trouble. I'd love to play with some scripting or use j's code to have version info in the IDE, but that's so low on the priority list since ultimately the application is always distributed in built form.
    2 points
  2. Has anyone used this for LabVIEW development? Any feedback on this compared to other virtual machines like VMware etc?
    1 point
  3. I think every professional LabVIEW developer should take advantage of virtual machines. Although, I do not recommend running VM's on your primary PC. Some advice/tips: VirtualBox It has fantastic remote desktop support. It is also free. P2V There are a few tools out there that allow you to do a Physical to Virtual conversion. I have used this in the past to convert a "real" machine shipped to a customer into a "virtual machine" that I can fire up at any time for support reasons. Snapshots Allows you to instantly save the "state" of a machine and restore it (while the OS/application is running!) We run a Linux server at my work that hosts multiple VirtualBox machines (one for every version of LabVIEW). Developers access this over RDP. I use these VM's on a daily basis.
    1 point
  4. This post is kind of old, I don't know if JGCode released his project API, so my apologies if this is already somewhere else. I just wanted to add a note here in case someone else tried to use the project API. The tags used in the build specification for the version have changed. JGCode uses inside "Executable Get Version_jgcode_lib_labview_project_api.vi" : App_fileVersion.major App_fileVersion.minor App_fileVersion.patch App_fileVersion.build at least on the version I am working on now (LabVIEW 2012) the tags are: TgtF_fileVersion.major TgtF_fileVersion.minor TgtF_fileVersion.patch TgtF_fileVersion.build Also, this is only useful in development mode, because as MJE showed in this post: http://lavag.org/topic/15473-getting-the-version-of-a-build-from-the-project/?p=93474 you can use that vi to extract the actual exe version at run time.
    1 point
  5. Count me in too. Attached is my LabVIEW Project API, (I've posted bits before). Don't think its ready for prime-time either, but am happy to post as is. Tested only with LV2009 thus far. Cheers -JG jgcode_lib_labview_project_api-2.0.1-1.vip jgcode_rsc_jgcode_library_palette-1.2-1.ogp
    1 point
×
×
  • Create New...

Important Information

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