Classes and Separating Script Files

nicstt

Just wondering if it is possible to seperate a script into separate files?

I know a function expression is used to declare a constructor functions; can and if so, how, can these be separated between script files?

Would make files much easier to write and debug.

Praxis

nicstt said:

Just wondering if it is possible to seperate a script into separate files?

I know a function expression is used to declare a constructor functions; can and if so, how, can these be separated between script files?

Would make files much easier to write and debug.

Yes, it is.  This post shows a simplified example: How best to structure a large script project?

Be aware that (so far, in my experience), if a file contains a Constructor (as the above example MyTypeDefA.dsa and MyTypeDefB.dsa files do), then the "include" command must be placed outside (i.e. before) the main routine in the .dsa file that "includes" the file - otherwise the Constructors are "not found" within the main routine.  If a .dsa file contains no Constructors (e.g. just a bunch of utility functions), then it can be "included"  within the main routine.

Hope this helps.

P.

 

Praxis

Some details of a more practical example:  My current main project has:

• A main file .dsa that "includes" all the following:
• 8 .dsa files, each containing the code for 1 Tabbed Page of the main dialog. (none of these contain Constructors, and are "included" within the main routine at the point where they otherwise would have been written in-line)
• 7 .dsa files, each containing the code for a Library of related routines (e.g. Utilities, Simulation stuff, G2F stuff, G8F stuff, etc.).  Some of these contain Constructors - e.g. the Utilities .dsa implements all its data and functions as members of a new class (derived from Object), and the .dsa creates a Global instance of that class, named g_prxUTY_lib  The utilities are accessed everywhere else in the project like this e.g:  print( g_prxUTY_lib.getCurrentDateTimeString() );  The Utilities can be accessed within all the other .dsa files, because the Utilities .dsa is "included" at the very start of the main .dsa file.

 

 

nicstt

Cheers appreciate the post.

I'm curious; can they be encrypted?

Praxis

nicstt said:

I'm curious; can they be encrypted?

I don't know - I've never tried encrypting scripts.

But I'd be very surprised if they can't be encrypted.

P.

nicstt

I seem to be having trouble; I even tested it on two very basic files.

The file to be include:

var test = "test";

 

The file that includes the file

include("test.dsa");print(test);

 

Stack trace "can't find the variable"; they are both in the same path/folder

 

hphoenix

nicstt said:

I seem to be having trouble; I even tested it on two very basic files.

The file to be include:

var test = "test";

 

The file that includes the file

include("test.dsa");print(test);

 

Stack trace "can't find the variable"; they are both in the same path/folder

 

Don't encrypted scripts use a different file type?  I thought they were like "test.dse" or such?

The 'include' statement probably needs the encrypted file name, not the unencrypted.

Or are you doing this with no encryption?  If that's the case, I'd probably use a relative directory path, like 

include("./test.dsa");

Or you could use the content manager methods to locate the file and get its absolute path and try that.

 

Richard Haseltine

Most likely this is a file location issue. See http://docs.daz3d.com/doku.php/public/software/dazstudio/4/referenceguide/scripting/api_reference/object_index/global - if you give a relative path, as you do above, it is going to be added to the path to your scripts folder.

Praxis

As Richard said, the include() command defaults to use locations relative to the DS Scripts directory.

At present I'm using absolute paths, like this:

// prxEXT.dsa           // Project Main Unit//---Global Utilities---// Get the absolute Path to this currently-executing Script:var g_prxEXT_ScriptPath = getScriptFileName().left( 1 + getScriptFileName().searchRev( '/' ) );//---Global INCLUDE files---// We assume that these 'include' Scripts are in the same directory as this Script://  Because these units contains Constructors, they must be included only at the outermost level of a main script:include( g_prxEXT_ScriptPath + 'prxOBJ_lib.dsa' );    // TprxOBJ_Object: PRX BASE Object facilities// Requires: Nothinginclude( g_prxEXT_ScriptPath + 'prxUTY_lib.dsa' );    // TprxUTY_lib: PRX library of General-purpose Utilities// Requires://  prxOBJ_lib.dsa// Exports://  var g_prxUTY_lib    : TprxUTY_lib//---Main Routine---// Define an anonymous function;// serves as our main routine,// limits the scope of variables(function(){  // ...etc.  //  Reference g_prxUTY_lib.* members here.// Finalize the function and invoke})();

There is a way to not have to specify whether the include file is a .dsa (un-encrypted) or .dse (encrypted), using DzScript

---

String : getScriptFile( String filenameWithoutExtension )

Parameter(s):

• filenameWithoutExtension - The path to the file, minus the '.' and the extension

Return Value:

• The path of the file, with extension, of the script found. Otherwise, an empty String.

 

I have not tried it, but the Samples contain some examples of its use, e.g.:

Samples: Lesson Strips

http://docs.daz3d.com/lib/exe/fetch.php/public/software/dazstudio/4/referenceguide/scripting/api_reference/samples/education/lesson_strips/ds_4_lesson_strip_example.zip

e.g. The .zip above contains a 0.dsa containing this code:

var oFile = new DzFileInfo( getScriptFileName() );var oDir = new DzDir( String( "%1/%2" ).arg( oFile.path() ).arg( oFile.baseName() ) );if( oDir.exists() ){  var sPopupPath = String( "%1/Popup" ).arg( oDir.path() );  var oScript = new DzScript();  sPopupPath = oScript.getScriptFile( sPopupPath );  if( sPopupPath )  {    var oPopup = MainWindow.toggleUIPopUpWgt( sPopupPath, Button );    if( oPopup )    {      LessonStrip.setButtonChecked( Button, true );    }  }}

 

nicstt

Thank you everyone.

Absolute paths works; I'll check out the links, and no, not encrypted at this stage.