Find/Replace-type feature.

[Bryan]

I've had situations where I've wanted to replace multiple instances of a subVI in a block diagram by finding each one, right clicking on it, going to "REPLACE" and replacing each one with the same new VI.

It would be neat if, along with the current "Find" function, that you had the option of replacing multiple instances of a function with a new one similar to how you would use Find/Replace in notepad to find and replace text, or a hybrid of LabVIEW's separate "Find" and "Replace" features if you will.

Of course, my "wish" is geared primarily toward user-created VIs, but I suppose being able to do it with the provided LabVIEW functions would be helpful as well.

[malef]

I've had situations where I've wanted to replace multiple instances of a subVI in a block diagram by finding each one, right clicking on it, going to "REPLACE" and replacing each one with the same new VI. 

It would be neat if, along with the current "Find" function, that you had the option of replacing multiple instances of a function with a new one similar to how you would use Find/Replace in notepad to find and replace text, or a hybrid of LabVIEW's separate "Find" and "Replace" features if you will.

Of course, my "wish" is geared primarily toward user-created VIs, but I suppose being able to do it with the provided LabVIEW functions would be helpful as well.

2826[/snapback]

Bryan,

LabVIEW help note for replacing block diagram objects may give a hint:

"Note When you select a VI with the same name as a VI in memory, a dialog box prompts you to replace the VI or cancel the operation. If you select Replace, LabVIEW replaces all the VIs in memory with the VI you selected."

Before following this note you should save old VI with another name.

Greetings

Manfred

[Bryan]

Thanks for the info!

I remember seeing that before but forgot about it. I see that the only stipulation is that you have to replace the VI in memory with one of the same name. It would be neat if I could do that even with subVIs that are not the same name, but I guess that's kind of a mundane detail unless one's forced to adhere to strict naming conventions and is in a situation where using a different VI of the same name is not acceptable.

[IBerg]

Thanks for the info!

I remember seeing that before but forgot about it.  I see that the only stipulation is that you have to replace the VI in memory with one of the same name.  It would be neat if I could do that even with subVIs that are not the same name, but I guess that's kind of a mundane detail unless one's forced to adhere to strict naming conventions and is in a situation where using a different VI of the same name is not acceptable.

2848[/snapback]

Yes, this can be a valuable technique... especially when you have 1000+ Vi's in your project and then find that you need to make a change to something found in many of them!

Of course, by carefully using an intermediate step, you can replace multiple instance of a VI with a VI that did not originally have the same name..

1. Open the VI you want to replace, and all VI's on whose block diagrams all instances of that VI should be replaced. (If you only want certain instances to be replaced on the same block diagram, you have to make the changes manually)

2. Choose "Save As" to save it to the same name as the VI you want to replace it with, but in a different directory.

3. Next, open the VI you want to replace all instances of the VI with, and choose "Yes" for the "Replace VI's in memory" dialog.

4. Now if you didn't originally still want the old VI name, open the VI you have now replaced all instances of the old version with again, and save it to the actual preferred name and directory you actually want the calling block diagrams to look up when they attempt to load the replaced VI.

5. If you are aware that no other un-intended changes have been made on any block diagram (Check the list of Open VI's under "Window" menu item for any names with an asterisk indicating changes in progress), you can now use "Save All" to preserve all the changes to all the VI's!

Success of techniques such as these often hinges also on maintaining a well-organized project file folder hierarchy and on knowing and understanding the option settings for the search path.... When working on large projects or especially when making a backup copy of a large project I typically remove all the default search paths such as <found vi> so that I can ensure that I am only working in the latest build's copy of the VI's

....not making changes in this month's revisions of the project that will cause last month's working version to break. I leave only the top-level folder of my folder hierarchy for the various components (collections of VI's in the project).

I would recommend not using this technique unless you have an effective VI management backup/scheme in place and/or understand the consequences regarding how your VI hierarchy will be distributed on your hard drive before and after these changes.

[IBerg]

But to get back to the original Wish, it would be nice (although probably difficult to design and implement) if it were possible to specify one (or more) "mappings" of where wires were connected on the original connector pane connections on the VI to be replaced with where the same wires should be connected on the new replacement VI's connector pane, so that using this replacement technique successfully would not be restricted to VI's whose connector panes matched perfectly. For each connector pane input on the old VI, the user could choose "Unspecified/None" or any of the new connector pane's inputs as its future connector pane connection on the new VI. Wires connecting to old points for which "Unspecified" was selected would be broken wires after the replacement was made.

A case in point for the use of such a feature would be where I recently discovered near the end of a large project that I wanted to replace all instance of "Format To String.vi" with a floating point input with my own wrapper VI so that I could more easily make changes to future versions -- for example to specify that a user-specified decision could be used as the basis for the decimal point character selection, at least in certain components of the project, (rather than the Windows region and language setting). But there was no connector pane pattern that matched "Format To String" so the technique I outlined above would not work smoothly... every instance of of "Format To String" with a floating point argument had to be manually fixed.

One might say that I should have wrapped "Format To String.vi" in a wrapper VI straight away, as soon as I saw how often it was being used.. but it seemed such a solution would have forced the computer to use a lot of data to variant to data conversions... or several seemingly unnecessary wrapper VI's for the various types of input argument lists.