Many first time RS users who encounter the dreaded

"Remote Scripting Error - page invoked does not support remote scripting"

error message are understandably at a loss as to what to do.  The error message is generic and can
have many causes - some rather obvious in the end and some rather subtle.

I thought it would be useful to post the some of the common causes, solutions, and RS debugging
techniques that have been posted in the newsgroup all in one general post.

<Disclaimer>

I do not actually consider myself to be an RS expert - I do not use RS myself in any production
application.  What I know about RS has come strictly through personal experimentation, reading (and
saving) the posts of the real resident experts who frequent this newsgroup (like Brent Ashley and
Bruce Barker to name just two of many ;-), as well as from reading published RS related articles,
mostly MSDN Magazine (formerly MIND) articles by Dino Esposito.

I strongly recommend the following for anyone new to RS:

1. Actually read the "official" RS documentation <g>!!!

Using Remote Scripting
http://msdn.microsoft.com/scripting/remotescripting/docs/default.htm

2. Go to:

microsoft.com Search Wizard
http://search.microsoft.com/us/dev/default.asp

and do an "Exact Phrase" search for: "remote scripting" without the quotes)

Be sure to check all areas under "...search scope:".

Note that you'll get some duplicate titles (some MSDN/MIND articles are available from different
paths).

...now back to the "Remote Scripting Error ...".

</Disclaimer>

There are several very common causes:

1) The client side path references to the RS pieces are incorrect.

2) The RSAspProxyApplet is called before it is ready.

3) There are errors in the user written server side implementation of the public_description object
instance.

============================================================================
1) The client side path references to the RS pieces are incorrect.
============================================================================

Given the following file system locations on the web server:

c:\InetPub\wwwroot\_ScriptLibrary\rs.asp
c:\InetPub\wwwroot\_ScriptLibrary\rs.htm
c:\InetPub\wwwroot\_ScriptLibrary\rsproxy.class

c:\InetPub\wwwroot\mysite\myclient.htm (or asp)
c:\InetPub\wwwroot\mysite\myserver.asp

In myclient.htm,
    make client side references to RS components using explicit virtual paths, and include a virtual
path argument to the RSEnableRemoteScripting function call.

<script language="JavaScript" src="/_ScriptLibrary/rs.htm">
</script>
<script language="JavaScript">
  RSEnableRemoteScripting("/_ScriptLibrary");
</script>

In myserver.asp,
    make the server side include reference using VIRTUAL rather than FILE and make sure the include
directive is NOT nested inside any server side script element.

    <!--INCLUDE VIRTUAL="/_ScriptLibrary/rs.asp"-->
    <SCRIPT RUNAT="SERVER">
    ...
    </SCRIPT>

============================================================================
2) The RSAspProxyApplet is called before it is ready.
============================================================================

In general, never make RS calls before the window.onload event fires.  It takes time for the Java VM
to load and for the RSAspProxyApplet to initialize.

Before making RS calls, you should always verify that the applet is ready for use.  One simple (if
perhaps inelegant) technique is to poll the readyState property in a loop.

  in javascript:
    while (RSAspProxyApplet.readyState != 4) {}
  in vbscript:
    While RSAspProxyApplet.readyState <> 4 : Wend

You can insert the code that polls the readyState immediately before each of your RS calls.  Or you
can do it once in the window.onload event and set a page level boolean flag variable to true and
make all RS calls conditional on the flag being set to true.

There are any number of other schemes you might devise, but the point is to ensure that the
RSAspProxyApplet is only called when it's ready to be called.

============================================================================
3) There are errors in the user written server side implementation of the public_description object
instance.
============================================================================

A common debugging technique is to type the url to your "server.asp" page directly in the browser's
address box.  If there are compile time (i.e. language syntax) errors in your code they will be
returned to you directly.

Once any syntax errors have been resolved, another debugging trick is to hard code as call to one of
your public_description object's methods to simulate a client side call and output the results using
normal Response.Write calls.  Navigate directly to the page as described above.  This will help you
identify any runtime logic or called component (like ADO) errors.

Another *excellent* (IMO indispensable) debugging trick...

<thread
  author="Brent Ashley"
  title="No more blind debugging"
  date="Monday May 1, 2000"
  newsgroup="microsoft.public.scripting.remote">

Hey, All;

I've found this rs.htm modification useful while debugging my remote scripting apps.  It augments
the dreaded "Page invoked does not support remote scripting" error by popping up a new browser
window containing the asp error message that was passed via the proxy class.  You can then see
exactly which line in your remote scripting page caused the error.  No more blind debugging.

Remember you probably don't want this mod in your release code.

Just add these two lines to this part of the _MSRS_evaluateRequest() function in RS.HTM as shown:

 function _MSRS_evaluateRequest(request)
 {
.
. a bunch of stuff missed out here for brevity...
.
  else
  {
   request.status = MSRS_FAIL;
   request.message = 'REMOTE SCRIPTING ERROR: Page invoked does not support remote scripting.';

  // add these two lines to open new window with asp error
   var win = window.open('','_blank','height=600,width=450,scrollbars=yes');
   win.document.write( request.data );

  }
}

 - Brent -

</thread>

<tip author="Bruce Barker">

knowing what the errors mean can can help:

'Page invoked does not support remote scripting.'

this is displayed  when the called asp page did not return a properly formated response. a proper
response has some simple xml tags, even if there was an error. there are two general causes for
this.

    1) you called the wrong page or misspelled the url
    2) the asp page has an unhandled script error, which prevents the proper respone format being
returned.


'Failed to create ASP object for <url>'

this can be displayed when you call RSGetASPObject(). it can be caused by the above, or by the
applet not being ready, but the applet is loaded.


'Cannot locate proxy which supports Remote Scripting. Was RSEnableRemoteScripting method invoked?'

this is displayed when the applet is not found. there are three causes for this:

    1) RSEnableRemoteScripting() really was not called
    2) the path to the rs library was not correct
    3) java applets are disabled in the browser


'Remote Scripting Error - <some message>

this happens when the server asp detects an error while trying to call the remote function. as it
has limited error handling, unless you modified rs.asp to be more robust, there only a couple causes
which are all simular.

    1) you did not define the function in RSMethods
    2) the function you referenced from RSMethods does not exist
    3) you misspelled the function name on the client side

</tip>

--
Michael Harris
Microsoft.MVP.Scripting
--