jgcode

I suggest starting a document in the new knowledge base section - it would definitely suit this use case. You can turn a thread into a document but I would recommend creating a new document that contains links to these posts.

Yes I did. Or, No I didn't (but then have forgotten ) Either way I like it! (unless I forget it again...)

twitter:@lavag

Nice one Jack - this works on the mobile version - excellent!

The ability to programmably interact with layers in 2011+ would be nice too

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.

v1.0.0.27 in the LAVA-CR includes the following features: Following up to mike_nrao's comment I have included a basic example of how to extend a Page and run code in parallel to the engine. To "do stuff" as opposed to just being static: The BD looks like this (from the example): New VIs that allow you to interact with the Framework (wraps dynamic calls). You can set the cursors and enable/disable the Ok button and FP Close X: In the <example> I have included a simple screen to demonstrate what these VIs do: I have added support for horizontal scrollbars. Only vertical scrollbars were supported in the original Framework, but I have extended it to work with both: I have added a Polymorphic API for launching the Dialog. It wraps loading from a folder:

No probs. Please post any examples you do (if you can) - would love to see Don't forget you could always cut and paste the engine code and start from there.

Here is the NI blog post introducing all champions: https://decibel.ni.com/content/groups/labview-champions/blog/2012/02/07/2012-labview-champion-inductees-nine-new-members

Class refnums work as well as some PN and IN but they are very slow and they weren't really designed for RTE.

You can also do this with subVIs

Thanks for the shoutout David (that would explain how Trevor knew about it ) I would love to see more LAVA-CR tools published on the LabVIEW Tools Network - keep em coming guys!!

It looks worse because of Icons and Text view - this is what it looks like as Icons only (in VIPM). I would like to be able to change this is VIPM - if anyone else does too then check out and vote for David's cool idea (and my comment!) on the VIPM Idea Exchange. I don't want to move stuff around too much due to palette inertia - but here is a second attempt for comment:

If its not exposed then I am guessing you would have to loop thru and get all children etc... and save based on type. This would be a pain but would make a great reusable VI. I posted this idea a while ago too that you may be interested in supporting: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Expose-all-available-LabVIEW-Project-Methods-via-VI-Server/idi-p/1156887 Cheers

Copy that. Very much appreciated too :beer:

Sweet!

I don't consider it 'that' big however, am happy to take on board such feedback (which is why I post stuff) - so I will see what I can do. I may move the constant but I will not remove it as Fraswa says - it is not native to LabVIEW and is handy to have.

I am going to make these first class citizens of the lvdata package

My reason for asking that question was to elicit such a response. I am glad you have been able to sort it out using the a Design Pattern. If you do anything cool - please share!

I mentioned that above too. Steve - is there a specific reason you need/want to cast?

Yes, it is easy to download a package e.g. from LAVA-CR from one PC, e.g. USB it, then install it on another PC. If you want to get access to packages on VIPN or LVTN then you need to download in VIPM, then go to the cache (under e.g. ProgramData\JKI\VIPM or something) and copy them out.

That's not exactly true in this case, yes there is a coercion dot but what you now have in run time polymorphism whereby the 'wire' is an array of Parent by the data in that array is still a mixture of Child classes. I don't see the need for the upcast (does it generate an error when it runs?) as you can wire the output straight into the Parent methods and the Child classes and any DD methods of the children will run. If you wanted to use any specific (static) child methods then yes, you would have to convert the Parent 'wire' to the Child. You should check out the Factory Pattern.

I pre-booked the shuttle as it was a bit cheaper than taxi.

With respect to the Community (I can't see it being used anywhere else) I have seen EK use it in an example with LVOOP design patterns - that was a first as far as I know.

There is a new, small and simple KB on LVOOP patterns that (new) developers may find interesting http://bit.ly/zJEud2 This links back to the main Community page on LVOOP DP's.