jgcode
-
Posts
2,397 -
Joined
-
Last visited
-
Days Won
66
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by jgcode
-
-
So we're agreed that standardized package filenames aren't necessarily a good idea? I think they are within an organization perhaps, but not in the community at large.
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.
-
jgcode, why aren't you?
I just
VIPM 3.0 so much I can't let goAs far as categories and tags. Yes! we agree that this is a great feature to have in VIPM. But we don't have it yet.
Cool
As far as naming convention. I'm selfishly concerned here about LAVA submissions. I would like to see all LAVA Code Repository packages have LAVA in the product name or the filename (or both). In addition to being installed beneath a LAVA category in the palettes or menus (if it's a tool).
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.
So I pose this question, does the presence of this identifier really give you any extra value?
Does really a source (NI, NISE, LAVAG, JGCODE) + a descriptive name give you enough?
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.
-
The challenge we found is that several packages would include more than one type of content, e.g. they would have an API (lib) and also add an entry to the Tools menu/project folder (rsc).
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 can image the default view in VIPM getting pretty unruly once a few more packages are released.
I definitely agree with the above - more and more packages is only going to make this worse.
I think it's even more important to have *categories*, not name standardization... ...For example, if I'm looking for some DAQmx stuff and I sort by package name " jgcode_rpk_ni_system_style_daqmx_controls-1.0-1" won't help me.
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.
-
I bet there's some use cases it doesn't handle. On MacIntosh, does it support the D and S keys?
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?
-
Just out of curiosity, is there any sort of package naming standardization in the works internally at NI? Currently I have ni_util_packagename, nise_packagename, nise_util_packagename, nise_lib_packagename, etc.
Maybe we can start the standardization right here on LAVA.
Start the revolution now!
(New thread started as not to be rude)
-
That's a massively non-trivial task, as in, it took 4 months and four LV developers to get it working for all the various use cases when we rewrote it in LV 8.0.
Well I did my version over 2 days...
Do hacks count?
-
"Sonja" is much more fitting for something this sexy.
-
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.
-
Yeah, and I'm glad it wasn't implemented - I think the absence of a key is more intuative than a green key.
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.
-
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
-
Nope. The icon was included in the icon library for completeness, in case you had some method like "Set To Public" or "List All Public Methods" or somesuch for which the green key was needed.
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?
-
How about "Eric"? That's a good solid name.
I like it - my Dad is named Eric
-
Maybe named after the top level .lvlib would be better?
-
You should change the title. This covers both New Accessors and New Overrides.
Sorry, the name was from the Installation Folder.
The description in the package contains the text which covers your NI Document.
How about you tell me what you want it called - and I will change it to that?
-
First things first:
Please find the following links to packages so that everyone can install these updates easily into LabVIEW using VIPM.
Cheers
-JG
-
Name: New Accessors
Submitter: jgcode
Submitted: 28 Aug 2010
File Updated: 03 Jan 2011
Category: *Uncertified*
LabVIEW Version: Not Applicable
License Type: Other (included with download)
New Accessors v1.0
Copyright © 2010, Jonathon Green; JGCODE
All rights reserved.
Author: Jonathon Green
LAVA Name: jgcode
Contact Info: Contact via PM on lavag.org
LabVIEW Versions:
LabVIEW 2010 only
Dependencies:
None
Description:
This package contains code posted on NI Forums by NI that applies a fix to the New Accessors folder. All VI passwords have been removed!
This fix is for LabVIEW 2010 only.
This package will install files to the labVIEW 2010\resource\Framework\Providers\LVClassLibrary\NewAccessors folder
On uninstall the original files will be re-installed.
See here and here to view original document and post by AQ.
Installation and instructions:
Install package using VIPM.
Examples:
No examples.
Known Issues:
No known issues.
Acknowledgements:
Version History (Changelist):
1.0-1 2010 08 28
- New (): Initial public release of the code (LabVIEW 2010)
License:
Copyright © 2010, National Instruments
Support:
If you have any problems with this code or want to suggest features:
please go to lavag.org and navigate to LAVA > Resources > Code Repository (Certified) and search for the New Accessors support page.
Distribution:
This code was downloaded from the LAVA Code Repository found at lavag.org
-
Just checking to see if you know that LV2010 is not available in the LabVIEW Version drop down when posting to the LAVA CR?
Cheers
-JG
-
Name: Library And Class Icons
Submitter: jgcode
Submitted: 28 Aug 2010
File Updated: 03 Jan 2011
Category: *Uncertified*
LabVIEW Version: 2009
License Type: Other (included with download)
Library and Class Icons v1.0
Copyright © 2010, Jonathon Green; JGCODE
All rights reserved.
Author: Jonathon Green
LAVA Name: jgcode
Contact Info: Contact via PM on lavag.org
LabVIEW Versions:
LabVIEW 2010 only
Dependencies:
None
Description:
This package contains code posted on NI Forums by NI that applies a fix to the VIs in the Enhanced Icon Editor. VI passwords have been removed!
This fix is for LabVIEW 2010 only.
This package will install files to the labVIEW 2010\resource\plugins\NIIconEditor\Support folder
On uninstall the original files will be re-installed.
See here and here to view original document and post by AQ.
Installation and instructions:
Install package using VIPM.
Examples:
No examples.
Known Issues:
No known issues.
Acknowledgements:
Version History (Changelist):
1.0-1 2010 08 28
- New (): Initial public release of the code (LabVIEW 2010)
License:
Copyright © 2010, National Instruments
Support:
If you have any problems with this code or want to suggest features:
please go to lavag.org and navigate to LAVA > Resources > Code Repository (Certified) and search for the Library and Class Icons support page.
Distribution:
This code was downloaded from the LAVA Code Repository found at lavag.org
Package Name Standardisation
in Application Builder, Installers and code distribution
Posted
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.