jgcode

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

I'm wondering how to implement the following functionality: File - Locate In Project.

After the menu selection the element of the tree selected programitically. How can I do that?

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)?

For naming, I think that it'll be important to companies to maintain their brand through their package name. "JKI Right-Click Framework" or "GOOP Develoment Suite" should be the names, since the packages are not just components in a library (where such a naming convention is sensible), but an actual product name which the developer has an interest in branding and marketing. I don't imagine picking up a shiny product brochure titled " Speed Development With jgcode_rpk_ni_system_style_daqmx_controls-1.0-1".

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?

maybe someone who knows for a fact can settle this for the both of us

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

or, if you want to use dynamic VIs for memory loading reasons (or some other reason where static links are not so desirable)

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 really like that they figured out a way in LV 2009 to fix the naming conflict problem in a built application. But an unfortunate side effect is that if you want to run a VI within an executable, you must know the full embedded path. Depending on how your sub-VIs are organized, this path can be unpredictable.

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

I have nothing more to add at the moment, used it successfully on 3 or 4 classes.

Thanks

/J

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

I have not tested the new version, but according to the video it looks perfect.

More feedback tomorrow (some of us do sleep )

/J

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>

That is correct. The CCT allows you to create snippets without having the locals converted to property nodes.

Anyone know if this is fixed in 2010?

Hello all,

I had ever saw on ni.com that sombody shared user defined labview control kits(see attachments) which can build very pretty GUI, are there any other free kits to download?

Thx

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.

(and I don't understand when you have time to sleep, its like you are logged in all day and night)

I am seeking counselling for this issue

You are welcome, I really like the idea of the tool.

The class currently edited used 5x3x3x5, and the work made is not that much really; I start by creating the first method, then I just save a copy of that method whenever I need a new one.

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

Tool feedback;

• At first I couldn't understand why the tool was failing, but then I looked into the code and realized that you had to use a specific connector pane pattern.
  • this should at least be stated in the ReadMe
  • ideally I'd like to be able to use any connector layout. In most cases it really doesn't matter where the LVOOP controls are connected, only on methods that combine, compare etc. is this a problem.

  [*]The first point leads me to the next one, error handling. I really don't like that the tool runs without any feedback. If it fails on a number of VIs, this should be displayed to the user.[*]The tool should check that the control being renamed is of the correct class. If another class is connected to the upper left corner this will also be renamed to the class name

Once I figured this out, the tool runs very smooth.

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

Code feedback

• The VI "Rename LVOOP FP Objects__icon_lib_scripting.vi" does not close control references if cating to "LabVIEWClassControl" fails
• The VI "Rename LVOOP FP Objects__icon_lib_scripting.vi" fetches the library name in every loop iteration, but this could be done before we enter the loop.
• The VI "Align All Block Diagram Labels__icon_lib_scripting.vi! could be realized with just one loop instead of three, using a select node to select left or right justification depending on if the object is an indicator or not.

Wow and a code review too - thanks heaps! (LAVA members rock!)

Agreed on all parts!

Time for some refactoring!

Sorry about the cross-post, originally my post was just about fixing the tool in LAVA CR.

I noticed that you are using VIPM2010, but the tool could have been installed with an earlier version of VIPM (I read a note about how much you just love VIPM3.0 )

Feedback is coming...

/J

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 filed a bug report for VIPM, see http://forums.jkisof...?showtopic=1465 for more info.

I have tried multiple PC:s, both community edition as well as Pro version of VIPM. Once I edit the ogp file so that icon.bmp is not ReadOnly anymore I can successfully install the package.

Have you installed using VIPM 2010 or VIPM 3.0? I believe that this is a issue only with VIPM 2010.

Regarding feedback, check back later today (its morning here in Sweden) as I have not really started using it yet.

/J

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

Jonathon,

I had trouble installing this package using VIPM 2010, and this was probably because the icon.bmp file included in the .ogp file was ReadOnly.

The main problem is within VIPM (AFAIK), but to enable other users to use this Quick Drop Plugin, I just opened your original zip and the included ogp file and removed any ReadOnly flags.

rename_lvoop_fp_object_labels-1.0-1_LV2009.zip

/J

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

One thing to consider is how to restore the original NI VIs. Are you performing a pre-install action to back them up and a post-uninstall action to restore them?

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.

But I would love to have one and if the LAVA community yells loud enough (hint hint)

This is me yelling.

Oh, and every now and then, my IDE will switch from English to Chinese for no apparent reason.

Nice!

I am having the same thing will my builds at the moment (but in LV2009)

I wonder if it is related?

Already reported. I will post the CAR when they get back to me.

I doubt the ctrl-click selection will work but I will give it a try when I can.

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