jgcode

Hey Mellroth I have it installed just fine here? LV2009, LV2010; Win 7; VIPM 2010.1568 Do you have any more info? Have you tried multiple PCs? Also, if you have any feeback for the tool please post? Cheers -JG

Yes, this is what I do a the moment: for NI VIs I create a backup.zip of the files and install that in a safe place. I use pre and post uninstall scripts to extract the zip and restore the state of the original VIs on uninstall. I have some simple templates I use to do this. I have done preinstall actions in the past (i.e. in the case where the User might want to preserve their hooks) but if an issue occurs then things can go whack, so I find the above much safer. But, really the User should play it safe and have a backup of their hooks or more correctly everything under <LabVIEW> (I mean really they should be using packages!) so I don't know if that really matters anymore and that the backup.zip is fine. This is me yelling.

Nice! I am having the same thing will my builds at the moment (but in LV2009) I wonder if it is related?

Worst case is it possible to cut and paste the XML?

In this specific case - you can't use a naming convention as you have to install the Hook and name it what NI have called it. I will check out your links.

Oh well am I on my own here? I like the idea of being able to type rcf in the search box and have all the Right Click Framework packages appear. This was a standard set somewhere that people have followed and it makes it easier to find things. Keywords in the package name is handy, especially ones that come down automatically from the VI Package Network.

