jgcode

From what I read, the OP wants to override parent data (which is not available in the child by LVOOP design). Yes that is correct. You may or may want to call it constructor (as LVOOP has no constructor) the constructor is always the Class.ctl if you will. You cannot force this operation and restrict the use of the Class.ctl as you have to use it subVI boundaries, as part of datatypes, as default value etc... IMHO I don't think this is the best approach to learning - you should try stuff anyways and form your own decision, then provide feedback back to LAVA to continue the learning cycle

Sure you can - check out the video Create Constructor From Template here, that is the style I like to use. Just set the parent accessors in that VI with the default data (from constants etc...) then call this VI instead of dropping of e.g. a Class Constant on the BD. Cheers -JG

This package exposes the Variant Data Type Library palette if anyone is interested. Cheers -JG

There is an OpenG package that installs this option. It wasn't there by default in 2009, Yair says it should be here, I can't check 2010 as I don't have it installed on this laptop. Cheers -JG

You are welcome, my friend

A valid idea but I don't think it is related at all to this discussion. Even if NI 'owned' the package (or whatever) building and distribution software you would still have the same discussion happening. JKI have done a fantastic job with VIPM, provide a very high level of support and have made package building available to everyone as, as of VIPM 2010 it is available in the Community Edition.

I am using the IPB app for iphone. Maybe check their website for other OS'. http://www.invisionpower.com/products/board/

I don't see a link to the cross thread anywhere (but I may of missed it) I have been following both, you can check it out here: https://decibel.ni.com/content/docs/DOC-15014#comment-17129 Val - I am not sure from ur comment above about 'Crelf moving threads to here' - did u post on the cross thread? If so what is your alias? Cheers -JG

I have found that this setting can 'fix' the issue I.e. Broken VIs are not longer broken. As it must be different to the Run Time Environment.

Could be the phone or the app, I seem to get a lag scrolling on NI's forum too today. Anyways, I dig the change - very 'fresh'.

I have had issues with Classes before and the way I debugged the build was by doing the following: Create a new VI and drop a class constant on the BD. Create a new build spec for this VI. Cycle through checking all Classes until you find an issue. Sometimes it's been a 'dirty' VI I just cut and pasted into a new one that fixed it, other times it's been some run time environment issue (e.g. with X control). Sometimes with I have gotten a better error message from LabVIEW too using this method. If you have hierarchy of Classes (e.g. composition) you can find the issue and work down. Either way, if you track down the issue please post it.

A fridge fell on my head when I was a kid - cut me some slack!!

I am finding it a bit more 'heavy' on my iphone 4.

Are u using DSC?

Are you using Classes and/or X-Controls?

Yer, that one threw me the first time I saw it. Especially in the context of what i was doing at the time.

Can you define "officially supported by NI" I.e. What would you expect feom them? Phone support, for them to code bug fixes etc...? Also are you go into detail about the issue you had? Cheers -JG

Yes, that seems correct, and IMHO is very logical to mainstreaming LabVIEW. On a side note, it provides a great market place, allowing developers to make money from selling tools etc... As a side note, from reading their forums, posts and blogs etc.. JKI are able to help with this process. If there is any logical reason(s) such as the above, that would make sense to move the libraries (or do anything else to them) then OpenG want to hear it! The only other use case I can think of, off the top of my head is when - I have wanted to do this in during a source distribution build: I wanted to exclude NI vi.lib but not my library VIs (which was under vi.lib at the time), but I couldn't so having it in user.lib lets me etc...

This issue is fixes in the OpenG Application Control Library 4.1.0.7 release.

This issue is fixes in the OpenG Application Control Library 4.1.0.7 release.

This release includes addressing issues involving Invoke Nodes that have been depreciated and do not work in LabVIEW 2010+ Unfortunately the Release Notes are slightly out of date, here are all the fixes: [FIX] 3275377 - Memory Leak in "Current VIs Parents Ref.vi" [FIX] 3275359 - 'Set Control Value {Variant}' function returns error [FIX] 3386881 - Depreciate Get and Get All Control Values {Variant}

This issue is fixed in the OpenG Toolkit 4.0.1.9 release.

This release fixes a bug whereby OpenG LabVIEW Data Library was not included as a dependency.

Concern? OpenG is striving to conform to standards set by NI. That should be reason for feeling relief if anything? As for LAVA, whilst I fully support and agree with the above LAVA compliments, I don't think you are comparing apples with apples here, i.e. Open Source code certification, versus - help you get on the forums? Wouldn't really be Open Source if NI owned it and distributed it with LabVIEW! FWIW I hope this day never comes. What I would love to see on the other hand is that if an OpenG VI was so awesome (e.g. covering a functionality gap) NI decided to include such functionality in a future version of LabVIEW (this is my personal opinion only). I.e. OpenG influenced LabVIEW positively then that would be great, but I don't want to see them manage the entire OpenG organization!! And it is available for everyone - simply download VIPM and away you go (Note: I appreciate that some companies cannot or do not wish to leverage such resources for internal reasons, and I have no issues with that). The LVTN is a way for any organization to plug into LabVIEW and OpenG views certification as very important. Anyways, I am just trying to understand your reasoning - are u able to go into details on why you would want the above?

To the best of my knowledge (on phone so don't have VIPM fired up) all packages part of the core OpenG Library have BSD licenses except LVZIP because it leverages other code (and must inherent it's license or similar). That document is referring to creating add-ons by anyone, I can't see anywhere it's saying offically supported by NI only if it goes in here - it's just merely a suggestion? Anyways, there is nothing wrong with user.lib. I use it, as well as other companies, to distribute reuse libraries. I can't see the location really matters, and my opinion is the similar to Ton's wrt vi.lib. As Ton mentioned moving would cause relinking a recompiling issues, which would be a big problem. Btw - OpenG is a LabVIEW Tools Network Silver Certified product. Whilst not supported by NI, it has passed the above standard.