jgcode

This is something I have played with in the past with my reuse library in LabVIEW where VIs represent packages and I link them and then use the VI Heirarchy window to view it. If VIPM had that feature it would be really cool. But it's probably heaps of work for a little used feature.

I disagree - I think it would be easier for end users and OpenG developers if all packages are rolled out at once (like we did for v4.0).

No, i was thinking that the flag would select the correct RegEx string to use in the MP primitive. So overhead should be negligible.

Cool. In the context of the email I sent, 'donated' referred to if OpenG would maintain the library (upgraded, fixes etc...), if e.g. the author preferred this.

In summary: Add this VI to OpenG Move to MD5 package Allow non-strict capitalization Implement code similar to this: With the non-strict capitalization issue, could an optional Boolean flag called "Strict Capitalization" (default = F) be added to the interface? Would that be a good feature to have?

I thought it couldn't hurt, so I have gone ahead and tried to ontact the author and see if the code could be donated to OpenG etc... (given that Library is no longer available and it was released as Open Source).

I will close this thread and reject this inclusion into OpenG.

I am sure we can work this out - I would love to see CCT on LVTN thru LAVA With flexibility mind - can you conform to everything else bar VI namespacing? If namespacing was maintained, but was in a LAVA version you 'may' have some relinking to the new folder location but LabVIEW 'may' handle this automatically (like I tested for OpenG -in the moving to vi.lib? thread). Can you test it and report back? With the LAVA package name, you can just have a conflict with the current CCT version so it uninstalls automatically. Thoughts?

This Article outlines the Requirements and Recommendations for publishing code through LAVA onto the LabVIEW Tools Network. My Package is used as an example in throughout this Article. Requirements Installation Type Code must be distributed as a package (.vip or .ogp). This will mean it is compatible with both the LabVIEW Tools Network and VIPM Installation Directories Installation directories have been standardized for the purpose of organisation and avoiding namespace clashes etc. No package released on LAVA, in the LAVA-CR or elsewhere should install to these locations - only those packages that are approved by LAVA for the LabVIEW Tools Network Once your package has been accepted, you will own that namespace and can install to other locations (if haven't already) in the future (think of it like a domain) without worry of collisions Palettes: <vi.lib>\LAVA<\package_name> Tools: <project>\LAVA\<package_name> Examples VIs: <examples>\LAVA\<package_name> Examples .bin3 files: <examples>\exbins Addons#: <vi.lib>\addons\_LAVA\<package_name> # Not for distributions that contain public VIs (i.e. VIs appear in palette or need to be linked to by end users) Package and Palette Namespacing Example package names will be lava_<type>_<my_package>-<version> Where type = lib for Libraries and type=rsc for Resouces/Tools E.g. lava_lib_my_package-1.0.0.1.vip In VIPM the package name is directly related to the palette name We require packages to be ordered alphabetically in the dynamic palette hence, the above convention must be followed Additionally, if using OpenG Package Builder, palette name must match the equivalent VIPM name VI Namespacing It is recommended that VIs should be namespaced similar to old school VIPM renaming syntax (e.g. __lava_lib_<package_name> however, at a minimum __lava should be used If a LabVIEW Project Library is used to namespace code instead, then add __lava namespace to the distributed library Palette Location Both .ogp and .vip packages that contain palette VIs will link to the LAVA Palette package as a dependency which is published on the LabVIEW Tools Network. The palette must appear under the Addons\LAVA top level palette however, users may wish to include another palette under the correct programming sub-palette. The VIPM Custom Category feature is currently not used Dependencies Any package dependencies must be also published on the LabVIEW Tools Network (aka external dependencies). Packages (especially Tools) should try to limit all dependencies by building in supporting VIs to the package (aka internal dependencies) Coding Standards The code distributed must meet the requirements of being LAVA Certified. Additionally you should follow the LabVIEW Development Guidelines and the standards for the Compatible with LabVIEW level that you ultimately want to achieve Recommendations Iconography We recommend you use any color, glyphs, text etc... for your icons. There is no set theme or icons - we don't want to stifle your creativity! License We recommend that you distribute under the most flexible license to aid in end user reuse (e.g. new-BSD license), but there is no licensing requirement - only that you have one It is recommended that this license is Open Source Initiative approved Adding a License Agreement file is also recommended (but this requires VIPM Professional) Premium Membership It would be helpful if members maintained Premium Member status so they can edit and delete posts etc... to maintain their forum professionally However, if not, we will open up this functionality for Team LAVA Developers Folder Naming Excluding Tools location, it is recommended that the folder name is package_name note: lower case and contains underscores for space E.g. <LabVIEW>\vi.lib\LAVA\my_package Click here to view the article

Elijah Kerry has blogged about that one a bit.

I have moved this thread to pending. If not many are interested I will close this in the near future and reject this proposal.

Thx, I do this but didn't know it had a name.

I haven't benchmarked it personally, so I cannot comment there, as I am just gathering requirements for this project (if it goes ahead). I see the use case that the OpenG copyright will be integrated with other copyrights, so I don't see the value in create a single screen etc... just for OpenG. What do others think?

There is a (not very popular) idea to fix this issue here (I would like to see it fixed regardless as, yes, it is annoying).

The only thing that concerns with this is that the operation may take a while to complete in very large projects, plus information could be missing. I would rather have a tool where I can parse the information and format it the way I like in the IDE, then its simply a matter of displaying it to the user in the app. If the formatting was done in code, I could always just run the tool then re-run the formatting code when I needed to update the license. I think this would be better?

I would be inclined to say no based on the fact this already has a meaning. Therefore if you saw it in RTE is it actually the ultimate ancestor or is it a class with its icon stripped? Least I know what the ? means now....

As you mention, if you implement a constant then you can easily decouple that from your code by passing the data by wire from the application to the modules etc... At the end of the day if you want to update the constant you only want to do it one spot, I can't see a difference between subVI and global in that regard, unless you wanted to add the constant to a re-use library then yes, subVI would be easier/more-common. Maybe it does come down to expectations....

Most likely for data validation. Of course the main reason for the review is verify whether this would be a useful function (and then how to implement it, if it is useful). So, please continue to let us know either way.

Hi Jonas Can you please clarify - are you saying you would like this tool to run in the Run Time Environment and it would popup a dialog showing the license information after having scanned the VIs for that information? Cheers -JG

Anyone interested in this functionality? Please give feedback.

Very cool - I like this very much so I will post it here:

Hi Olivier Thanks for the hot tip - can you go into details about these changes for 2012? I will head over to that NI Group also and see what I can find out. At the moment VIPM handles generation of Top Level Menus using the Custom Category feature, so any changes to NI protocols I assume will be reflected in VIPM. The good thing is, palette and disk hierarchy are not always related, which is the case with OpenG, so palette location would not affect a move to vi.lib (as long as everything is configured to point to the new location etc... of course).

I see the LAVA-CR allows CC license for submissions.

If its a constant then its never going to change - refactor it out and pass by wire into the loop.

No probs.