Why TS search the directories for LV modules called using relative paths?

[MimiKLM]

Let me check once again...

[dug9000]

---

@Garvacious wrote:

"If you specify your code modules as:

..\Code Files\Code I Want To Call.vi

Then you will get the behavior you are asking for because that path is relative to your sequence file."

-That only works if your code files folder is a child folder of your Sequence File folder, like:

Sequence File Directory\Code Files\Code I Want To Call.vi

...if your code is in a directory parallel to your sequence file directory, or in a completely different place on your hard drive, then that won't work.

So, I guess that relative paths DO work, but in a limited way.  Otherwise you must use the search directory method.

---

the ".." means go up one directory so it should work.

-Doug

[MimiKLM]

OK. With "..\" works.

However, the directory still have to be in the search directories.

So, we go back to sqare. Why it is done like that? Why the current sequence file directory must to be in the search directories to secure calling the VIs using relative paths?

[Norbert_B]

Without having any official backup, i simply answer: Because the design decision was done in that way.

To argument for the design decision:

Why should a developer create special rules if a general approach also solves these cases? Why should a general approach be set aside in order to create a collection of special rules and cases to address?

Search Directories work in any situation, they are a general approach. Differing "pure relative path" vs. "when do i look elsewhere if relative path is not met" are special rules which require additional work and make things complex.

Granted, design decisions like this might be annoying for some developers, but for most, it simply works....

Norbert

[MimiKLM]

How big do you think is the difference between loading module which is called with absolute path and the module called with relative path with searching fearure obligatory enabled?

[dug9000]

---

@MimiKLM wrote:

OK. With "..\" works.

However, the directory still have to be in the search directories.

So, we go back to sqare. Why it is done like that? Why the current sequence file directory must to be in the search directories to secure calling the VIs using relative paths?

---

Each sequence file's directory does not need to be explicitly in the search directories. There is already a default search directory which means "relative to the current sequence file's directory" and it's there by default and the first location searched. It's treated like a search directory for added flexibility, but functionally I think it's no different than what you are asking for. Though perhaps I am misunderstanding what you are asking for. I agree in many cases, relative to the sequences file is the best way to go, however some customers prefer the added flexibility of being able to put their code modules in completely separate locations from their sequence files and define search directories to look for them. TestStand should work well with either use case, either relative to sequence files, or custom search directory locations. Is there a particular problem that search directories are causing for you?

-Doug

[dug9000]

Also, search directories provide the following additional functionality:

1) For step types, which exist outside of (or really in multiple) sequence files, it's nice to be able to find their substep code modules using a search directory rather than having to use an absolute path.

2) Search directories allow for the possibility of overriding files by placing them in an earlier search directory. TestStand uses this functionality by default for things under the Components directory. There is a public components directory where, if you put code modules and sequence files there, you can override the default implementations.

[MimiKLM]

I just not OK with the situation in which I have to search for something which I already defined where it is.

Search means try to find something by looking or otherwise seeking carefully and thoroughly. 

So it looks like I have to use something obligatory which is not needed in my situation, as it is nothing to search.

I don't know how much more load it causes for the environment, but I think the cost could be significant. Why I can not just not to use this feature still calling modules using relative paths?

[dug9000]

---

@MimiKLM wrote:

I just not OK with the situation in which I have to search for something which I already defined where it is.

Search means try to find something by looking or otherwise seeking carefully and thoroughly. 

So it looks like I have to use something obligatory which is not needed in my situation, as it is nothing to search.

I don't know how much more load it causes for the environment, but I think the cost could be significant. Why I can not just not to use this feature still calling modules using relative paths?

---

If the file exists at the specified path relative to the sequence file, there is very little difference between what you are asking for TestStand to do and what it actually does, and very little overhead involved. For non-recursive search directories (which most of them are and the "current sequence file directory" definitely is) all TestStand is doing is taking the directory and appending the specified relative path to it and seeing if the file does in fact exist at that location (a single API call). If the file exists relative to the current sequence file directory TestStand will succeed on the first try. So, though it's called a search, the first thing TestStand tries is exactly what you are asking for it to do, it assumes the path is relative to the sequence file and sees if it exists at that location, if so, it's done. That's the file that gets used. So basically, the first thing TestStand tries by default is exactly what you are asking for it to do. The only difference is if no such file exists at that location, it also tries some additional things.

Also, this searching is only done at load time, which for most modules is at the beginning of the execution. The module is then, by default, not unloaded until the sequence file and execution are closed which for most systems isn't until the system is being shutdown.

Hope this helps clarify things,

-Doug

[MimiKLM]

---

@dug9000 wrote:

---

@MimiKLM wrote:

I just not OK with the situation in which I have to search for something which I already defined where it is.

Search means try to find something by looking or otherwise seeking carefully and thoroughly. 

So it looks like I have to use something obligatory which is not needed in my situation, as it is nothing to search.

I don't know how much more load it causes for the environment, but I think the cost could be significant. Why I can not just not to use this feature still calling modules using relative paths?

---

(...) all TestStand is doing is taking the directory and appending the specified relative path to it and seeing if the file does in fact exist at that location (a single API call). If the file exists relative to the current sequence file directory TestStand will succeed on the first try. So, though it's called a search, the first thing TestStand tries is exactly what you are asking for it to do, it assumes the path is relative to the sequence file and sees if it exists at that location, if so, it's done. That's the file that gets used. So basically, the first thing TestStand tries by default is exactly what you are asking for it to do. The only difference is if no such file exists at that location, it also tries some additional things.

---

OK, I'm happy with the explanation. It could be good your explanation above could be in the help file first af all.

The word "search" is a bit confusing in this context.

Thanks.