jgcode

It certainly is!

You mean here as in LAVA? Make sure you look here too: UI Tools (and associated expansion packs) from François Normandin.

Maybe it would be helpful for you to post up your methods (that you mention above) too? Quick question: How important is performance to your use case? (given, that you have already have an implementation(s) to parse the data and solve the problem?)

Kudos to you and Shaun for clearing that up for me. I have another question on references: If I use, say, an IN that creates a reference e.g.: If I don't pull the reference out to use it, should I still close it? (I ask Brian P this at NI Week, but he said without looking at the source code he didn't know).

Here is the OpenG code that does it. You can find it in your <LabVIEW>\Wizard folder Cheerrs -JG

Now I am interested to know - should I be explicitly closing this reference? Or is it more like a "This VI" reference (which is a constant)?

I am guessing if you are a large company you are not going to rely on a package name for the branding and marketing of your product! I am pretty sure you would do that through other techniques i.e. go to their website, read about it, click a link to download it, (does the name matter now?), install it into VIPM. Anyways, in VIPM 2010, the package name wouldn't necessarily appear in the List as packages now have alias' so a different name will appear (as mentioned above). I am talking about the name of the package (which is about as informative as any executable or installer I download from the web these days). As this thing is definitely going to grow in the future, you are going to want to avoid any name clashes. I am not 100%, but I am also guessing this name acts as the Primary Key in the VIPM database? (The disk structure also follows this convention in Cache and Databases) So you are going to want to have something informative and yet unique. The examples you present e.g. "JKI Right-Click Framework" or "GOOP Develoment Suite" makes sense because everyone in the community knows what these are already. What happens if you come across a package you don't know about? Having standardization (whether internal, or in the community) would help someones look at a package they haven't seen before e.g. jgcode_rpk_ni_system_style_daqmx_controls-1.0-1" and be able to parse some stuff out of the name e.g. "hey its a repackage version of some code from NI's website for System Style DAQmx Controls, it is version 1.0-1, I may check this out and fire this up into VIPM and read its description in detail - or, nah I don't no DAQmx so I don't care etc..." I think that is helpful?

You are right, I just checked it out. I have always like using them as a way to include Dynamic VIs (i.e. in a build) and as an easy way to reference them - esp given the path changes in 9.x build model. I also like that the top level VI doesn't not break if the Static VI is broken. i just assumed there would be lazy loading involved if I never did anything with the ref etc... Anyways now I can keep this in mind Cheers

I am under the impression that Static VI Refs do not load the VI into memory but they "link" to the VI (i.e. you do not have to include them in Dynamic VIs in the build spec)? Or is there some memory hit I am unaware of? (I know Darren says he doesn't trust 'em)

I like to use static VI references or relative paths to get around this.

Sweet!

The ZIP download contains the Example code in the Video - if anyone wants to run a test, its already to go, just open the .lvproj file. Cheers -JG

Look forward to hearing back! Cheers -JG

I have updated this plugin to add support for the following: 1.1-1 2010 09 02 Added (): Support for templates with connector panes: 5x3x3x5, 6x4x4x6, 8x6x6x8. Fixed (): Class Control must belong to the same Class in order to be updated Fixed (): Compatiable with VIPM 2010 - No read-only files included in package. Use this plugin when you have changed the Class's name or Cloned a Class and want to update all the Front Panel Object Labels quickly. Thanks for the feedback Mellroth (hope you like the new changes). Cheers -JG <object id="scPlayer" class="embeddedObject" width="1027" height="913" type="application/x-shockwave-flash" data="http://content.screencast.com/users/jgcode/folders/LAVA%20CR/media/ca86669e-be3b-4471-bd9c-0e0a32e97c85/jingswfplayer.swf"> <param name="movie" value="http://content.screencast.com/users/jgcode/folders/LAVA%20CR/media/ca86669e-be3b-4471-bd9c-0e0a32e97c85/jingswfplayer.swf"> <param name="quality" value="high"> <param name="bgcolor" value="#FFFFFF"> <param name="flashVars" value="thumb=http://content.screencast.com/users/jgcode/folders/LAVA%20CR/media/ca86669e-be3b-4471-bd9c-0e0a32e97c85/FirstFrame.jpg&containerwidth=1027&containerheight=913&content=http://content.screencast.com/users/jgcode/folders/LAVA%20CR/media/ca86669e-be3b-4471-bd9c-0e0a32e97c85/Rename%20LVOOP%20FP%20Object%20Labels%20v1.1.swf&blurover=false"> <param name="allowFullScreen" value="true"> <param name="scale" value="showall"> <param name="allowScriptAccess" value="always"> <param name="base" value="http://content.screencast.com/users/jgcode/folders/LAVA%20CR/media/ca86669e-be3b-4471-bd9c-0e0a32e97c85/"> </object>

Anyone know if this is fixed in 2010?

Hi Techie Just so you know, these controls are available in the package: ni_lib_ni.com_inspired_controls.vip (This package is available from the LabVIEW Tools Network, and will automatically shows up in VIPM) I recommend handing out at the UI Interest Group for more (where I just found a sweet VI by Ton )

Here is a quick and dirty way to do it, but it might help you get started in LabVIEW? (I tried to add this as a VI snipped and LabVIEW changed the local variable to a PN with a static reference wired to it! - Weird) Event.vi Code in LabVIEW 8.6

Christina's the UI Queen! - don't forget to check out Eyes On VIs too. Alot of the recent blog posts relate to this.

I am seeking counselling for this issue

Sweet, I am happy to add support for 5x3x3x5 for you whilst I fix following for the next release?: Must belong to same Class [bug] Update ReadMe No read-only files in package Refactor the above code Is that cool?

Seems there was an issue with downloading the files. I have just fixed it and you can now download this package (or zip).

Thanks Jonas for the feedback! My Design Decisions: The tool was designed for working with LVOOP, so I made the assumption (which combined with scripting this is a very powerful concept - I think Norm mentions that on the Darkside) of using the 4x2x2x4 CP as standard. I did not see the need to support every CP (nor did I want to code it when I never would use it) Unless you are using GDS, you would have a lot of work for changing each connector pane from the default and if you did you probably have your own scripting tools? But I will add that to the Readme for now and look into possible support for other panes in the future. Which makes me ask - what CP patterns do you use frequently with LVOOP? So the reason for silent error handling is that it not really an error from my point of view I.e if the plugin encounters something that doesn't fit the criteria then it just ignores it and completes the rest of the tasks. I didn't see the point of reporting anything. (On the topic of error handling in general, I don't think their is chained error handling/reporting in QD but I might ask Darren about this as it would be good it QD handled it) Agreed, I should check for the correct class as the Library [bug]. Wow and a code review too - thanks heaps! (LAVA members rock!) Agreed on all parts! Time for some refactoring!

Haha! I certainly do. But I have VIPM 2010 @ work - and I did a uninstall / reinstall in LV2009 and LV2010 before posting. Not doing so, is a trap fo' young playas. PS - Nice yelling by the way

I didn't know this was a cross-post until Jim emailed me just then with the above link. My screenshots are VIPM 2010 (the Splash Screen gives it away ) Please let me know your feedback if you have any. Cheers for posting