jgcode

Great !

Thank you for your work

Olivier

You are welcome, my friend

Hi Folks,

I think perhaps this discussion is in part related (or will be when I post my next comment) to an idea i have posted at LV idea exchange: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-a-Package-Manager-to-LabVIEW/idi-p/1670074 check it out.

Cheers,

/MArcus

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 must be missing something - how do I turn on the mobile theme? All I can get on my 'droid phone is the full site.

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

Have you tried setting the "Enable Debugging" flag

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.

I disagree. Are you using the mobile theme?

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 am using classes

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.

JG always looks like that

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

Nice, the mobile version of the site looks good and is way more functional than before.

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

It seems that NI is attempting to leverage the community for extra value added toolkits and re-use code while giving credit to the toolkit developers. Many of these toolkits have "NI part numbers" but are 100% supported by partners.

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

I concur with the above reasons for keeping OpenG as a third party package. I believe the reason why some want OpenG integrated into LabVIEW is due to issues with the process of getting the library into LabVIEW. For instance, my organization had to tweak the firewall for VIPM to properly download the OpenG packages. I can see how this may be a hurdle to install "additional" software with IT among large organizations.

As a side note, from reading their forums, posts and blogs etc.. JKI are able to help with this process.

And to follow-up on the original thread: thank you for the information. My hunch was backwards compatibility. It would be nice to have OpenG libraries excluded from the VI Hierarchy window which is not an option for user.lib.

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}
  

You can track this bug here: ID: 3386109

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.

Jgcode, I appreciate that OpenG is Silver Certified. I didn't know but that alleviates that level of concern for me. And as we all know LAVA is the "gold standard" of highly talented, well-seasoned LV architects and aficionadi who give us all the benefits of their experience by giving us their time: and that is the single biggest gift anyone can give you.

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?

I think if (and I really hope it's WHEN) OpenG is fully integrated into LV "officially", it should then be in vi.lib as it should be part of the default instll: ie available to all users. But that's probably just simply an IMHO kind of statement.

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.

Thanks Val, yes that is correct.

Furthermore, nothing was removed in 4.x, in fact that was one of our design goals. Some things were shuffled though to leverage some awesome new features of VIPM (with no affect on relinking of course etc...).

Cheers

-JG

...the problem was that the OpenG Toolkit package didn't declare a dependency on OpenG LabVIEW Data Tools....

You can track this bug here: ID: 3386109

I believe the bug is derived by the mismatch in the case structure's state and the enum value being passed to the reorder 2d array. See attached pic.

You can track this bug here: ID: 3390029

At one particular instance of my application, I want to force the child to call the parent method (irrespective of having dynamic dispatch terminal – addition function in this case).

Is anyone aware of any work around for this type of usage?

I had this question when I first started using LVOOP and was trying to do some JAVA examples in LabVIEW (where JAVA supports what you are trying to do).

Check out the thread, AQ replied - its a good read.