Jump to content

Auto Relink All SubVIs


Recommended Posts

QUOTE (Michael_Aivaliotis @ Dec 5 2008, 09:36 PM)

Wow, I just figured out the answer. Apparently this can be done using the "replace with" function. In the search results window. Just do a search on the VI then replace it with itself. Awesome!

That is a nifty trick that I did not know about. Good find. I'm pretty sure I would have attempted to solve this with scripting if I had 675 instances to fix...

Along these lines, I'd like to know how you guys would feel about LabVIEW doing the relinking automatically in some cases. There are a few reasons that the relink is currently manual...for instance, if there are several identical data types on the conpane, and in addition to changing the pattern, you also rearranged (and renamed) some of the terminals, the relink might not wire them correctly, so by manually visiting the subVI instance, there's a better chance you'd discover the incorrect routing.

However, I must say that in my 7+ years doing VI development full-time, I don't think I've ever seen LV mess up the wiring after a relink. Do y'all think it would be beneficial for LabVIEW to automatically relink subVIs on VI load if the only thing changed was the connector pane pattern? In Michael's case, it sounds like having this functionality take place at edit time when VIs are already loaded would be useful as well.

-D

Link to comment

99 percent of the use cases is when you need to add terminals on a VI that has all the terminals full. In other words you need to change the pattern to add more space. You don't usually rename terminals or rearrange them. Not that I haven't done that. So in these cases LV relinks properly.

I can see that if a relink occurred where terminals were swapped but not broken then this would be bad. However even with a manual relink, the end user rarely notices it because the wires shift around but the colors stay the same.

I guess NI's taking the safe route and letting the user blame themselves instead of LabVIEW for the problems that may come down the pipe when the app doesn't work.

In my opinion I would just prefer to let LabVIEW do the relink "like magic" and have %99 satisfied users delighted. Even if it means that %1 will swear at NI for breaking their app.

Link to comment

QUOTE (Darren @ Dec 6 2008, 01:00 AM)

That is a nifty trick that I did not know about. Good find. I'm pretty sure I would have attempted to solve this with scripting if I had 675 instances to fix...

Along these lines, I'd like to know how you guys would feel about LabVIEW doing the relinking automatically in some cases. There are a few reasons that the relink is currently manual...for instance, if there are several identical data types on the conpane, and in addition to changing the pattern, you also rearranged (and renamed) some of the terminals, the relink might not wire them correctly, so by manually visiting the subVI instance, there's a better chance you'd discover the incorrect routing.

However, I must say that in my 7+ years doing VI development full-time, I don't think I've ever seen LV mess up the wiring after a relink. Do y'all think it would be beneficial for LabVIEW to automatically relink subVIs on VI load if the only thing changed was the connector pane pattern? In Michael's case, it sounds like having this functionality take place at edit time when VIs are already loaded would be useful as well.

-D

Autorelinking is tricky. It is usually required when you change the connector pane and that can be not always unambiguously resolved. I wouldn't mind if there was a dialog that tells me something like: "There are currently XX instances of this VI in memory and they can all be relinked safely/not safely! Do you want this to be done automatically?" though.

Rolf Kalbermatter

Link to comment

I'd go for a new context menu item, right below Relink to subVI, called Relink All Instances. It would need to have a confirmation popup of some sort, maybe like Rolf mentioned: "There are 500 instances of this VI in memory. Do you really want to relink all of them? This operation cannot be undone." When selected it could just automagically do a replace, like Michael discovered.

Link to comment

QUOTE (Justin Goeres @ Dec 6 2008, 08:40 AM)

I'd go for a new context menu item, right below Relink to subVI, called Relink All Instances. It would need to have a confirmation popup of some sort, maybe like Rolf mentioned: "There are 500 instances of this VI in memory. Do you really want to relink all of them? This operation cannot be undone." When selected it could just automagically do a replace, like Michael discovered.

Popping up a dialog and requiring user interaction doesn't seem like too much of an improvement over Michael's Find/Replace trick (and I believe his trick is undoable). I was suggesting that we do automatic relinks only in cases of changed connector pane, with no renamed terminals (and the VI still residing in the same place on disk). Are y'all not comfortable with an automatic relink in this scenario? I think a change like this would primarily benefit people in Michael's scenario, or people who distribute VI-based APIs and need to add connector pane terminals between releases of the API without having to perform mutation or having their users perform manual relinks.

-D

Link to comment

QUOTE (Darren @ Dec 6 2008, 09:12 AM)

I was suggesting that we do automatic relinks only in cases of changed connector pane, with no renamed terminals (and the VI still residing in the same place on disk). Are y'all not comfortable with an automatic relink in this scenario? I think a change like this would primarily benefit people in Michael's scenario, or people who distribute VI-based APIs and need to add connector pane terminals between releases of the API without having to perform mutation or having their users perform manual relinks.

