It is, on the whole, best to start testing a Server Scriptlet with an HTML page, as we did above. Writing an HTML page is quite straightforward and quicker than Visual Basic. However, there's a possible nasty side effect, which does need to be pointed out. It seems that you need to close IE4 before testing a modified scriptlet. In other words, you write your scriptlet and run an HTML page to test it. Then you find out there's a bug or something you want to fix. So you switch to your favorite editor and enter the changes. You can't simply refresh IE4, however, for the updates to take place.
There's a reason for this. A DHTML Scriptlet is a far simpler object, really nothing more than an HTML page. With this in mind, by refreshing the IE4 window you could force the browser to consider the most recent version of it. Things aren't so smooth with Server Scriptlets. A Server Scriptlet is a COM object—or rather it is accessed through a real COM object. Loading and unloading a COM object, say an ActiveX control, poses a number of problems. In practice the object remains locked and gets freed only when you close IE4 or—probably—when you open so many documents that it's put out of the browser's cache. Only then is a COM object unloaded from memory. If you're using a tool like Visual Basic, Visual C++ or Delphi at this point you can delete or recompile it. If you're using Server Scriptlets, however, only now you can have it reload again from scratch with all the new changes to the XML and script code.
With the first beta of Server Scriptlets, if you're using a scriptlet and have an error then the JScript parser remains hanging. You need to close your development tool (say Visual Basic) before re-testing the scriptlet. This is due to a bug which will probably be fixed by the time you read this.