LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Resolving folder conflicts in LV project

See the attached screen shot of the resolve conflicts screen. I have a few conflicts (which may have been created when moving and renaming folders) that are not file conflicts but folder conflicts. I am not under the impression that having two folders (autopopulating or otherwise) with the same name is a problem. In any case, these folders do not actually exist on the hard drive. They are apparently referenced in the list of VIs down below. Clicking "Use Selected Item" only appears to resolve the conflict, as after prompting for saving of the files, the newly resolved conflict diappears and then reappears right away at the bottom of the list.

 

It is true that these so-called conflicts are not directly causing any serious problems, but I have three now, instead of one, after a recent move of some files, and I do not wish to continue accumulating these conflicts.

 

I'm not sure if this is relevant, but we are using LabVIEW 8.x file paths in the executable.

Mitch
0 Kudos
Message 1 of 6
(3,726 Views)

Hi,

 


after a recent move of some files


You moved (or copied?) some files…

 

You get a conflict whenever a VI is found (or expected) in two different places. You need to resolve those conflicts by choosing the correct VI.

 

Lessons learned:

Always move VIs inside the project. LabVIEW will automatically resolve any pending conflicts this way…

 

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 2 of 6
(3,712 Views)

Thank you GerdW for your reply. As I explained in my original post the paths that are conflicting are not FILE paths but DIRECTORY paths. The conflicts displayed in the attached screen shot are conflicts between folders, each with a list of VIs that somehow reference the directory. The project conflict resolution interface does not seem to know what to do with these (see original post), and consequently neither do I.

Mitch
0 Kudos
Message 3 of 6
(3,685 Views)

If the conflicts "Reappear" you have them in an autopopulating folder.  Stop that! Auto-pop folder's are the devil's work! makes it a real bear to resolve conflicts too!

 

Now think of your car, You know you own it and you know where you parked it.  The car doesn't know its owned by you or who is parking it.  How would you like it if random people just started parking your car wherever without telling you?  Use the PE to move the project items.


"Should be" isn't "Is" -Jay
Message 4 of 6
(3,675 Views)

Actually, the conflict is not with files in an autopopulating folder. It is with folders that DO NOT EXIST. Please note that the conflicts in the attached screen shot do not have a file extension on them, because they are not files, they are folders which have been deleted. The project tells me which files are referencing the folder path, but i cannot figure out how to remove or correct those references so that the conflicting folder paths no longer show up.

 

I do use auto-populating folders, for the most part, and with a large application like ours I really appreciate the way that they force conflicts. It helps me with garbage collection in the rest of the application. I would be be suprised to learn that these so-called conflicts would go away if my folders were switched from auto-populating. Perhaps I will try switching the parent folder off of auto-populating and then restore it. The boost in organization that the autopopulating folders provide are well worth a few phantom conflicts showing up the in project.

Mitch
0 Kudos
Message 5 of 6
(3,630 Views)

@JÞB wrote:

If the conflicts "Reappear" you have them in an autopopulating folder.  Stop that! Auto-pop folder's are the devil's work! makes it a real bear to resolve conflicts too!

 

Now think of your car, You know you own it and you know where you parked it.  The car doesn't know its owned by you or who is parking it.  How would you like it if random people just started parking your car wherever without telling you?  Use the PE to move the project items.


I like that analogy!

 

I use virtual folders and physically separate controls and subVIs.  I make sub-virtual folders inside to group my subVIs accordingly.  In case someone wants to make sense of the phyiscal files, I name similar VIs... well... similarly.  Then I can concentrate on coding and not on coming up with names and locations.  If I can't immediately come up with a good name for the subVI, I don't care.  I can always rename it later in the PE and have PE take care of the behind-the-scenes stuff.  Same with virtual folder places.  I don't know how many times files started with one name and virtual location only to end up with a completely different name and virtual location.

 

I've used Auto-populating folders before.  While I don't consider them the "Devil's work," it is much more difficult to organize, since you are dealing with physical locations.  Moving files is a PITA.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 6 of 6
(3,616 Views)