LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
Oligarlicky

Connector Pane Modification Should Break Callers

Status: Declined

Any idea that has received less than 5 kudos within 5 years after posting will be automatically declined.

In 2014, when you update a type definition (like an enum) and it can't automatically update all the instances of the type def, LabVIEW prompts the user to modify each instance of the change. This is a great feature. Can we apply the same treatment to subVIs?

Example:
Let's say you have a subVI:
Original BFSub.PNG
And then you switch or edit the terminals. Currently, LabVIEW assumes that any changes to the subVI did not change the location of the connector terminal and silently updates the caller. This could cause a bug if the caller developer doesn't know about the incoming change. Instead, LabVIEW break the caller and allow the user to bring up dialog box for approving the change to each instance of the subVI. The dialog box should be similar to the typedef change dialog showing the user a preview of the end result of the change and also allowing the user to make manual changes to the wiring. To facilitate this wiring, the dialog could present a flat sequence structure around the subVI. The dialog should initially suggest wiring that would follow the rename. That is, if wire A was supposed to connect to beans, and there is a new beans terminal somewhere else, connect wire A to the new beans terminal. If there is ambiguity, leave the connection disconnected between the flat sequence structure and the subVI.

Example dialog:
 Create dialog with small edit area3.PNG
The user can then approve the changes applying them to the subVI instance.

Update applied.PNG

4 Comments
altenbach
Knight of NI

 So, if we only save the subVI (with the same name), should he caller still be broken the next time the project is openend? How would it know? How about callers that are not open at the time of the change?

 

Just trying to figure out how that should all work...

Oligarlicky
Member

It should be like the 2014 typedefs. If you save but don't change anything in the connector pane, the callers should not break. Callers should keep an independent copy of the connector pane of all the callees. When you load a caller into memory it should see if the callee pane still matches.

 

Edit: This is also similar to if you chose a different connector terminal pattern of a callee it will break the caller and make you rewire it. That might be an adequate solution to this. I just though the compare dialog was useful.

fabric
Active Participant
I would love to see something like this, although I agree it may be tricky to make it work smoothly. Kudos for the overall concept.
Darren
Proven Zealot
Status changed to: Declined

Any idea that has received less than 5 kudos within 5 years after posting will be automatically declined.