Leaderboard

Name: Rename LVOOP Labels Submitter: jgcode Submitted: 28 Nov 2009 File Updated: 30 Jan 2012 Category: LabVIEW Tools Network Certified LabVIEW Version: 2009 License Type: BSD (Most common) This package is Open Source This package is a LAVA distribution - visit 'http://bit.ly/team_lava' to learn more about Team LAVA Visit 'http://bit.ly/rename_lvoop_labels' for this package's support forum This package contains a Plugin which renames a Class Member VI's Top Left and Top Right Connector Pane inputs to 'Class Name In' for control and 'Class Name Out' for indicator. Qualified Namespacing is ignored (i.e. parent Libraries). All VI control terminal labels are aligned left and indicator terminal labels right. Addtionally the Class icon will be refreshed. Use this Plugin e.g. after you have renamed a Class and you want to update it's labels or when you have cloned (Save As) a Class This plugin was designed to be use with 'LVOOP templates' therefore, the following Connector Panes are supported: 4815 - 4x2x2x4 4833 - 5x3x3x5 4834 - 6x4x4x6 4835 - 8x6x6x8 Restart LabVIEW to refresh Menus after installation Use the Tool Menu or NI Example Finder to view examples of how this tool works. Tools Menu: Plugins can be found under Tools>>LAVA>>Rename LVOOP Labels 'Rename Selected VI Only' - operates only on the selected VI 'Rename All VIs In Class' - operates on all VIs in the selected VI's Class 'Open Example' - demonstrates features of this tool Quick Drop (QD): Press Ctrl + Space to launch QD The default hotkey for this plugin is 'Z' 'Ctrl + Z' - operates only on the selected VI 'Ctrl + Shift + Z' - operates on all VIs in the selected VI's Class Help Menu: Help can be found under Help>>LAVA>>Rename LVOOP Labels Installation Locations (relative to LabVIEW directory): '\vi.lib\addons\_LAVA\rename_lvoop_labels' - main code '\project\LAVA\rename_lvoop_labels' - tools menu plugin code '\resource\dialog\QuickDrop\plugins' - quick drop plugin code (z.vi) '\help\LAVA\rename_lvoop_labels' - help menu plugin code '\examples\LAVA\rename_lvoop_labels' - example code '\examples\exbins' - .bin3 file Click here to download this file

I found a new bug in LV2010. Back in LV8.6 I reported an issue where the order of the build specifications dictated the order they would be built when doing a build all. So, If you created an EXE first, then an installer, then later added a web service and included it in the installer, the order of the build would be: Exe > installer > web service. Thus, when you make edits to the web service code and do a build all, your changes will not be picked up unless you build all twice, since the web service would be build AFTER the installer. The work-around was to drag the build specs around to rearrange them so the web service came before the installer that needed it. I reported this and said that a better fix would be for the project to detect this dependency and build the components in the right order. Well, in LV2010, not only has this not been fixed, but you can no longer drag the build specs to rearrange them and work around the bug. So, better plan your project completely before trying to build any part of it...

I suppose but I don't really like naming my build specs: a myapp web service b myapp exe c myapp installer Also, CAR #247090 has been created to track this issue. I hope it is not too late to get it fixed in SP1.

Thanks, let's hope Michael agree... 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. 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. /J

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

I filed a bug report for VIPM, see http://forums.jkisoft.com/index.php?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

Before I go into this too deep, are you operating at at least 1024x768? Assuming that you are, let me lay out why this design holds up against the 'bigger than 1 screen argument. We'll start big and work our way down. Vertical resolution of at least 1024 (1280x1024 or 1600x1050) You will easily see the code that you will be working with 98+% of the time (Event handler loop and Primary Execution) Does the fact that the other 2% or less of the time you can't see that other code? Personally I would rather have more real estate to route wires cleanly and document than cram. period. end of story Also, in this case, you will only need to scroll in one direction, which by most of our standards, is ok style practice if the situation warrants (see previous point) Resolution of 1024x768 Although you lose visibility of 40% the architecture at this low resolution take into consideration what is the largest loop. The Primary Execution Loop, the one that you will interact with 93% of the time or more. So although there will be a lot of scrolling when working with the other sections potentially, you are still able to follow the primary flow of your program without needing to scroll in the process. In summary You will find that although you have an architecture in front of you that goes beyond your monitors display, as you implement code, the containment of sections of code into monitor digestible sections makes it Very usable.

So you want to do this: ...just take your preference file you created and rename/replace it with "prefPage_Colors.vi". I never modifies the colors anyway.