Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 02/22/2013 in all areas

  1. Hi all, First time poster. I have been trying to create a new class in LV via scripting. I can successfully create the class, and add private data members to that class. However, when I try to creat accessor methods the unbundle feature is broken. I can fix this by opening the priavte data control and saving it. Any ideas how to fix this problem? I have attached my code. I have tried saving the control a number of ways, as well as the class, but can't seem to make it work. Thanks for any insight. Let me know if you have any questions. Chris Class Wizard.zip
    1 point
  2. This sounds like you need to ensure that the Math Kernel Libraries are included into your installer. Specifically, if you have downloaded the full RTE to your computer and run the self-extracting archive, it's the MSIs at the location: C:National Instruments DownloadsLabVIEW Run-Time Engine2012 (32-bit) f3ProductsMKL_2012 It's often possible to include only segments of the RTE without requiring the 200MB+ footprint; in this case, I think it's MKL for ya. Hope this helps!
    1 point
  3. I'm pretty sure that the default color depth for the method is 8 bits, so you get a limited palette. Try using 24 bits.
    1 point
  4. According to Darren it's InternalPaletteEdit=True. However I would back up your <LabVIEW>menus directory first in case you want to revert.
    1 point
  5. This site is not about Lava, but something else called LabVIEW. I would start with the Lava site - http://lavape.sourceforge.net/index.htm By the way, if you're going to be software engineers, you should definitely be able to do that much on your own.
    1 point
  6. I really like this thread, as this is an area I am always trying to improve. I used to write config files like this (bar the input into class just output a cluster, esp for <2009 RT apps): The only thing I can add is that I found it easier using an enum as the key due to typos, esp when the number of keys get large, but that was just personal preference. Where variants can be used, I prefer to leverage existing APIs (such as OpenG) as it just so much less work to read and write to disk and extends the LabVIEW Config API by supporting other datatypes (e.g. arrays). Here is how I do configs with LVOOP. Mentioned in other threads I like to write the Object's private data to disk from within the Object. The data that is required to be persisted is stored in a non-typedef cluster. I usually end up having reusable Objects, application Objects (including general Config Objects) that I want to flatten to disk. These can be basic Objects, extended Objects, MFVIs/modules, arrays of Objects and Objects composed of other Objects - I am able to do this albeit there is a little more work for the last two. Typically I like to use a single ini file (as I like the format). I'll use a simple application as an example Here is the startup code for the application, it is quite simple and contains reuse modules (the purple banner object extends the blue banner object): Inside the second VI from the left (curves settings constructor) the structure of the file is setup (header, sections): When the Read VI (reuse) is called in the startup (third VI from the left) it performs checks, reads the header (meta data) and then the section data The section data is an override VI which extends the base case and is custom for every application. It calls the Object's read to disk method The reading is delegated to a File Interface (reuse) Object (not shown) which has a variant interface - it may not be the best interface but I found this was the easiest way for reuse. In the base implementation it uses OpenG ini format (abstracted under a few layers) as this is my preferred approach plus you can't really have abstracted Classes in LabVIEW etc... In the end this is what the file looks like, and it is minimal effort to create using the reuse modules: Additionally I can support versioning if required for that application in the future.
    1 point
  7. Thats what the MCL should be as a control (your picture) without us having to jump through hoops and use hacks to emulate proper controls.. It's about time NI stopped faffing with blue sky stuff and put more effort into the core stuff that's been needing development for the last 5 years that everybody uses (controls, events, installer, more integrated source control support (svn, mercurial) .... et al.)
    1 point
  8. I've managed this. It deleted 100 files in only a few seconds (and put them in the Recycle Bin).
    1 point
×
×
  • Create New...

Important Information

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