What could cause the rename module utility to fails?

[TiTou]

I'm trying to rename a clonable module that I created with DQMH 4.2.

It takes a while and fails to rename my module and I get no message telling me what went wrong.

I have 2 testers for this module, on that for Windows and one for RT, I don't know if this makes things different when the scripter relinks the renamed public API VIs calls of the tester.

Any idea what the issue could be?

Running LV 2018 SP1 32 bit

[FabiolaDelaCueva]

Hi TiTou,

Do you have other libraries inside your DQMH cloneable library? 

Can you reproduce the problem with a DQMH cloneable module that has not been modified at all but includes the RT API Tester? I have tried this on my end and the module and the regular tester got renamed. I did notice that the RT API Tester was not renamed (I have filed an issue DQMH-608 on our end to fix this) but everything else worked.

If you could share the code with us, we could look into what is going wrong on your end.

Regards,

Fab

[TiTou]

---

@FabiolaDelaCueva  a écrit :

Do you have other libraries inside your DQMH cloneable library? 

---

Hi Fab,

My module has some NI lvlib in it's dependencies and is also calling other lvlib that I created and placed next to my DQMH module because several DQMH module call these libraries.

But if mean have I got an lvlib inside the DQMH module's lvlib, then no.

I didn't even know that LabVIEW would accept a lvlib inside a lvlib, I guess it's to give scope flexibility.

Renaming a newly created clonable module works fine.

I'll see if I can isolate and share some code, but it's not critical, I can leave without renaming my module.

Thanks for answering so fast 🙂

[FabiolaDelaCueva]

keep us posted!

Yes, you can have lvlibs inside other lvlibs, check out the "Clone Registration.lvlib" inside all DQMH Cloneable Module libraries 

[TiTou · Accepted solution]

---

@FabiolaDelaCueva  a écrit :

Yes, you can have lvlibs inside other lvlibs, check out the "Clone Registration.lvlib" inside all DQMH Cloneable Module libraries 

---

Oh, I see, so each DQMH module has it's own Clone Registration.lvlib which is the default one when you create a module but thanks to name mangling it can be modified in each module, thus replacing dynamic dispatch without OOP, right? (I mean, it's not as good as dynamic dispatch but hey...)

---

@FabiolaDelaCueva  a écrit :

keep us posted!

---

After a few more tries I could rename my module and eventually find out that the new module name I wanted to use was already taken by a low level lvlib dependencies in the VI.lib... silly me.

So we can't have two libraries with the same name, trying to do that causes the rename module utility to fail. Shocking!

[FabiolaDelaCueva]

Glad you figured it out. We will look into what we can do to improve error reporting so the tool informs you when you are trying to rename using a name that already exists.

---

@TiTou wrote:

---

@FabiolaDelaCueva  a écrit :

Yes, you can have lvlibs inside other lvlibs, check out the "Clone Registration.lvlib" inside all DQMH Cloneable Module libraries 

---

Oh, I see, so each DQMH module has it's own Clone Registration.lvlib which is the default one when you create a module but thanks to name mangling it can be modified in each module, thus replacing dynamic dispatch without OOP, right? (I mean, it's not as good as dynamic dispatch but hey...)

I would call it name spacing instead of LabVIEW mangling.

A LabVIEW class is just another type of project library. One that cannot have other libraries within.

One of the multiple things that makes dynamic dispatch possible is name spacing. It allows us to have VIs with the same name in different libraries.

The clone registration library in the Cloneable DQMH modules allows the Module to keep track of how many instances of the DQMH module are currently running and which of those instances is the first instance. 

Regards,

Fab