[Closed] include() fails on first try, succeeds on second?
I am including a script, whose sole content is a string of the absolute path to another script.
I am trying to use a combination of fileIn and include like so:
fileIn (include “LibraryPath.ms”)
The problem is, when I FIRST open Max, and have not run any scripts yet, this fileIn always fails on the first try, saying:
Compile error: Can’t find include file: LibraryPath.ms
– In line: fileIn (include “LibraryPath.ms”
HOWEVER, without doing anything, if I try running the script a second time, the fileIn succeeds! Why can’t it find the include file on the first try?
I’m probably missing something basic here about how includes work or how max stores scripts in memory, but I’m afraid I just don’t know. Any help would be appreciated.
I just tried the syntax you have used and it doesn’t work on my max2012.
This works –> filein “whateverfilename.ms”
This works –> include “whateverfilename.ms”
This FAILS –> filein(include “wahteverfilename.ms”)
Also – is your “librarypath.ms” in the same directory as your calling script? I usually use explicit pathnames. If you need to, you can dynamically build them like (getdir (#scripts) + “rest\of\path”)
Jason, thanks for the reply.
Yes, the script being called is in the same directory. I’ve been trying to keep the projects modular (to the degree that I know how, still learning!) since I’ve seen our tools change locations over time.
My goal to accomplish this was store the absolute path to the rest of my library stuff in a file, called LibraryLoader.ms… this path would then get fileIn’d upon including it, as you saw.
I get the same results as you with added note that the fileIn works after running the script a second time.
Theoretically, the include will grab the contents of LibraryLoader.ms, which is just a string, nothing else in the file. This string is a valid file path.
Then, for the fileIn, it should be trying to load that string that was just included. Unfortunately it just doesn’t work.
I’ve moved on to a new approach, a little chain of fileIn calls. I fileIn LibraryLoader.ms, which in turn fileIn’s the library script which I use as my interface to all my other utility scripts (which are in the same directory as the loader!)
It’s weird, but hey it works, and keeps the projects modular. Now, the only thing I would ever have to update is the string found in LibraryLoader.ms, should the projects need to get moved again =)