Jump to content

WhiteFang

Members
  • Content Count

    4
  • Joined

  • Last visited

Community Reputation

0 Neutral
  1. So a near ideal fix was to create a pre-build custom action VI using VIPM. This VI searches the list of source-files looking for VI "files named anything at all Version String more anything.VI" using this regex expression. .*?(?=[Vv]ersion [Ss]tring).+?(?=(\.[Vv][Ii])$) If found, Open VI Reference is used along with 'method: Control Value.Set' and 'method: Default Values.Make Current Default' followed by 'method: Save.Instrument' (then close reference). There is a one-time setup required to create (or rename) the string indicator(s) with appropriate name(s), but afterwards, this does the trick for me. I could extend it as needed, including (with a lot more work) to automatically create (from template) a Version String VI if it is missing, and then (somehow?) add it to the template prior to the build.. I attached a simple example saved in LV2012. Hope this helps someone, and if you extend it to create the file (if missing) I would appreciate it if you shared the improved version back to the forum. Pre-Build Custom Actions (LV2012).vi
  2. Hi Brian, thank you for coming up with a fix for this, I hope this fix (or a fix) gets built into the next VIPM update. -Perhaps a JKI rep' could comment on this in the thread?
  3. Hi, So I have a large number of code modules or packages that we leverage to manage code re-use. We use the VIPM 'Display Information' with 'Edit All VI Descriptions' checked and we add the following to all VI descriptions: ----------- {product_name} <b>{version_number}</b> {author_name} - {company_name} {copyright} Now, as a legacy, several of our modules would have a VI-constant containing nothing but a string constant and a string indicator wired to the constant. The constant would have our product name and/or version#. The problem is that this is all manually maintained, which is less than ideal. So, we wrote a new 'brat' (VI that acts on or affects the calling parent(s) without any inputs) that would get the calling parent's VI description and using a couple of simple reg-ex's it would parse out the {product_name} and the {version_number} and return it to the caller. Presto, now our code could self-report their current package name and version! The problem we have is that this does not work for RT targets (error 56, Manager call not supported). What to do now? -We could do a VIPM 'pre/post build actions' and before the package is built, run a VI that prompts for the location of the 'version constant' VI and opens/edits the constant value, but I don't know how/if my pre-build action VI would be able to automatically get package name and version from VIPM. We probably could run a post build action, and get it from the VI description using a modification of our existing brat, but I'm not sure again how editing post build VI's would work out.. Is the post build VI run before the VI's are sucked into the 'zip' package? where are the VI's temporarily stored? My goal would be to not have any manual input at all to this step, for example by standardizing on the file-name of the 'constant version string.vi' and using scripting to edit the BD constant prior to build completing. I'm wondering if anyone has done something similar already and/or could help me get started in the right direction. Thanks! PS where are the moderators? why are there 'topics' about viagra on your forum's that are not deleted?)
  4. I HAD the same issue, including the article linked not working for me. For me, for whatever reason, the fix was to enter my local Computer Name in the LabVIEW Machine Access dialog. NOTE: Using * or my PC IP address (Static or otherwise) did NOT work. The only thing that worked for me was to enter it by name. To find your Computer Name, in Windows 7, right click the 'my computer' shortcut and pick properties OR go to Control Panel-->All Control Panel Items-->System Look for 'Computer Name:' and type what you see there into the 'Machine Access List'. Not sure why it would behave this way, but there it is.
×
×
  • Create New...

Important Information

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