Load TypeDef/Control from a Fixed Path

[Vaibhav]

Hello all,

I tried to search but couldn't find this topic. But I doubt if this has not been discussed already, in the LabVIEW forum.

In my application, I have used customized controls. The application has several "parts" and each of them use "similar" (but not necessary the same) TypeDef controls that I have customized to suite the part.

LabVIEW's good feature is that even if the control file is moved to another path, it finds and loads it, with a warning. However in my case, I need to turn this feature off, for some control file(s). Is that possible?

I am using control files with same name, but they are expected for different "calling" VIs. If this is not considered a good practice, I may change names of each control file, adding a prefix/suffix of the calling application's name. Thus each control file becomes unique.

But still this will remain a question. Because of small and appropriate names, I often prefer them with a "typical" name that I would give for such a control. Like in each application we have a "Main" program. And what I faced, the problem, is when I loaded a VI, it automatically "used" a control (with the same name like of the one that this VI expects) that is already loaded (from a different path) by an already open another VI, although the expected control exists in its expected location. It showed a warning, but didn't ask "do you want to load the original or use the one from the memory?"

My question is, is it possible to have an "expected" path to be fixed, and not allow the VI to load the "recently" opened "same name" control as its expected control?

The feature is good, but in some cases, can we turn it off or not?

[Ben]

1) If they are different they should have different names (unless you are working in libraries where the name gets mangled to include the library names as a prefix)

2) Too unravel what you have....

a) Close all of your VIs and THEN open the right type def and then open the VIs that use it. LV will only open one copy of a VI or a control of a certain name at a time.

At this point your VIs will all be pointing at the correct type def.

b) Save all of your VIs that use that type def.

Now mixing in those ctrl of the same name can still be done but you will have to think ahead of LV.

When a VI is saved a path to the sub-VI (and ctl files) is saved in the VI so it can find them again. By doing that save the VIs are now pointing at the type def you "opened first". If is just one or two places then....

c) Close everything

d) open the "other control" and save it as new name.

e) open only the VI where you want to use the "other" and skip passed finding the control and let them open broke.

f) Find all of the places that are broke and replce with your re-named control.

g) Save so they are pointing at the new "other".

Fixing these types of crosslinking issue are all variasions on the theme of "only one VI of a name in memory at a time".

make backups first!

have fun,

Ben

[Vaibhav]

Hi,

Thanks for the quick yet detailed reply.

In my post I mentioned that renaming (giving unique names) is the proper way, but I was looking for some way to load a control ONLY from the path that is expected (stored in the caller VI).

But what you said "only one VI of a name can be in the memory at a time" makes sense and gives reason for why it wouldn't happen what I want. The warning that is shown while loading the control from a different path (using the one which is in the memory already), looks more like "It's done, here is the message" rather than "do you want to load it?" so I don't feel like I have some way to stop it.

Thanks for the steps to rename the controls and repair VIs.

The good thing is that if I don't save the VI (after it loads/uses an unwanted control), and close everything, and if I open the VI again, it will load the correct control (the original setting). And for now, all my VIs are pointing to their respective controls. So even if I just rename all the controls on the harddisk (not thru LV), and open their VIs, it's going to show the broken controls which I will have to fix. Or do you think I should open the controls and rename them using LV?

[Ben]

Unless you are trying to break something (like above) always rename when the caller is open so they "see" the change and THEN save the callers.

Ben

[Vaibhav]

True!

Thanks again.

[Mark_Yedinak]

I would also receommend using LV projects for your applications and projects. They make resolving cross linking much easier.

[Vaibhav]

Thanks for the comment Mark! 

Yes, that's true.

But what about stopping the undesired connections from messsing up the program in the first place? I mean, before building a project.

By the way, if we open a program through Project Explorer, it would still not allow to open a file whose twin brother is already in the memory. But will it shout before assuming a new connection on its own?

[Mark_Yedinak · Accepted solution]

---

Vaibhav wrote:

Thanks for the comment Mark! 

Yes, that's true.

But what about stopping the undesired connections from messsing up the program in the first place? I mean, before building a project.

By the way, if we open a program through Project Explorer, it would still not allow to open a file whose twin brother is already in the memory. But will it shout before assuming a new connection on its own?

---

No, the projects will work like libraries. Once you have the VIs as part of a project its name gets modified internally, or at least how to locate it on disk, which allows you to open both projects at the same time. The trick here is to do your work through the projects rather than opening the VIs directly. As long as you work through the projects themselves you can use two different VIs or typedefs with the same name located in different directories at the same time. That is as long as each one is the member of a different project.

[Vaibhav]

Sounds great!

Something that would allow me to keep the names as they are.

Thanks a lot!

I just changed the control names after suggestion from Ben. Because that seems to be a safe practice in general. In fact, I usually do not work from project explorer. But what you said is THE solution for my original question.

See Ben, once again, I need to mark 2 solutions.

[Ben]

---

Vaibhav wrote:

...

See Ben, once again, I need to mark 2 solutions.

---

Mark's is more complete and does exploit the project power.

So his is the best solution.

Ben