Renaming Parent dynamic dispatch VIs don't rename children

[Michael Aivaliotis]

If I rename a parent dynamic dispatch VI, the children override VIs don't get renamed. I assume this is a known issue. I'm not sure if others think this is an issue that should be fixed but it's bugging me lately.

This is in 8.6.1

[Darren]

QUOTE (Michael Aivaliotis @ Mar 25 2009, 09:01 PM)

If I rename a parent dynamic dispatch VI, the children override VIs don't get renamed. I assume this is a known issue. I'm not sure if others think this is an issue that should be fixed but it's bugging me lately.

I agree. It seems like something we should be able to do. But then again, there may be a good reason for why it can't be done...AQ?

-D

[Aristos Queue]

QUOTE (Darren @ Mar 25 2009, 11:33 PM)

I agree. It seems like something we should be able to do. But then again, there may be a good reason for why it can't be done...AQ?

Because not renaming them is intended behavior. :-) I can agree that it might be nice to have a tool to visit all of the overrides and rename them all in parallel, but not renaming them all is just as valid a use case, one that I've needed frequently.

[Jim Kring]

AQ: In situations where there are several valid choices in behavior, why not prompt the user to choose (and maybe give them an option to not ask again and use their current choice in the future, if that's appropriate)?

Mike: It sounds like you've been spoiled by great programs like TortoiseSVN that, when you rename a file (like changing a prefix), will find other files next to it with similar names (that you are likely to want to rename) and ask you if you want to apply the same renaming operation to them, too. Maybe one day LabVIEW will have a great feature like this, too

[Aristos Queue]

QUOTE (Jim Kring @ Mar 26 2009, 01:01 AM)

AQ: In situations where there are several valid choices in behavior, why not prompt the user to choose (and maybe give them an option to not ask again and use their current choice in the future, if that's appropriate)?

Jim: In situations where there are several valid choices in behavior, why not make sure that whatever you ship allows all possible behaviors and then improve access in the future if some of the hard-to-reach behaviors turn out to be in high demand? With LabVIEW's current behavior, if you want to rename all the VIs, you can, and if you want to rename only one, you can. All behaviors accounted for. If LabVIEW renamed everything when you renamed one, you wouldn't be able to rename just a subset. Functionality loss. Why didn't we just add both mechanisms initially? Consider the issues this feature raises:

1. Adding the rename all would be additional code to implement the feature plus new menu items which I am guessing there would be severe pressure against since it would push up the already mind boggling complexity of the Save As options dialog (you'd now have two different kinds of SaveAs:Rename, which is, currently, the one easily comprehendable option in Save As).
   
2. Suppose you chose SaveAs:Rename:RenameAll on a child implementation VI. Do we then rename the child and descendants or do we go rename the ancestor as well? Or do we make more options in the Save As dialog so you have three options for Rename instead of two?
   
3. What if some portion of the inheritance tree was currently reserved or locked because it was read-only on disk... does the entire Rename operation fail or do we rename those that can be renamed?
   

Very quickly this turns into a significant feature requiring a significant slice of developer and tech writer time. Most editor improvements do. The path of least code provides all the functionality albeit without the pleasant UI experience. We go with that unless there is a compelling usability reason to strive for the better UI -- which generally means either we predict the feature will be unusable without the improved UI or after release we get customer requests for a particular improvement.

I have a list of something close to 100 purely editor UI improvements that we could make specific to LabVOOP (LabVIEW itself has thousands upon thousands). I have around 20 major functionality improvments requested. In general, my team has time to implement between 3 and 5 per release as the rest of the time is generally given to 1 or 2 functionality improvements (functionality improvements are generally much harder than editor improvements because you have to implement the functionality and then you still have all the UI problems that editor improvements have). When you make requests, please phrase the priority of those requests accordingly. It helps us decide what to work on next.

[Jim Kring]

QUOTE (Aristos Queue @ Mar 26 2009, 07:21 AM)

Jim: In situations where there are several valid choices in behavior, why not make sure that whatever you ship allows all possible behaviors and then improve access in the future if some of the hard-to-reach behaviors turn out to be in high demand? With LabVIEW's current behavior, if you want to rename all the VIs, you can, and if you want to rename only one, you can. All behaviors accounted for. If LabVIEW renamed everything when you renamed one, you wouldn't be able to rename just a subset. Functionality loss. Why didn't we just add both mechanisms initially? Consider the issues this feature raises:

1. Adding the rename all would be additional code to implement the feature plus new menu items which I am guessing there would be severe pressure against since it would push up the already mind boggling complexity of the Save As options dialog (you'd now have two different kinds of SaveAs:Rename, which is, currently, the one easily comprehendable option in Save As).
   
2. Suppose you chose SaveAs:Rename:RenameAll on a child implementation VI. Do we then rename the child and descendants or do we go rename the ancestor as well? Or do we make more options in the Save As dialog so you have three options for Rename instead of two?
   
3. What if some portion of the inheritance tree was currently reserved or locked because it was read-only on disk... does the entire Rename operation fail or do we rename those that can be renamed?
   

Very quickly this turns into a significant feature requiring a significant slice of developer and tech writer time. Most editor improvements do. The path of least code provides all the functionality albeit without the pleasant UI experience. We go with that unless there is a compelling usability reason to strive for the better UI -- which generally means either we predict the feature will be unusable without the improved UI or after release we get customer requests for a particular improvement.

I have a list of something close to 100 purely editor UI improvements that we could make specific to LabVOOP (LabVIEW itself has thousands upon thousands). I have around 20 major functionality improvments requested. In general, my team has time to implement between 3 and 5 per release as the rest of the time is generally given to 1 or 2 functionality improvements (functionality improvements are generally much harder than editor improvements because you have to implement the functionality and then you still have all the UI problems that editor improvements have). When you make requests, please phrase the priority of those requests accordingly. It helps us decide what to work on next.

I'm sorry if my post made it sound like I was complaining. I was simply making a feature suggestion.

Regarding priority: if it was really important, I would have been much more emphatic (or possibly written a tool to do it myself) -- you know how passionate I get when I'm really excited or pissed about something

Now, if you'd like to show me your list of 100 editor UI improvements, I would be happy to review and prioritize them

Thanks for all your hard work -- it seems like we've all been asked to do more with less, lately.