jgcode

twitter:@lavag

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

If the Icon Editor persisted the layer information to the clipboard when you copied, then it wouldn't necessarily be a waste of time, but that's never been implemented in any of the icon editor plugins that I've seen.

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:

<update>

You already answered my question above I think where you said 'Also I envisage that you could run the Engine in parallel with other code'. I see now that it's possible.

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

I was under the impression (from a post somewhere by AQ) that lvclass references work in run-time as of 2010.

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!!

Man, that is a massive palette. Why does the it have its own version of the variant constant? If you eliminated that, you could condense it to a more reasonable 5x5.

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:

Hi scripting people.

I couldn't find a way to script "Project->Save All". Can anyone offer some guidance to achieve this?

Thanks and best regards, Miha

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

Hold off on finalizing this until the end of the week, please. I'm asking compiler folks to investigate the performance gain of adding the output terminal to see if there's another way to get that gain OR if it could at least be made unnecessary in LV 2012. Since this affects the conpane of the VIs, and that would be hard to remove in the future, it would be better to publish without it.

If you don't hear from me by the end of this week, ping me, please.

Copy that.

Very much appreciated too :beer:

Sweet!

Man, that is a massive palette. Why does the it have its own version of the variant constant? If you eliminated that, you could condense it to a more reasonable 5x5.

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

Because I need to keep the state of the parent for each call to the dynamic VIs. Something similar to this:

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 think most of our confusion (well, mine at least)...

I mentioned that above too.

Steve - is there a specific reason you need/want to cast?

We develop a number of test systems for use in China at our production facility and when we ship it for whichever engineer is on site at the time to debug. Now because the PXI racks that are used may well have been bought in China we can not guarantee that the PXI rack will all the required software and drivers so we make sure that any software or drivers are included in the package we send as as access to the internet can be tricky or just so slow as to be unusable.

The question is that we a number of components that we install from the VIPM but that is not allays possible via the internet in China, is there a way to download the installer files and then use them locally on the PXI rack on site.

My thanks in advance.

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.

Arrays have to be of a single type. The child classes get coerced to the parent since that is the only type for which they are all compatable to exist as a single type within the array (and why you have coercion dots).

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.

...the only answers I know of are rent a car, phone a friend or call a taxi.

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

Would NI let you use it?

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.

Interesting, thanks for pointing that out, I'll have to look into it. I expect supplying a stylesheet URL might simply insert a processing instruction into the prolog of the document?

<?xml-stylesheet type="text/xsl" href="path.xsl"?>

[/CODE]

I'll have to download Easy XML to check it out I suppose.

That would be my guess - that it just inserts the XML declaration.

mje - if you can, in the future, please update this thread with code that you implement - that would be really sweet.

Jealous?

Definitely

Maybe next year you can join us for both and for NI Week

Hmm 2013. The '13' doesn't sit well with me. If they name it 2012b I am in!