DukTape JS

Author: Dave
Date: 06.05.15 - 7:38pm

I have been tinkering with a new project, to try and get the dukTape js engine working with visual basic six. My end goal hopefully would be similar to what I did with script basic.

Since JavaScript supports obj.method notation, this time around I want to up the ante and be able to call methods on com objects the same way you can in the Microsoft script control.

So how do we map an arbitrary number and prototypes of functions and wire them into the correct method on the COM object.

When you call AddObject in the Microsoft script control, it has to use the typelib information to extract all of the prototypes to know how to call them. Ok I have done this.

But how do you create the necessary JavaScript prototypes and wire them all up to send them to the correct com method?

in the duktape C api you can create arbitrary objects and methods on them..but they are designed to each call a specific C function. This wont work for what I am trying.

Here is what I came up with so far. it is working, but will be further refined.

I added a single native C function called resolver.

int comResolver(duk_context *ctx) {
	int i, retType ;
	const char* meth = 0;

	int n = duk_get_top(ctx);  /* #args */

	if(n < 0) return 0;
	if(vbHostResolver==NULL) return 0; 
	
	meth = duk_safe_to_string(ctx, 0); //first arg is obj.method string
	retType = vbHostResolver(meth, strlen(meth), ctx, n-1);

	return 1;  
}

then i built up a javascript class source file (manually for now)

function dlgClass(){
	
	this.ShowOpen = function(filt,initDir,title,hwnd){ 
		return resolver("call:cmndlg:OpenDialog:long:[string]:[string]:[long]:r_string", filt,initDir,title,hwnd); 
	}	
	
}

function fsoClass(){
	this.ReadFile = function(fname){
		return resolver("call:fso:ReadFile:string:r_string", fname); 	
	}	
}

var cmndlg = new dlgClass();
var fso = new fsoClass();

var form = {
  set caption (str) {
    resolver("let:form:caption:string", str); 
  }, 
  
  get caption() {
    return resolver("get:form:caption:string"); 
  },
  
  ReadFile : function(fname){
		return resolver("call:fso:ReadFile:string:r_string", fname); 	
  },  
  
  ShowOpen : function(filt,initDir,title,hwnd){ 
		return resolver("call:cmndlg:OpenDialog:long:[string]:[string]:[long]:r_string", filt,initDir,title,hwnd); 
  }	

}

Now in vb6 I can do the following (all testing and working so far) to make alert() work I rewired the DUK_FWRITE to redirect to my own stdout handler which calls back to vb6

rv = Eval("1+2") 'works
rv = Eval("alert(1+2)") 'works
rv = Eval("pth = cmndlg.ShowOpen(4,'title','c:',0); alert(fso.ReadFile(pth))") 'works
rv = Eval("form.caption = 'test!'; alert(form.ReadFile('c:lastGraph.txt'));")
rv = Eval("form.caption = 'test!';alert(form.caption)")

So everything is looking good so far. property gets and sets are functional as are arbitrary method calls. To make the magic work my vb host resolver function

looks up the live object from the name
extracts method/property name
loads a variant array with the relevant args/values/types
uses TLIApplication.InvokeHook to call the method
sets the return value
returns execution back to the script.

So with the initial experimentation stage up and running, next step will be to use the typelib info to parse the COM objects on the fly when I call AddObject and build the appropriate js class file for each, and well as save the method info for the resolver.

I will probably save the method info in a class in parsed format and just use a methodID in the javascript file instead of a full text based prototype which is bulky but good for initial testing.

Before I goto much farther down that road which will be a lot of work though..I think I will start experimenting with the debugger capabilities (here and here) to make sure I can control it.

just having a more modern Javascript implementation available for VB6 is already a win, COM object support was a must have though. but if I can build a full IDE for it like i did for script basic..then that will knock it out of the park.

One more thing to resolve..right now all the COM objects and methods I have tested are on static global top level objects. What if a method returns a new object instance such as with the Microsoft Scripting runtime or Excel automation? ex:

Function OpenTextFile(FileName As String, 
	[IOMode As IOMode = ForReading], 
	[Create As Boolean = False], 
	[Format As Tristate = TristateFalse]
) As TextStream

Function ReadAll() As String Member of Scripting.TextStream

how to call a method on a specific instance of an object instead of static top level global objects like we have been? My first thought was to add a int field to the TextStreamClass of my own that would hold an objptr(obj) to identify it uniquely. Resolver will have to return a new class instance, and set say a hInst field of it. Thanks to some help from the guys on the IRC channel this is already working in a simple test scenario ex:

duk_get_global_string(ctx, "fsoClass"); 
duk_new(ctx, 0);

Also looking at the debugger docs, they are marked as highly experimental. My instinct is telling me to hold off on messing with the debugger side of it for a bit just in case.