I'm perfectly fine with this. Where do I sign? In general I abhor dialogs. There are many reasons why, but primarily, they end up being like that pesky fly that keeps buzzing around your head that you keep on desperately swatting with your hand. You can never kill it, but just make it go away temporarily. Then it comes back and you swat it away again. All you want to do is get your work done but that pesky fly keeps buzzing around your head. That's what dialogs are.

==

Here I go hijacking this thread, but is it me or is the resolve conflicts dialog totally useless. I mean, I can never figure out what the hell it's trying to tell me and in most cases it seems like I only have one choice and it's already highlighted for me.

Link to comment

QUOTE (Michael_Aivaliotis @ Dec 6 2008, 09:06 PM)

Here I go hijacking this thread, but is it me or is the resolve conflicts dialog totally useless. I mean, I can never figure out what the hell it's trying to tell me and in most cases it seems like I only have one choice and it's already highlighted for me.

Well that basically means you have all ready thought about the conflict (unconsciously offcourse) and provided LabVIEW with a (one) valid solution.

Not so advanced users (the ones who don't know what cross-linking is) will have more than one option on occasion.

Remember when you got in previous LabVIEW versions a message that said

I was looking for XYZ.vi in c:\lv8.x, however I found XYZ.vi in c:\lv6.x, I am using that now, if you don't want that don't do a 'save all'.

NI has built a dialog around this little seemingly unimportant message, making it clear what you could harm.

Ton

Link to comment

Darren,

I like your idea and think some version of it should be included as the default or at least as a second menu-based option: eg Relink This SubVI (which is current behavior) and another Relink ALL Instances. If adding an option like that is problematic then the default should be exactly as your originally proposed it. For most LV users, most of the time, it will greatly ease an otherwise burdensome task. And those who are more advanced are much more likely to do the right thing from the beginning to not create problematic relinking and, if they do somehow do that, they would most likely be in a very good position to revert to a prior version (SCC) or know where to start looking for problems (inappropriate linkages due to the saved change.).

Link to comment

QUOTE (Darren @ Dec 6 2008, 10:12 AM)

Popping up a dialog and requiring user interaction doesn't seem like too much of an improvement over Michael's Find/Replace trick (and I believe his trick is undoable).

Having it in the context menu would save several clicks over the Find-Replace mambo. That's a huge improvement.

Also, I would prefer having a confirmation dialog of some sort because Relink All Instances is an operation that can potentially change several hundred VIs whose windows I don't have open. I understand why Michael abhors dialogs, but in general an operation that's going to affect hundreds of files I'm not even looking at should both warn me before it does something and give me the chance to back out.

Link to comment

QUOTE (Justin Goeres @ Dec 6 2008, 07:39 PM)

Also, I would prefer having a confirmation dialog of some sort because Relink All Instances is an operation that can potentially change several hundred VIs whose windows I don't have open. I understand why Michael abhors dialogs, but in general an operation that's going to affect hundreds of files I'm not even looking at should both warn me before it does something and give me the chance to back out.

What kind of warning do you get when you change a typedef by adding, removing or renaming controls within it?

Link to comment

QUOTE (Justin Goeres @ Dec 7 2008, 10:03 AM)

None, but I can't accidentally modify a typedef by just mistargeting an item in the right-click menu.
I don't think you're following me here. When you edit a typedef and save it, you are essentially applying a relink action to all typedefs wherever they are called. Even if, for example, a bundle or unbundle breaks. LabVIEW just does it and there is no asking you. Similarily, when you edit the connector pane of a VI and save it, why doesn't LabVIEW automatically relink all instances without asking you? I know the answer, but I'm asking that it should just do the relink. So you won't even need to have right-click option. It just works.

Also, I was rethinking Darren's proposed solution and I'm not sure I like it anymore. The reason is because you are creating a situation where LV sometimes relinks and sometimes does not. This will add more confusion than it's worth. Why does it work sometimes? Too very confusing for the end user.

Link to comment

QUOTE (Michael_Aivaliotis @ Dec 8 2008, 01:05 AM)

I don't think you're following me here. When you edit a typedef and save it, you are essentially applying a relink action to all typedefs wherever they are called. Even if, for example, a bundle or unbundle breaks. LabVIEW just does it and there is no asking you. Similarily, when you edit the connector pane of a VI and save it, why doesn't LabVIEW automatically relink all instances without asking you? I know the answer, but I'm asking that it should just do the relink. So you won't even need to have right-click option. It just works.

And that caused a lot of bitching in the past since it didn't always work optimal. For many versions Bundel/Unbundle by Name could get really badly confused and just randomly switch terminals (and not always was that causing broken wires). The situation was so bad that I had wished it would not rename at all but just leave invalid names in the Bundle/Unbundle instead and let me search it out manually.

Rolf Kalbermatter

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.