Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral
  1. I noticed the standalone? boolean control in the Easy Write XML File.vi and read its description: Standalone? specifies the value for the standalone attribute in the XML declaration. Standalone? determines whether the document exists entirely on its own (TRUE), or depends on other files (FALSE). but I'm not clear what having the standalone attribute set to 'no' in the XML declaration means. I searched around jki.net and didn't find any discussion and then searched google to find www.w3.org/TR/REC-xml/#sec-rmd. Decided I'd never grok that! Guess my question becomes; what is the use case that a JKI EasyXML Toolkit user would use the FALSE value of this control?
  2. I've experienced that - in my case, I had some vis (and ctls, oops) that were not under the directory in which I was trying to build a package. I was packaging up some old code, and didn't realize it reached out to so many other directories. Good Luck!
  3. I have a small package with no dependencies. (Why are you snickering?) Anyway, on the Dependencies tab, I don't have any listed dependencies. I have a hard time remembering if that is true or if I just haven't run the scan to check yet. Could something (like last scanned "04-09 blah blah" text) let me know that I have checked?
  4. All this sounds quite useful. I've been using the dialog box that asks me if "like to apply changes to my package icons" as a sign I should probably check the dependencies too. Yes, I think it would be good to Scan for Dependencies at those times. Plus, I think there should be a Scan for Dependencies before the build of your package. Hmmm, [complete tangent warning] perhaps the Dependencies tab could do something like what happens in the main VIPM window icons, when a new version of a package is available. Provide some indication that the dependency is not using the latest version of the package. This difference could be correct (intended by the developer) or indicate that the dependencies are out of sync. Perhaps then all these auto scans aren't really as necessary? The developer controls when scans happen. cbl
  5. I have a bad memory [and my apologies if I've already mentioned this ]. I keep forgetting to update my package dependencies before I re-build my package. As a result, on a lab machine where I have several packages 'deployed', I kind of messed myself up. I know if I remembered to update my project vipc file, I could've avoided this. So I'm going to try to remember update dependencies on package re-build, but could the VIPB help me remember? Or maybe optionally update the dependencies when the package is rebuilt? Cheers
  6. Thanks for the template JKI, great to see how others solve reoccurring problems in LabVIEW. And thanks for sharing. The fact that the error handling is built into the template, is just one of the many items that strikes me as quite useful. A situation I come across frequently wrt errors in this kind of pattern involves running Macros, or any multiple state activity. The template currently goes to the error handler case, displays the error, clears the error and then continues on running the remaining steps, starting with the error cleared. Sometimes this is exactly the behaviour I need, but sometimes I want to complete the remaining states but let them know an error happened, and mostly I just want to abort the remaining states (clear out the queue - since running them no longer makes sense due to an error). Do you at JKI or do others run into this, and if so what approach(es) do you take to manage the different ways of operating? I can think of several ways to *change* this (well I think I've got at least three different ways I do it!), but would like discuss this so I can select an approach that is *more preferred* or at least results from more of a consensus. And like you indicate in your template, I may have some Post error work I always want to complete. That is handled nicely in the template. Cheers!
  • Create New...

Important Information

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