Some quick answers that might get you on the right track, though I don't think they're entirely complete. Feel free to ask for clarification or expansion on any of the below:
The data types you can return to a client script are limited by the fact that they have to fit into a VARIANT. That's the nature of COM Automation, more than anything; IDispatch::Invoke does everything with VARIANTs. I know that JScript and VBScript treat arrays differently, so you may find that you need glue code on one end or the other to make them work as you expect. There's a reason we return collections rather than arrays from things like Keyboard.Keys, and that's it in a nutshell. I haven't tried dates, so some experimentation will be required, but since they fit in a VARIANT and are supported by both VBScript and JScript, it seems they should be fine too.
Basically, if Window-Eyes can find or create an IDispatch that corresponds to your function or class, you can expose it as a shared object. The GetRef function in VBScript turns a function name into an IDispatch with the named function as the default method, but we also have a shortcut built in to Window-Eyes that can look for functions by name in the IDispatch that represents your entire script. If Python can supply one or the other of those types of IDispatch, it should work. If it can't supply one or the other of those types, you might also have problems with things like hotkey and dialog callbacks, which use the same mechanisms. There might be workarounds, though; that's essentially what vbgetref.dll does for VB6, which doesn't seem to be able to supply the necessary IDispatch objects.
Jamal Mazrui wrote:
Are there limitations on the data types a JScript shared object can return to a client script? I assume that strings and numbers may be returned, but how about arrays and dates? A related question is what features does a language need to create a shared object? For example, if I create a function in a Python program, can I register it as a shared object? Jamal
