Using the include() statement
Richard Penney
Posts: 41
In the script I'm working on, I use the include statement at the top of the script to load a dsa, file which is similar to loading a DLL in C++. It works fine, and I can call functions within it from the main script.
In addition, I would like to dynamically include scripts that are listed in a text file. The reason for this is to support extensions which I might want to create down the road, and offer my users the extended functionality.
I've attempted to do this, but when I iterate through the file collection, the include statement fails. Example: include( sNextModule );
Anyone have a clue as to how this could work?
Comments
Global::include() assumes that if sNextModule is a relative path, then it is relative to the default script path App.getScriptsPath()
You can override this behaviour by explicitly specifying sNextModule as an absolute path.
For more discussion about include(), see these threads:
https://www.daz3d.com/forums/discussion/269626/classes-and-separating-script-files
https://www.daz3d.com/forums/discussion/comment/908906/#Comment_908906
If you intend the inlude()ed files to be in the same directory as your main script, then you will probably use Global::getScriptFileName() to get the relevant Path: Be aware that in DS v4.11, if you Re-Load the main script, or modify it in the Script IDE, then getScriptFileName() will return "" and so that mechanism won't work until DAZ fixes this bug. For details see: https://www.daz3d.com/forums/discussion/333656/bug-in-ds-v4-11-0-383-dzsireloadaction-sets-getscriptfilename
P.
Many thanks Praxis. Actually, I was using absolute paths. When it failed to work, I changed the approach to the following:
This worked! And I was able to call into the library module from the main script. But I'm interested in the idea referenced in your links, namely, wrapping a module's functions in a class object.
As an old C++ programmer, I was accustomed to using namespaces to avoid conflicts between DLLs having the same function names and signatures. I think you may have given me a way to emulate that behavior. I just need to figure out how to do that.
Thanks again.
Sorry folks. The code snippet I placed in my last post was not the most current. But it serves to gets the point across.
You're welcome.
If you're going to uses classes and inheritance in DAZ Script, you may want to look at this thread: https://www.daz3d.com/forums/discussion/231026/simple-explanation-for-a-c-developer-classes-inheritance
And as a general tip, rather than using the DAZ Forum search box, you will have better results using Google to search site:daz3d.com/forums/
P.
Thanks for the link, Praxis. I'll be experimenting with class inheritance today.
Hey folks, I've been cooking up some new stuff.
Continuing with the subject of dynamically loading library scripts from a project's include directory, I'd like to share the results.
Let's say you include a module named Library1.0.dsa, and it has a function named helloWorld() as well as a function named fooBar().
When helloWorld() is called, you see a message saying, "Hello from Library1.0".
Later, you're inspired to implement helloWorld() in a more robust fashion, so you create a new module named Library2.0.dsa.
The helloWorld function in this module displays a message saying, "Hello from Library2.0. I'm more capable than my prior version!".
Note that this module has no function named fooBar().
From your main script, call hellWorld(). You'll see the extended message from Lbrary2.0.
Next call fooBar(). You'll see whatever message you added to that function in Library1.0.
In summary, by using incremental version numbers for your library files, the dynamic loading operation I explained earlier in this thread will load every file in a directory, but only the latest versions of functions will be loaded. If later versions choose not to override a function in a previous version, the previous function remains loaded and accessdible.
I hope this proves to be of some help to folks just getting started with DS Scripting.
Nice tip Richard..... I didn't know that.... handy....