Adding dependency conflicts Ver 2009 f3

[Hobbs23]

Thanks for the reply

The program whines about dependencies that have changed since the last time the project was saved. This happens even if I save, shut down, then reopen the vi. The files it complains about are all ".mnu" files associated with those drivers.

I sent you a snip of the Project, but once it whines, I hit "close", it does some mumbo-jumbo (maybe puts them into memory?), and then I see no errors until the next time I load.

Tempting on the Auto-populated folder although if I have one at this point it was inadvertent... and I'll STOP, when I WANT to stop... whatever it is, that I don't understand I'm doing. 😉

[JÞB]

AH HA!

OK, so just a little more "Learning experience" (Pain) and only 2 "Don't do that agains!"

Thanks for the snip and having the file locations showing.

Fix process:

1. Close everything and get back to a Getting Started Window
2. Change pallet loading:
   1. Tools>>Options>>Environment, Check "Load Pallets during Launch"
   2. Relaunch LabVIEW
3. Fix Project
   1. Select the lvlibs in <LabVIEW>\Instr.lib\ Right-Click and select "Remove from Project"
   2. Go to Files view
   3. Select anything in <LabVIEW>\User.lib\ Right click and select "Move On Disk" Move them out of <LabVIEW>\ to someplace else
   4. Select those controls in <Documents> and put them over by the new project location
4. Save everything.
5. Relaunch LabVIEW
6. All Better

<LabVIEW>\User.lib\ is for "Reuse Code" LabVIEW goes though that folder structure and creates *.mnu File entries to load onto the Tools / Controls palettes.  Projects COULD go in <LabVIEW>\Projects\ but that is normally avoided to make SCC configurations sometimes simpler.  Best practice is to have a structure that mimics your SCC Repo and an agreed <Development> path (C:\MyCompany\LabVIEW Code\LabVIEW Version\ProjectName\ is common)  Having your working project path inside User.lib just confuses LabVIEW when it tries to load pallets. Don't Do That.

<LabVIEW>\Instr.lib\ is for instrument drivers and LabVIEW also automatically gone though to pull up items for the palletes. Items in vi.lib and instr.lib belong in dependancies of your project and not in the project.  LabVIEW projects recognize these special paths and make exceprions for them in all build specs as well as them being included by default in the search paths so LabVIEW and the Project know how and where to find them.  So if your project is in one "Special" place and has items as part of the project from another "Special" place the palettes just get confussed as all hell.  Don't Do That!

Oh, yeah, by Default LabVIEW tries to load the palette items when you need them.  So, if you are adding to or moving things around from "Special Locations" during development the palettes get confussed as all hell unless you Load Palettes during launch.

All in All it makes sense!  but I admit sometimes its like learning how a handgun works by pointing it towards the ground an shooting yourself in the foot.  (Not Recommended)

[Hobbs23]

Yer kill'in me. 😉

Since I don't live in some remote mountain hut, I must pick this up in the morning... after... I go to my hut... on a rock strewn mound of dirt. SO, I'll let you know how I fair.

Thanks!!

[Hobbs23]

Ouch,

but I do appreciate you spending the time to instruct me, and those after me that read this.

Well, that was a learning experience that I do see the advantage of. For the sake of those learning from my mistakes, I noticed the following:

-For my particular version of LV, I found the switch  for "loading Palettes during Launch" in Options>>Controles/Functions Palettes. (Fairly normal to find things in slightly different locations when talking across platforms/Versions etc.

-At first I just put a temp directory on the Desktop for this UNTIL I realized this is a resting place for the entire project which will stay put until I am ready to migrate it to another computer.

-The program complains about every single thing from dependency conflicts, to OMG you haven't save this yet, and oh by the way you did say you wanted to make a comment every time you saved a version of anything. I pressed ok, or save at least 300 times.

-Finally looking to previous snips I posted, you can compare the directory structure to the one I have now . Much nicer. (conflict4.jpg)

-Now the problem, loose ends. I still have some dependency conflicts that come up every time (Conflict5.jpg). Notice that it is following those files around. I also am curious about two things left in the old user.lib directory, one of which is flagged and says it may even not be there anymore. These do not give me the option of "move on Disk" though, but don't seem to be the thing whined about by the program.

I can feel it, we are almost there. (yes and that was a pain in the butt for sure) 🙂

[Hobbs23]

Progress

     Turns out when I used the "getting Started" window to open the last project, it loaded from the LabView directory user.lib location. I must have not done that part correctly. Now it is all nice and tight in the new directory as shown in the Conflict6.jpg.

I still get the dependency conflict warning every time I load the main vi. All the conflicts are ".mnu" files. They warn of these files causing conflicts with things in my project. WHAT THINGS LABVIEW!!?? WHAT ARE THESE MNU FILES, AND WHY DO I NEED THEM? THEY TASK ME!!!

[JÞB]

Quick tip.  Jpg files are just awful use the snipping tool to save png files and see that 📷 icon ? Click it then drag n drop the png inline with the text.

Those mnu files are for pallets  and, you still have the instrument driver in the project and at the wrong file location.  Place the driver in <LabVIEW>\instr.lib\ and remove it from the project.  It will show up in dependencies like vi.lib.

[Hobbs23]

Thanks again

...and I have to jump through soooo many hoops to get a jpg. Ok, I will use this magical snipping tool you speak of. Thanks

-I misunderstood thinking I needed to move everything. I even moved the dependency folder. Ok, I will undo that foolishness.

[JÞB]

Look on the bright side.

Most developers just "do it the other way" because that's what they were taught to do and never had to learn all the valuable minutia you just got dumped on you about the whys.  Do keep trolling the forums for these tips you "Sea-Daddy" should have shown to you.  Its what we are here for. 

[Hobbs23]

Indeed

It's just another broken arm. 😉

Ok, I did the reorganization, putting everything back the right way. I remember seeing the snippit thing in LV2015. I tried finding it in this base package of LV2009 with no luck. No Camera Gyph or anything. (we are not under contract either for any services other than coffee.... if we bring our own ;))

However, knowing the format you desire, is just as easy for me to pull off. So I attached the result of the last movement, saved, recompiled, and now I am hopefully ready to dig further down into the pallet menu conflicts. I can't for the life of me see what any dependencies could create conflicts with other files in the project.

[JÞB]

---

@Hobbs23 wrote:

Indeed

It's just another broken arm. 😉

Ok, I did the reorganization, putting everything back the right way. I remember seeing the snippit thing in LV2015. I tried finding it in this base package of LV2009 with no luck. No Camera Gyph or anything. (we are not under contract either for any services other than coffee.... if we bring our own ;))

However, knowing the format you desire, is just as easy for me to pull off. So I attached the result of the last movement, saved, recompiled, and now I am hopefully ready to dig further down into the pallet menu conflicts. I can't for the life of me see what any dependencies could create conflicts with other files in the project.

---

Use the windows Snipping Tool

Do a save as (png is the default)

Click THAT camera in green Drag-n-drop Capture.png click done