LLB creates seperate files when vis are named the same

[thols]

---

@Nils_Thomsen wrote:

I don't see the point in adding a prefix. It will simply rename all files what will bring no advantage as they later still have the same name.

---

If you rename one but keep the other, then they won't have the same name. 

But from your picture, I think you may get another problem. I guess NI_HTML inherits from NI_Report, and if you rename one of them, then you will break that. 

[Nils_Thomsen]

But I cannot rename it partially in the built options.

[thols]

---

@Nils_Thomsen wrote:

But I cannot rename it partially in the built options.

---

Just create a virtual folder for each, or at least the one you want to set prefix on:

[wiebe@CARYA]

Even if you can put 2 VIs with the same name in an llb, you couldn't load them in memory at the same time, unless they're in their own namespace (.lvlib or .lvclass)

I suppose you could (have to?) make a llb that (statically or dynamically) links to a 2nd llb (or ppl or (compiled) VI).

The 2nd llb should have the VI with the same name in a lvlib or lvclass, or it simply won't load if the other VI in memory.

If I got stuck with a llb plug in system, I'd try to write a manager plug-in that could load things however I want it.

[raphschru]

Do you really need vi.lib VIs to be included in the distribution ? I'm not sure how LV or your application would load multiple copies of vi.lib VIs anyway…
Otherwise you can solve your problem by simply checking "Exclude files from vi.lib":

I think the problem comes from the fact that llbs do not recognize lvlib/lvclass namespacing…

[thols]

Even if you can solve this by renaming files in the build, I still think you should question if you really need everything in one single llb. That just isn't practical.

If that really is the case, you can be creative and put zip file data in a string in a VI, and when the main VI runs, extracts that zip (to e.g. the temp folder which you always have write access to) and loads whatever you need from there dynamically.

[Nils_Thomsen]

Seems like that's a working solution.

I'd be nice, if labview would be smart enough to do it itself but that may come in LV34...

Their experiment with lv nxg took too many ressources and the good old standard lv has a huge ballast in really bad habits and functionality that needs a severe update.

[thols]

---

@Nils_Thomsen wrote:

...

I'd be nice, if labview would be smart enough to do it itself but that may come in LV34...

...

---

If you post your idea in the Idea exchange, there is an actual (albeit small) chance that it will happen. 

[Nils_Thomsen]

I followed the idea exchange almost a decade and my impression is that NI is not interested in porting the suggestions. Seeing the changelogs over the last view years they adopted some small changes that were supplied over the exchange but honestly I have the impression that the whole development process is stuck and there are just a few homoeopathic changes between major releases at all. Sometimes something usefull is added but our last version jump was from lv15 to lv21 and there were a few things that are useful. Streams and pipes aren't as they do not even compile properly if used multiple times in a project. And I'm sick of paying thousands of dollars to get almost no improvements. Furthermore their change to the subscription method will prevent us from updating as long as anyhow possible.

[Nils_Thomsen]

After some extensive testing, I found it is not working as expected.

It seems like the polymorphism gets broken and the references are totally messed up after renaming. It compiles without error, it runs without error but it somehow crashes in the print report.vi with a missing activex reference.