Resolve Load Conflicts Improvements

[Simon_Holman]

When you move files around in the directroy structure (not renamed), you get prompted with this Resolve Load Conflicts message box.

For every VI file used something that has moved you must choose if you want to:

a) load with the file found in the new location.

b) load the file that can no longer be found.

I proposed having a way to automatically load the newly located file with the alternative cannot be found

OR

having a "Resolve All Conflicts" button for this case.

 

[crelf]

I'd prefer being able to select multiple items in the "Conflicts" box.

[PJM_Labview]

I could not agree more.

In my opinion, this one area where the project fail miserably. 

Prior to LV 8.0, I could reorganize file and folder on disk very quickly. For instance if I rename a folder the procedure would go like this:

- Rename folder

- Open LV

- Open all renamed item in folder in LV

- Open VI tree

- Done

--> Elapsed time: couple min

Now, if you have to do the same thing in recent LV version the project get all out of synch with the new item location and you have to go through countless conflict resolution dialog. This is a plain nightmare because this turn out to be way slower than the old fashion method. I have yet to figure out a way to speed this up.

Let me give you a concrete example, I work on a LabVIEW 8.2 project a few months ago where after doing some major reorganization on disk (all 400+ project VIs were in the same folder) it took me over 4 hours to get all the project conflict resolved! The same operation (with no project, just using VI Tree [the old fashion way] does take only a few minutes).

Unless I am missing something really obvious, there is a need for an option somewhere that say just relink with item in memory and don't make me go through all this dialogs.

Note: I am not saying that these dialogs are not useful (in various situation they are great), I am saying that they are times where they do more harm than help.

PJM

[tst]

You can do at least some of the things (such as renaming or moving) in the project tree. This keeps the links correct (provided you save everything, of course). I'm assuming that if you have SCC integration, you don't even get a problem with that.

[tst]

Just to clarify - I meant either a right click and selecting rename or move or working the files tab.

[Intaris]

Ran into this today.  More intelligent ways to solve the conflicts is definitely needed.

[Dan_DeFriese]

Oops. IMO the developer should be able to (optionally) suppress this dialog as well as any related warning dialogs and have LabVIEW simply use the specified VI search path(s).

~Dan

Message Edited by Dan DeFriese on 04-03-2010 11:38 AM

[Intaris]

I would like to add that at the very least, a double click on an entry in any of these windows should automatically open the item selected..... I've lost count of how many times I've had to hunt for the particular VI or control which needs updating before I can open it and complete the update.

[Ben_Phillips]

I was about to start my own on an issue related to this, but not quite the same.  At the very least, I think the resolve load conflict should tell you (even roughly) how many more of these conflicts you have to fix before you can pull up the VI.  Sometimes I don't really need to fully load in a VI, I just want to look at the code, but it isn't worth it if I have to do 60+ resolves.  It's always just, oops, you have one more!

[gsussman]

The whole conflict resolution mechanism in LabVIEW needs to be rethought.

Like PJM I have WASTED several hours arm wrestling with LabVIEW trying to fix project dependencies. What should be simple processes like copying some useful code from another project or moving some driver files will generate a seemingly endless string of dialog boxes.

Pre-lvproj days, identifying crosslinked files and re-linking them or this would have required only a couple of minutes. The same actions in LabVIEW are now significantly more user intensive and just plain mind numbing.

IMHO any process that REQUIRES 100+ consecutive dialog boxes is an abysmal failure in user interface design.

I just completed this process on one project after moving two driver librairies. The total count of dialog boxes was 571.