Integration SDK 4.10c Errata
Fixes Affecting Users of the ScriptEase ISDKs

• 4.10c API - latest update: March 22, 2000

• 4.10c, both ISDK/C and ISDK/Java - latest update: September 29, 2000
  

• 4.10c documentation - latest update: Dec. 3, ' 99

• Cleanup problems after conversion error messages
• MSVC6 bug with realloc
• Problem with Unix source installations during SE initialization
• Breaking out of inner for...in loop causes infinite loop
• Debug-time warnings with jseCreateCodeTokenBuffer playback
• Undefined statements not flagged as using undefined variable
• Three Clib functions not working
• Changes to COMOBJ.CPP (Link Library)
• Attributes changing on literal strings
• jseInterpret() may return true with run-time error
• Syntax errors during compilation may cause problems
• Calling an object that's not a function with no _call or _construct
• Incorrect error message line numbers when interpreting from a text source
• jseGetFileNameList() with pre-compiled tokens
• Application Error with COMOBJ
• Deref variable not making space for new element
• FindNames with protected-memory systems
• JseCallFunction() and MayIContinue
• Remote debugger hanging under Windows
• SECode_Stack_Push
• ToolkitAppPrintError - No unicode
• Alert about defineXXX() Functions
• Memory Access While Deleting Call Structure fix
• eval() function and JSE_MULTIPLE_GLOBAL
• Implicitparents bug fix
• HTML-style comments

  For Both ISDK/C and ISDK/Java, version 4.10c

• Null-pointer exception when using _put on global variable
• Error reading pre-compiled floating-points
• Functions not callable after parsing error
• Problems executing pre-compiled code
• incorrect error message for wrong number of parameters
• Invalid line numbers or breakpoints
• Parsing errors
• ISDK incrementing dynamic object
• Using "Delete" Operator On Non-Reference Var
• Changing The Global Object

  version 4.10c :
      (may apply to earlier versions)

• Code under “Methods” in SE JavaScript chapter
  A correction to the section “Methods - Assigning Functions to Objects”
  in the ScriptEase JavaScript language chapter of the ISDK
  (and all ScriptEase) manuals.

• New example of NULL data type
  In the ISDK manual's "ScriptEase JavaScript" chapter,
  under DataTypes/Special Values/Null

The Details

for 4.10c --

• Cleanup problems after conversion error messages
  

  Problem: Crashes may occur during cleanup after some conversion errors. For example, either of the following script lines may produce such an error:

  
  
         for ( var a in (void 0) ) ; 
  
  
  
         var foo;  ToObject(foo); 
  
  

  Fix: in FUNCTION.C function functionFinishCall() (at about line 539) change lines:

  
  
      Var *it = SECODE_STACK_POP(thestack); 
  
      VAR_REMOVE_USER(it,call); 
  
  

  to,

  
  
      Var *it = SECODE_STACK_POP(thestack); 
  
      if ( it != NULL ) 
  
      { 
  
         VAR_REMOVE_USER(it,call); 
  
      } 
  
  

  This fix may cause your assertions to fail if you rely on the return variable of jseCallFunction() and jseInterpret() to be set to NULL on error.

  So also change these lines in JSELIB.C.

  In Function jseInterpret() at about line 434, change:

  
  
      else 
  
      { 
  
         if( ret!=NULL ) VAR_THOROUGH_REMOVE_USER(ret,jsecontext); 
  
      } 
  
  

  to,

  
  
      else 
  
      { 
  
         if( ret!=NULL ) VAR_THOROUGH_REMOVE_USER(ret,jsecontext); 
  
         if ( retvar != NULL ) 
  
            *retvar = NULL; 
  
      } 
  
  

  and in function jseCallFunction at about line 1711 change:

  
  
      if( retvar && retbool ) *retvar = packageVariable(ret,FALSE); 
  
  

  to,

  
  
      if( retvar != NULL ) 
  
         *retvar = retbool ? packageVariable(ret,FALSE) : NULL; 
  
  

