LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

[Bug] - LLB's on Windows allow you to have invalid file names but won't load on MacOS

Solved!
Go to solution

LabVIEW 2020 Windows - 

I created an LLB and put a vi in it with the file name "Set Sequence Cluster - No HW/Cal Writing.vi".  I linked some vis to that vi and submitted my code.

 

LabVIEW 2020 MacOS - 

Upon syncing the code, the class which should contain "Set Sequence Cluster - No HW/Cal Writing.vi", instead showed "Cal Writing.vi" as a missing method.

 

It appears that LabVIEW MacOS can't parse these filename characters despite the fact that they are valid on Windows.

0 Kudos
Message 1 of 9
(3,429 Views)

I agree that this is probably a bug; perhaps this one reason why NI strongly discourages you from using them.

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 2 of 9
(3,408 Views)

LLBs have additional reasons to not use them:

  • One corrupt VI can make the whole LLB unusable
  • Can't be searched by any program other than LabVIEW (OS file searches, for example)
  • You can't track changes to individual files using source control software

 

The convenience of having everything in one file is outweighed by all of these issues in my experience.

0 Kudos
Message 3 of 9
(3,400 Views)

NI Specifically encouraged us to use them when we talked to them about our woes (e.g. have you ever tried to rename a class and get that to not completely blow up when using Perforce?).   The NI Dev team encouraged us to look into LLB's and pointed out how they had made them compatible with lvlibs and lvclasses 

0 Kudos
Message 4 of 9
(3,396 Views)

@Thomas_robertson wrote:

NI Specifically encouraged us to use them when we talked to them about our woes (e.g. have you ever tried to rename a class and get that to not completely blow up when using Perforce?).   The NI Dev team encouraged us to look into LLB's and pointed out how they had made them compatible with lvlibs and lvclasses 


Well I don't know Perforce but I would never put my files into a llb. Too risky and as mentioned, it makes it much more difficult to track changes. I have renamed and moved things around in SVN. It takes some effort but I rename things in the LabVIEW project so it handles all of the necessary updates on the LabVIEW side. Then using the repo browser in SVN I rename the files there as well. This has worked for me. Effectively, you have to rename everything twice. I would imagine that Perforce has similar capabilities.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 5 of 9
(3,380 Views)

@Mark_Yedinak wrote:

@Thomas_robertson wrote:

NI Specifically encouraged us to use them when we talked to them about our woes (e.g. have you ever tried to rename a class and get that to not completely blow up when using Perforce?).   The NI Dev team encouraged us to look into LLB's and pointed out how they had made them compatible with lvlibs and lvclasses 


Well I don't know Perforce but I would never put my files into a llb. Too risky and as mentioned, it makes it much more difficult to track changes. I have renamed and moved things around in SVN. It takes some effort but I rename things in the LabVIEW project so it handles all of the necessary updates on the LabVIEW side. Then using the repo browser in SVN I rename the files there as well. This has worked for me. Effectively, you have to rename everything twice. I would imagine that Perforce has similar capabilities.


I do the first part the same way - take care of renaming/moving things in LabVIEW first, but in TSVN (which, from your description, I am assuming you are using), I do a "fake" commit by bringing up the commit dialog.  You'll see missing files and added files.  Highlight a pair of related missing/added files, then right-click and "repair move".  (SVN doesn't do "renames" and "moves" - it always considers it a delete/add.  Doing the "repair move" tells SVN that the added file replaces the deleted file and preserves the file history.)  After I take care of all the repairs, I cancel the commit.

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 9
(3,366 Views)

That's an interesting way to do it. I just bring up the SVN Repo Browser (basically TortoiseSVNs version of a file explorer) and do a rename there. I don't have to do any fake commits. I may have to try your method and see how it compares.

 



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 7 of 9
(3,358 Views)

@Mark_Yedinak wrote:

That's an interesting way to do it. I just bring up the SVN Repo Browser (basically TortoiseSVNs version of a file explorer) and do a rename there. I don't have to do any fake commits. I may have to try your method and see how it compares.

 


I think they're probably two sides of the same coin.  The most important thing is not losing the file history on rename.

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 8 of 9
(3,341 Views)
Solution
Accepted by rolfk

It sounds similar to the pains we go through with Perforce, although I haven't noticed a "Repair move" feature, instead I've had to go hunt for the old file in P4 and manually revert it then mark it for delete (this also deletes the file history, so that's another downside to renaming files, traceability).   I consider the whole affair enough of a pain in the ass that I infrequently rename vis which is quite bad from a refactoring point of view (our code base is 25 years old and constantly evolving, it's not a quick little turnkey project).  I've also had situations where I renamed a class (in LV 2016) and the code base was still asking me to find it 3-4 years later even though no code was broken and nothing linked to it (maybe some disabled code somewhere referenced it by the old name, I don't know I never figured it out).  That experience was enough to make us scared of ever renaming a class or lvlib so now I only am willing to do so if the class/lvlib lives in an llb.

 

I have a rule that there should be no more than 5 vis in an llb, ideally no more than 3. Additionally a class or an lvlib will have its own personal llb (usually called "Fubar class.llb" in which perhaps Foo.lvclass might live, or might now be Bar.lvclass if it's been renamed).   I certainly can't get behind large llb's for volatile code (i.e. code that isn't packaged for distribution). 

 

I honestly feel like vis, lvlibs, and lvclasses should all have some of the llb capabilities where the actual name of the vi/class/library is decoupled from the physical name of the file on disk.   I believe Labview is fairly unusual in that methods have to be named exactly what their file name on disk is (maybe in Java you have to put Class Foo in file Foo.java, but you can rename the methods in the file all you want).  That coupling is just aggravating as hell when you have to deal with source control.

0 Kudos
Message 9 of 9
(3,207 Views)