XMetaL Tips and Tricks

XMetaL Community Forum XMetaL Tips and Tricks Script error: unable to determine ClassID for language "JScript"

  • Derek Read

    Script error: unable to determine ClassID for language "JScript"

    Participants 1
    Replies 0
    Last Activity 12 years, 7 months ago

    Product(s):
    XMetaL Author or XMAX, any version

    Description:
    You attempt to run a macro, or an event macro runs (this will often occur when launching the software as most customizations of XMetaL include events set to run at startup) and you see one of the following errors:

    Script error: unable to determine ClassID for language "JScript".
    Script error: unable to determine ClassID for language "VBScript".
    Script error: unable to determine ClassID for language "Python".
    Script error: unable to determine ClassID for language "PerlScript".
    Script error: unable to determine ClassID for language "Perl".
    Script error: unable to determine ClassID for language "{script engine identifier}".

    [img]http://forums.xmetal.com/index.php?action=dlattach;topic=503.0;attach=164;image[/img]

    Causes:
    You must have a functioning script engine for all macros used by a particular customization of XMetaL (Author or XMAX). Without a functioning script engine any macros written in a script that requires that engine will fail to run.

    Out of the box, all versions of Windows that XMetaL is currently certified to run on include a functioning copy of “Windows Script Host” which provides scripting support for JScript and VBScript. These are the two most common languages used for writing scripts that customize XMetaL (because they do not require any extra script engine to be installed). Additional scripting languages may be used but require a script engine supporting those languages to be installed.

    There seem to be some security and virus applications that disable Windows Script Host (WSH), or a portion of WSH. It is also possible that a particular IT department may disable WSH on purpose This is of particular relevance to people seeing the errors above for JScript and VBScript. For other languages (Python, PerlScript or anything else) it may be that you are using an XMetaL customization that needs a particular script engine that has not yet been installed on your computer.

    XMetaL Author Enterprise users working with DITA content should note that this functionality is primarily implemented using JScript so errors mentioning other script engines would indicate you have some additional scripts installed that are likely not part of the DITA solution, possibly provided by a 3rd party. In this case you may also wish to check with the 3rd party to see if there are any specific requirements they have for scripting engines needed by their solution.

    Fix:
    The fix for this is to enable the script engine for the language in question.

    JScript:
    Confirm that the following file exists: c:windowssystem32jscript.dll

    • If the file does not exist you should attempt to repair Windows or download and install a fresh copy of WSH. See links below. Also note that your “Windows” folder may not be named c:windows
    • If the file exists, register it (you may need your IT people to do this) using the Windows command regsvr32 jscript.dll

    VBScript:
    Confirm that the following file exists: c:windowssystem32vbscript.dll

    • If the file does not exist you should attempt to repair Windows or download and install a fresh copy of WSH. See links below. Also note that your “Windows” folder may not be named c:windows
    • If the file exists, register it (you may need your IT people to do this) using the Windows command regsvr32 vbscript.dll

    Python, Perl or other script language:
    Confirm that you have a script engine installed that supports the language in question.

    • If not, you will need to obtain one and install it. Before you do this check with the people that wrote your customization to see which one they tested with as engines from different providers and different versions of these engines may function slightly differently and using an incompatible engine may cause further errors. It is usually safest to install the same version that was tested during the creation of the scripts.
    • If you do have the engine installed you may need to repair it. Refer to the engine's documentation or check their support channels for more information on how that may be done.

    Security or Virus Protection Resolution:
    In all cases above where it has been determined that the scripting engine was installed but disabled you should attempt to figure out the root cause so the issue can be avoided in the future. This means tracking down the software responsible for disabling it or checking with your IT people to see if the engine was disabled on purpose.

    External References:

    Reply

  • You must be logged in to reply to this topic.

Lost Your Password?

Products
Downloads
Support