• MSVC6 bug with realloc (ISDK/C 4.10c)

  Problem: Microsoft’s MSVC6 has a bug in the realloc() function.

  Fix: If you’re building with MSVC6 and getting errors related to memory management, specifically to realloc(), Microsoft describes the bug at this location:

  http://support.microsoft.com/support/kb/articles/q225/0/99.asp

• With Unix source installations during SE initialization (ISDK/C 4.10c)

  Problem: Some 4.10c Unix source installations crash as the ScriptEase engine initializes. If this happens on your system, e-mail -

      Tech Support

  for the unix_410c_update.zip files. These files overwrite some of the existing source.

• Infinite loop from breaking out of inner for...in loop

  Problem: breaking out of an inner for...in loop causes infinite recursion.

  Fix: in STATEMENT.C function secompileFor(), at the end of this “if” block:

  
  
     if( codeGetType(this->srcCodes)==statementIn ) 
  
  

  are these statements:

  
  
     secompileAddItem(this,gotoForIn,ptr2); 
  
     secompileAddItem(this,popIterator); 
  
     secompileEndLoop(this,secompileCurrentItem(this),ptr3,label); 
  
  

  They should be re-ordered in this way:

  
  
     secompileAddItem(this,gotoForIn,ptr2); 
  
     secompileEndLoop(this,secompileCurrentItem(this),ptr3,label); 
  
     secompileAddItem(this,popIterator); 
  
    

• Debug-time warnings with jseCreateCodeTokenBuffer playback

  Problem: Playback of pre-compiled code (created with jseCreateCodeTokenBuffer) represented as strings (e.g., "0") may trigger internal debug-time warnings.

  Fix: In srccore\token.c, line 407 (part of tokenReadString() ), the allocation line should be changed to:

  
  
     str = jseMustMalloc(jsechar,((size_t)len+1)*sizeof(jsechar)); 
  
  

  The right after the following for loop (line 421), add:

  
  
     str[i] = '\0'; 
  
  