I just VIPM 3.0 so much I can't let go Cool Amen to that. I did bring this up at NI Week but no seemed to like it I should have mentioned this to you! IMO, I don't think all submissions need this, but my idea is that LAVA should have another level of certification. A higher level whereby releases would implement the above naming schema, and the code would be more tight and (kinda like NI's Add-on Developer levels) etc... I would love to see that. I think a source is a good idea and is required as mentioned above as it would form part of the unique identifier. As long as other names are controlled by that source then there should be no conflicts in the community. You could even go as far as registering for a source name (form some governing body) so that for whatever reasons there are no clashes in the future. Off Topic? Aside from names there are also going to be cases of installing to the same location - I don't know how that could be controlled? E.g. I have a make a package that installs LVOOP Accessor Hooks, you make one too - how does VIPM keep track of that? Installing one will overwrite the files of the other whilst VIPM still thinks its installed. The only way would be to include it as a conflict package.

I haven't done it yet but I can't see any reason not to combine names to cover the above and show that you have a hybrid install when you do a search. E.g. company_lib_rsc_package_name ??

I definitely agree with the above - more and more packages is only going to make this worse. That's why I prefer to use the search bar So do you lead the package name with the Category then? I do like this idea of a new feature called Category that appears in the Listbox so you can sort by it. This should follow NI's terminology (string, numeric, array etc..) and should definitely be standardised IMO.

No seriously as I joked above, it is a hack. I am not diss'n anybody - I have no doubt that that many man hours were involved to get it right - hence the reason I was asked for a wrapped api. I know this as the number of use cases that kept coming up was doing my head in. At the moment it could be nicer but it does the function I want it, I had to block a few things out - like overwriting an existing file so I don't have to handle if in-memory issues etc... Also I had the issue of having to remove the project items then stick them back in the tree at the top level (I don't like this but can live with it). So it would be very cool if there was a IN for Library.SaveAll that ran through the dialogs and handled everything. Do you think this is doable? Is it worth posting it to the Idea Exchange? Cheers -JG

Daklu made an interesting point on this thread about if there is any internal standardisation of package names at NI. Do we need naming standardisation? I think yes, and IMO now is the time to do it with the LabVIEW Tools Network kicking off and VIPM/packages being NI's distribution method of choice. Can we, the open source community at LAVA, lead the way for standardisation (I think yes here too)? As for me I copied VIPM's original naming convention for all packages (.vip and .ogp), as well as what was already out there. Along the way I added some of my own as the need arose. I try to be as consistent as possible (sometimes I am not!) The following are some examples of types of packages and keywords I use, as well as the name format for the package: lib = Library: [Type] Internal Reuse Library E.g. jgcode_lib_developer-1.4.0-1 rsc = Resource: [Type] Not reusable code. This can include palettes, templates, hooks, LabVIEW menu (wizard, project etc...) E.g. jgcode_rsc_jgcode_toolkits_palette-1.1-1 class = LVOOP Class: [Keyword] Contains Library/Classes designed to be extended etc... (as opposed to an non-extend-able API) icon_lib_class_variant_map-1.0-1 qdp = Quick Drop Plugin: [Keyword] E.g. jgcode_rsc_qdp_lvoop_assistant-0.11.1-1 rpk = Repack: [Type] Repacked some else's code, need to use the code but it wasn't available as a package. None of the original code is changed. E.g. jgcode_rpk_ni_system_style_daqmx_controls-1.0-1 fix = LabVIEW Fix: [Type] Exclusively released by NI and overwrites LabVIEW shipping files (something I don't normally like to do) E.g. jgcode_fix_ni_apply_icon_to_vis_buttons-1.0-1 tool = Tool: [Type]: I started using this keyword for LabVIEW tools (e.g. Project Folder) but have considered dropping it in favour of rsc E.g. icon_tool_open_icon_folders-1.1-1 Another format I have considered is for releasing code that is not quite up to production but I want to manage it's release using a package (that's a great thing about packages - they're version controlled). Haven't come up with a standard name for that yet tho. I am interested to hear how others divide up their distributions. What is everyones opinion on this?

Maybe we can start the standardization right here on LAVA. Start the revolution now! (New thread started as not to be rude)

Well I did my version over 2 days... Do hacks count?

Here is a screenshot of what I did if anyone else is interested

Thanks guys I just tested it out and it works -> For All Unsaved VIs: >> VI.DisconnectFromLibrary >> ProjectItem.Delete LVClassLibrary.Save (now works) For All Unsaved VIs: >> ProjectItem.AddItemFromMemory >> VI.Save.Instrument LVClassLibrary.Save (save with all members) The only issue with the above is that I am currently doing a recursive search for all Project Items in the Class which flattens the Project Item hierarchy as it returns an Array of (Unsaved) Children. This means when I add the files back they appear directly under the Class, not in their original location i.e. they may have been nested in a virtual folder. But I could fix this up by integrating the above into the recursive search.

Thanks for posting.

Thanks guys. The VI.Path property is not writable - so I will have to pull out the VIs, Save them, then put them back. Just out of interest - is there a Private Method to do this - surely you guys at NI don't have to do it this way? To really push my luck - any chance of creating a wrapper for it? What I am trying to do is essentially recreate the Save Class Dialog, and handle unsaved members etc... Everything was going great until I got to the last bit to do the save Oh well, maybe I should have taken DFGray's advice and just enforce that the Class is saved.

Well I guess you won't be voting for my Idea then The only thing I don't like is the conflict with Not Specified scope - which appears the same in the Project but does not behave the same.

[cross-posted to ni.com] Howdy This may be a VI Server question more so than a scripting one? But any help is much appreciated. I am running into the following issue: I have an unsaved Class with unsaved members that I want to perform a Save All on. If I run the LVClassLibrary.Save method first I get the following error: Error 1019 occurred at Invoke Node in *.viPossible reason(s):LabVIEW: One or more untitled subVIs exist. This file cannot be saved until all dependent files have been named. If I try to save each member first using VI.SaveInstrument I get the following error Error 1450 occurred at Invoke Node in *.viPossible reason(s):LabVIEW: One or more untitled library dependencies exist. This file cannot be saved until all dependent files have been named.Method Name: Save:Instrument I can't seem to find a method that does everything all at once. And I can't seem to do either one first. Can anyone help? Cheers -JG

Its good to know someone in the know Cheers.

I posted the following to Idea Exchange a while back: Display Public Scope Key for Library / Class Virtual Folder to Differentiate between Public and Not Specified On the weekend I came across the following glyph in the Enchanced Icon Editor: Out of interest I was wondering if the above Idea was ever considered to be a feature but got pulled? Does anyone know?

I like it - my Dad is named Eric

Maybe named after the top level .lvlib would be better?