10-02-2017 02:15 PM
Hello,
I had a folder where I had all my controls and VI's for a class I made. I planned poorly and later moved this class and all its files to a new folder in my project folders. Now, when I closed my project and opened it later, I had a lot of conflicts since the files were moved, but I don't see a way to resolve these. The Use Selected Item button is greyed out. I can see that the class is now in the dependencies and says (Not loaded) [Conflict] next to it. In the Resolve Project Conflicts screen, it is citing VIs that were not in the files I moved but are VI's that are used by the VI's that I moved. Is there a way to fix this?
Solved! Go to Solution.
10-02-2017 03:00 PM
I have not done very much with LabVIEW OOP, but have lots of experience with LabVIEW Projects (which can include Classes). A Project is really just a description of "Where things are", and this knowledge is used a lot in Project organization. If you move files and Folders from within the Project, you will automatically reset their entries to the new locations.
The problem comes when you do this when the Project isn't open, such as moving files and folders with Windows Explorer. I've done this to myself, and have also observed my colleagues doing this, and it can get messy.
I just tried this myself, moving a folder of stuff inside a Project folder (with LabVIEW off) and then opening it -- it was "too simple" a test, as LabVIEW just said "Which of these two VIs did you mean, the old address (without an icon) or the new (with the icon)"? It was a simple case of "choose the right one".
When it gets messier and this simple method doesn't work, open Dependencies (at the bottom of the Project Tree). This is something you typically need to do if you rename a file or folder instead of simply moving it. The "old name" will be in Dependencies (as the "caller" routine doesn't know you changed the name of the VI it is trying to call). You should be able to right-click it and say "Replace with VI found in this Project" (or words to that effect) and go find the new name (which should be in the Project, of course).
Depending on how many VIs you have to process, this can get tedious, but then that serves as a lesson -- "Don't do that again".
Bob Schor
10-02-2017 03:35 PM - edited 10-02-2017 03:37 PM
What you did is like borrowing your dad's car and parking it in a random location. Your dad, the lvproj, knows where he left the car last and, if he can't find it there, he will complain. Its a lot nicer too ask dad to mover the car (move the objects from Project Explorer NOT Windows Explorer
And you did worse than that! Libraries (and Classes) know where their stuff it too! so don't go moving them around without asking them PLUS the stuff (vis etc..) Also knows what library or class it belongs too and where it is. Think of this like physically moving your local library and forgetting to tell the books the library moved!
You are going to have pain. Good, pain is a great way to teach you not to do that again!
To make it a bit less painful for you to "Fix it" FOR EACH lvclass. and lvlib:
Then:
Last:
10-06-2017 08:37 AM
I might be misunderstanding your instructions but they are not working. I am not able to drag and drop VIs or anything from my windows explorer into my project explorer. I also am not able to right click and do replace with. In my Resolve Project Conflicts window for each VI or control, it shows the old path and new path for the VI but I am not able to click on "Use Selected Item".
10-06-2017 09:32 AM
If you can reset all files to the original state and position, it would be easier restart from the beginning and move all the stuff in the Project's File tab, dragging and dropping items.
However this file view only shows directories that contain project's files; thus the first file for each new directory should be moved opening the vi and selecting Save As... -> Rename, which let you choose the new location.
10-06-2017 09:37 AM
I would revert to the previous version of the code and then move thing sonly using the project.
I have seen some project get so screwed up that I could not resolve the issues particularly classes that are recusrsive...
Is there good reason why can NOT revert to the previous version?
Ben
10-06-2017 09:42 AM
I also learned to Save All frequently when I make changes to the project.
LabVIEW 2011 crashes quite often in those cases, although especially when changing build specifications.
10-06-2017 09:54 AM
@Ben wrote:
Is there good reason why can NOT revert to the previous version?
Ben,
While I completely agree with your post, I know from my own experience with my "formerly bad" behavior that there are several reasons why one cannot revert to the previous version:
When one has a large Project and is faced with the Current Revision and the Last Known Good Revision, it can become an interesting exercise to figure out which of the 800 VIs have been changed, how they've been changed, and how to start "repairing" things ...
Bob "Commit Early, Commit Often" Schor
10-06-2017 09:55 AM
@pincpanter wrote:
I also learned to Save All frequently when I make changes to the project.
LabVIEW 2011 crashes quite often in those cases, although especially when changing build specifications.
Oh,
You have "Auto-populating" folders in your project!
~~~ Face-palm~~~~
Don't do that!
10-06-2017 10:02 AM
Jeff·Þ·Bohrer ha scritto:
@pincpanter wrote:
I also learned to Save All frequently when I make changes to the project.
LabVIEW 2011 crashes quite often in those cases, although especially when changing build specifications.
Oh,
You have "Auto-populating" folders in your project!
~~~ Face-palm~~~~
Don't do that!
No I don't. I use auto-populating folders only when creating a brand new project.