• Undefined statements not flagged as using undefined variable

  Problem: Nonsense or undefined statements are not flagged as using an undefined variable.

  Example: The following script should generate the error "NonsenseVariable undefined" at run-time:

  
  
    function foo()
  
    {
  
        NonsenseVariable;
  
    }
  
  

  Fix: If this is a major problem, it can be fixed by turning off the peephole optimizer (#define JSE_PEEPHOLE_OPTIMIZER 0 in SECODE.C) but the resulting script will run a little bit slower.

• Three Clib functions not working Problem: The following functions of the Clib object do not work as they are supposed to in all situations:

  
  
  mktime()
  
  exit()
  
  strtol()
  
  

  Fix: Contact http://support.nombas.com/ if you need to use one of these functions.

• Changes to COMOBJ.CPP

  Problem: Some COM object methods are not getting called with The parameters which were passed to them, or are being called multiple times.

  Fix: Many parts of COMOBJ.CPP had to be reworked. Contact http://support.nombas.com/ for the new version of COMOBJ.CPP.

• Attributes changing on literal strings

  When literal strings are returned from a function, their attributes may change.

  Fix: In VARUTIL.C function convert_var_ToString() change the case for VObject from:

  
  
     if( VAR_TYPE(vartemp)==VString )
  
     {
  
        new_var = vartemp;
  
     }
  
  

  to:

  
  
     if( VAR_TYPE(vartemp)==VString )
  
     {
  
        JSE_POINTER_UINDEX bmax;
  
  
  
        /* need to copy the data */
  
        new_var = constructVarRead(call,VString);
  
        bmax = varGetArrayLength(vartemp,call,NULL);
  
        varPutStringLen(new_var,call,(jsechar _HUGE_ *)
  
                        varGetData(vartemp,0),bmax);
  
        VAR_REMOVE_USER(vartemp,call);
  
     }
  
  

• jseInterpret() may return true with run-time error

  Problem: jseInterpret() may encounter a run-time error and call the application's error-reporting function, but still return True.

  Fix: In INTERPRT.C function interpretTerm() following this statement (at about line 354):

  
  
     assert( InterpretCall->pReturnVar==NULL );
  
  

  add this line of code:

  
  
     callSetReasonToQuit(call,callReasonToQuit(InterpretCall));
  
  

  
  

• Syntax errors during compilation may cause problems

  Problem: syntax errors during compilation may result in data corruption, cleanup errors, and crashes.

  Fix: in SECODE.C are two fixes. First is in secompileCompile(). Change:

  
  
     secompilePeephole(&This,c);
  
  

  to,

  
  
     if( success )
  
        secompilePeephole(&This,c);
  
  

  Second fix: in secompileAddItem(), after comment "/* if tokens have switched line numbers..." change:

  
  
  
  
     if ( This->NowCompiling
  
  

  to,

  
  
     if ( This->NowCompiling && This->varsAlloced!=0
  
  

• Calling an object that's not a function with no _call or _construct

  Problem: Calling an object that is not a function, and has no _call or _construct functions, will dereference a NULL pointer and crash. For example: "Math();" and "new Math();" would crash.

  Fix: in SECODE.C function callFunction() this statement appears twice:

  
  
    call_func = function->stored_in;
  
  

  In both cases this should be rewritten as:

  
  
    if ( NULL != function )
  
      call_func = function->stored_in;
  
  

• Incorrect error message line numbers when interpreting from a text source

  Problem: When interpreting source directly from text (not from a file) error message line numbers can be off and calls to jseBreakpointTest() will not report all valid breakpoint line numbers.

  Fixes:

  in BRKTEST.C function BreakpointTest() change line:

  
  
    jsebool right_file = False;
  
  

  to,

  
  
    jsebool right_file = WantedName[0] ? False : True;
  
  

  and in SOURCE.C function sourceNewFromText() remove this line:

  
  
    ++(SOURCE_LINE_NUMBER(This));
  
  

• jseGetFileNameList() with pre-compiled tokens

  Problem: jseGetFileNameList() returns no file names when playing back pre-compiled tokens.

  Fix: If you need a fix for this in 4.10c, get the code change from Nombas.

• Application Error when using COMOBJ

  Problem: If an Application Error is occurring when using the COMOBJ link library, the following code fix in srclib\comobj\comobj.cpp may solve it.

  Fix: the function ConvertReturnedVariant needs to take an extra parameter 'wName' of type _bstr_t. A corrected version of ConvertReturnVariant is shown here:

  
  
     static void NEAR_CALL
  
  ConvertReturnedVariant(jseContext jsecontext,VARIANT
  
                         &vRet,_bstr_t wName
  #                      if !defined(NDEBUG)
                            ,COMdispatchList *clist
  #                      endif
                        )
  {
     jseVariable newobj;
     LPDISPATCH pdisp;
  
     switch(vRet.vt)
     {
        case VT_BOOL:
           newobj = jseCreateVariable(jsecontext,jseTypeBoolean);
           jsePutBoolean(jsecontext, newobj, V_BOOL(&vRet));
           jseReturnVar(jsecontext,newobj,jseRetTempVar);
           break;
        case VT_BSTR:
           newobj = jseCreateVariable(jsecontext,jseTypeString);
           jsePutString(jsecontext, newobj, (char*)V_BSTR(&vRet));
           jseReturnVar(jsecontext,newobj,jseRetTempVar);
           break;
        case VT_EMPTY:
           break;
        case VT_I4:
        case VT_UI4:
        case VT_UI2:
        case VT_I2:
           newobj = jseCreateVariable(jsecontext,jseTypeNumber);
           jsePutLong(jsecontext, newobj, (long)V_I4(&vRet));
           jseReturnVar(jsecontext,newobj,jseRetTempVar);
           break;
        case VT_R4:
           newobj = jseCreateVariable(jsecontext,jseTypeNumber);
           jsePutNumber(jsecontext, newobj, (double)V_R4(&vRet));
           jseReturnVar(jsecontext,newobj,jseRetTempVar);
           break;
        case VT_R8:
           newobj = jseCreateVariable(jsecontext,jseTypeNumber);
           jsePutNumber(jsecontext, newobj, (double)V_R8(&vRet));
           jseReturnVar(jsecontext,newobj,jseRetTempVar);
           break;
        case VT_DISPATCH:
           // this get returned an new dispatch object
           pdisp = V_DISPATCH(&vRet);
  
           CreateComData(jsecontext,&newobj,wName,pdisp
  #                   if !defined(NDEBUG)
                         ,clist
  #                   endif
           );
           jseReturnVar(jsecontext,newobj,jseRetTempVar);
           break;
     } //switch
  }
  

  Also, all calls to ConvertReturnedVariant need to pass this new paramater:

  
  
    ConvertReturnedVariant(jsecontext,vRet,wName
  
  #                            if !defined(NDEBUG)
  
                                  ,cdata->TrackList
  #                            endif
  
  

(The following first published August, 1999, or earlier.)

• Deref variable not making space for new element

  Problem: deref variable (i.e., a[1] in cfunction where a is string) was not making space for the new element being assigned. So a[0] = 1 doesn't grow to include a 0th element if it did not already.

  Fix: in VARWRITE.C function varPutNumber(), after:

    if( varIsDeref(this) )

  add this line:

    varmemValidateIndex(this->varmem,this->offset_or_createType,
        1,False,False);




• FindNames with protected-memory systems

Problem: the FindNames function can crash protected-memory systems.

Fix: The simplest fix is to add this statement at the top of -

GetStringTableEntry() in CALL.C:

  if ( NULL == entry ) return NULL;





• JseCallFunction()and MayIContinue

Problem: if calling jseCallFunction() and MayIContinue returns
false, then contexts may not be cleaned up.

Fix: In function.c/functionFullCall(), a short loop must be
added to end all sub-functions when MayIContinue() returns false.
Contact Nombas for this code if you need to add it to 4.10C.




• Remote debugger hanging under Windows

Problem: Debugging session hangs when using remote debugger on
the Windows platform.

Fix: in PROXY.C, replace the functions DoWaitForReadLoop,
WaitUntilReadyToRecv, and WaitUntilReadyToSend with the
following:

static void NEAR_CALL
DoWaitForReadLoop(struct tcpipInfo *ti)
{
#if defined(__JSE_WIN16__) || defined(__JSE_WIN32__)
  MSG msg;
#endif

  while( !ti->GotWmSocketReadReady &&
    !ti->GotWmSocketCloseReady )
  {
# if defined(__JSE_WIN16__) || defined(__JSE_WIN32__)
    if( !GetMessage(&msg,0,0,0) ) return;
    TranslateMessage(&msg);
    DispatchMessage(&msg);
# elif defined(USE_MAC_WINSOCK)
  NMIdle();
# endif
  }
}

static void NEAR_CALL
WaitUntilReadyToRecv(struct debugMe *debugme,SOCKET socket)
{
  struct tcpipInfo *ti =
    (struct tcpipInfo*)jseDbgInfo(debugme);

  unsigned long non_blocking = 0;

  DoWaitForReadLoop(ti);

  ti->GotWmSocketReadReady = False;
  ti->GotWmSocketCloseReady = False;

  ioctlsocket(socket,FIONBIO,&non_blocking);
}

static void NEAR_CALL
WaitUntilReadyToSend(struct debugMe *debugme,SOCKET
  socket)
{
  struct tcpipInfo *ti = (struct tcpipInfo*)jseDbgInfo(debugme);

  unsigned long non_blocking = 0;

  ti->GotWmSocketWriteReady = True;
  ti->GotWmSocketCloseReady = False;

  ioctlsocket(socket,FIONBIO,&non_blocking);
}

The function DoWaitForWriteLoop() may be commented out or
removed from the code altogether.

• SECode_Stack_Push

Problem: SECODE_STACK_PUSH() assumes compiler errors:

In a few cases, the use of the SECODE_STACK_PUSH macro makes
invalid assumptions about the C compiler. If your compiler has
this problem, then the engine will crash during initialization.

Fix: In function.c at about line 167, this code:

SECODE_STACK_PUSH(CallerCall->Global->thestack,
  functionFinishCall(this,CallerCall->pChildCall,
      InputVariableCount,ThisVar));

should become this code:

VarRead *ret;
ret = functionFinishCall(this,CallerCall->pChildCall,
    InputVariableCount, ThisVar)
SECODE_STACK_PUSH(CallerCall->Global->thestack,ret);

In secode.c line 2100 this code:

SECODE_STACK_PUSH(stack,do_op_delete(call,tmp));

should be:

VarRead *tmp2;
tmp2 = do_op_delete(call,tmp);
SECODE_STACK_PUSH(stack,tmp2);

and a few lines below that this code:

SECODE_STACK_PUSH(stack,do_op_typeof(call,tmp));

should be:

VarRead *tmp2;
tmp2 = do_op_typeof(call,tmp);
SECODE_STACK_PUSH(stack,tmp2);




• ToolkitAppPrintError - No-unicode

  Problem: Our default ToolkitAppPrintError function does not
  handle Unicode.
  
  Fix: The single statement in PRINTERR.C should become:

  fprintf_jsechar(stderr,UNISTR("Error %s\n"),
  ErrorString);




• Alert about defineXXX() Functions

Alert: It is possible that the defineXXX() functions, as prototyped in DEFINE.H, will read from memory not allocated by the application. This has not been found to produce an error in any system.

Fix: in DEFINE.C function defineAddLen() the line containing "memcmp" should be changed to:

if ( 0 == strncmp_jsechar(FindString,(*plink)->Find,FindStringLen)

• Fix For Memory Access While Deleting Call Structure

Problem: Invalid memory access while deleting a call structure.

Fix: Remove the following lines from the end of the callDelete() function in CALL.C

/* Don't restore a valid quit reason if
* calling a destructor failed -
* that's still a failure
*/
if( !callQuitWanted(this) )
callSetReasonToQuit(this,RememberReasonToQuit);



• eval() function and JSE_MULTIPLE_GLOBAL

The eval() function may not recognize the correct variables when using the JSE_MULTIPLE_GLOBAL option and your code is use jseGetGlobalObject() to modify the global variable. The problem is that eval() is modifying the global to the original value, and not the value of its own context.

Fix:
In srclib/ecma/ecmamisc.c, the function Ecma_eval. Right before the 'if ( !jseInterpret(...' line, the following should be added:

# if 0 != JSE_MULTIPLE_GLOBAL
jseSetGlobalObject(jsecontext,
jseGlobalObject(jsePreviousContext(jsecontext)));
# endif




• Implicitparents bug fix

(Note: this bug is probably important to only a few users, because very few probably use implicitparents or implicitthis on assigned methods of an object.)

Variable attributes may not be retained by methods assigned as members of an object. This is most likely a problem if you use the jseImplicitThis or jseImplicitParents attributes. SCOPE2.JSE in the test suite demonstrates this error.

Fix: Contact us at --
Tech Support

• HTML-style comments (<!--) are not recognized by the core interpreter. This type of comment can be added by assigning JSE_HTML_COMMENT_STYLE=1 in your compiler environment, and by adding the following code after the IS_WHITESPACE statement in the CompileFromText() function of CODE.C:
    #if defined(JSE_HTML_COMMENT_STYLE) \
     && (JSE_HTML_COMMENT_STYLE==1)
      if( src[0]=='<' && src[1]=='!'
       && src[2]=='-' && src[3]=='-' )
      {
        goto EndOfSourceLine;
      }
      else
    #endif

For both ISDK/C and ISDK/Java, version 4.10c

• Null-pointer exception when using _put on global variable

  Bug: When trying to assign a value to a member of an undefined variable, and there is an dynamic _put method assigned to the global variable, a null-pointer exception will be thrown. (SE:ISDK/Java 4.10c)

  Fix: In Operator.java at line 323 (in method do_op_structureMember), remove the line which reads:

   orig.VAR_REMOVE_USER(call);

  and in Var.java at line 93 (in method GET_READABLE_VAR), change this line:

   if ( membername==0 )

  to

   if ( VAR_HAS_DATA() )

• Error reading pre-compiled floating-points

  Bug: In SE:ISDK/Java 4.10 floating-point values may not be read correctly from pre-compiled bytecodes (i.e. bytes created with jseCreateCodeTokenBuffer).

  Fix: In TokenDst.java method ReadNumber() change this line
     val = 256*val+buf.at(ByteCount-i-1);
  to
     val = ( val << 8 ) | (buf.at(ByteCount-i-1) & 255);

• ISDK/Java parsing error leaves function in uncallable state

  Bug: In SE:ISDK/Java 4.10 if there is a parsing error while compiling a function that function is left in an uncallable state.

  Fix: The following code change will remove the function if compilation fails. In FunctionParms.java, near the end of method Delete() change this code:

     if ( !lfunc.ResolveVariableNames(pCall) )
  
        pSuccessFlag[0] = false;
  
  

  to this:

     if ( !lfunc.ResolveVariableNames(pCall) )
  
     {
  
        // function failed; so delete the variable that is this function
  
        VarRead funcVar = VarUtil.GetDotNamedVar(call,
  
                 call.session.GlobalVariable,
  
                 call.GetStringTableEntry(GetName()),
  
                 true);
  
        funcVar.VAR_REMOVE_USER(call);
  
        pSuccessFlag[0] = false;
  
     }
  
  

• Problems executing pre-compiled code

  Problem: When executing pre-compiled code, some scripts will run incorrectly or hang.

  Fix: in SECODE.JAVA change this line:

     int ag = AbsoluteGotoFromRelative(This.opcodes,
  
                                       This.opcodes[idx]);
  
  

  to this:

     int ag = AbsoluteGotoFromRelative(This.opcodes,
  
                                       This.opcodes[idx+1]);
  
  

• incorrect error message for wrong number of parameters

  (ISDK/Java 4.10)
  Problem: error message not printing correctly for wrong number of parameters to a function.

  Fix: In srccore/Call.java, line 3474, add the method:

       void Quit(String text,int num,String text2)
  
       {
  
          Error(text,num,text2);
  
       }
  
  

  In srccore/LibraryFunction.java, line 115, changes to:

             call.Quit(TextCore.INVALID_PARAMETER_COUNT,
  
                       VarCount,GetName(call));
  
  

  (This is approximately the 4th line in the Execute() method.)

• Invalid line numbers or breakpoints

  (for ISDK/Java 4.10c)
  Error: When interpreting from source text (instead of from file) the text in the first line is ignored. This can manifest as line numbers being invalid, breakpoints being off, or the script just acting wacky.

  Fix: In the file Source.java, method "Source(Source PrevSB, BytePtr SourceText)", delete these lines:

  
  
    if ( MemoryPtr.cursor > 0 ){
  
       MemoryPtr.shift(-1).setCharAt(0,'\0') ;
  
    }
  
    /* start at line 1 not 0 */
  
    pLine++;
  
  

  and replace these lines:

  
  
    int len = CStringLib.strlen(SourceText)+1 ;
  
    MemoryPtr = new BytePtr( len ) ;
  
    CStringLib.strcpy(MemoryPtr,SourceText);
  
  

  with these:

  
  
    int len = CStringLib.strlen(SourceText)+1+1/*beginning null*/ ;
  
    MemoryPtr = new BytePtr( len ) ;
  
    MemoryPtr.setCharAt(0,'\n');
  
      /* always for first line to be read */
  
    CStringLib.strcpy(MemoryPtr.plus(1),SourceText);
  
  

  
  

• Parsing errors

  Problem: Statements such as (SomeFunction)(); generate a parsing error.

  Fix: In CODE.C function CompileFromText(), "case '('", at about line 389, replace this statement:

  
  
     || EndFunctionCall == Type ) {
  
  

  with this statement:

  
  
     || EndFunctionCall == Type
  
     || EndEvaluationGroup == Type ) {
  
  

  The fix is nearly identical in the Java version of CODE.JAVA.

• ISDK incrementing dynamic object

  Problem: Using the increment or decrement operators on a property of a dynamic object (i.e., and object with _get or _put methods) may result in the variable being replaced by an undefined value. For instance, this script:

  
  
  var foo.x = 0;
  
   printf("foo.x++ = " + foo.x++);
  
   printf(" foo.x = " + foo.x);
  
  

  will print "0 undefined" if foo._get() returns a newly-created, temporary variable.

  Fix:
  in SE:ISDK/C --

  ..is in SECODE.C about 5 lines after the statement:

  
  
   case opPreDecrement:
  
  

  replace:

  
  
  if ( VNumber == lVar->varmem->data.vall.dataType )
  
  

  with:

  
  
   if ( wVar == lVar /* no dynamic obj happening */
  
   && VNumber == lVar->varmem->data.vall.dataType )
  
  

  * * * * *

  Fix:
  in SE:ISDK/Java 4.10c --

  The replacement is similar. In secode.java:

  replace:

  
  
   if ( VNumber == lVar.varmem.dataType )
  
   

  with:

  
  
   if ( wVar == lVar /* no dynamic obj */
  
   && VNumber == lVar.varmem.dataType )
  
  

• Using "Delete" Operator On Non-Reference Var

  Problem: the "delete" operator used on a non-reference variable (e.g. "delete 0", "delete global") will crash the engine.

  Fix:
  for ISDK/C --

  In the do_op_delete() function of OPERATOR.C, after reporting the message BAD_DELETE_VAR replace this line:

  
  
   return NULL;
  
  

  with this:

  
  
   return constructVarRead(call,VBoolean);
  
  

  Fix:
  for ISDK/Java --

  In the do_op_delete() method of Operator.java, after reporting the message BAD_DELETE_VAR, replace this line:

  
  
   return null;
  
  

  with this:

  
  
  return Var.constructVarRead(call,VBoolean);
  
  

• Changing The Global Object

  (In v4.10c for both ISDK/C and ISDK/Java)

  Problem: user can change the global object from a script, rendering the entire script object tree invalid and inevitably leading to a crash. For example, this script, with "global" being the name of the global object, will crash the interpreter, probably in cleanup:

  
  
  global = 4;
  
  

  The solution is to make the global object a Read-Only variable. This can be fixed from within your application, after jseInitializeExternalLink(), by setting the read-only attribute on for the global object.

  Fix: in the core engine for ISDK/C:

  In the NewGlobalVariable() function in UTIL.C add the following statement after "varAddUser(newGlobalVariable);"

  
  
  varSetAttributes(newGlobalVariable,jseReadOnly);
  
  

  = = = = = = =

  Fix: in the core engine for ISDK/Java

  In the NewGlobalVariable() method of Call.java, add the following statement after "newGlobalVariable.SetLvalue(true);"

  
  
   newGlobalVariable.SetAttributes(jseReadOnly);
  
  

Documentation errata

4.10c documentation --

• Code under “Methods” in SE JavaScript chapter

  The lines:

  
  
     var joe = Rectangle(3,4); 
  
     var sally = Rectangle(5,3); 
  
  

  should be:

  
  
     var joe = new Rectangle(3,4); 
  
     var sally = new Rectangle(5,3); 
  
  

• New example of NULL data type in Documentation

  Problem: In the ISDK manual's "ScriptEase JavaScript" chapter, under DataTypes/Special Values/Null, the example is wrong.

  Fix: It should read:

  
  
     var test = null;
  
     if( test==null )
  
        Screen.writeln("It is null.")