What does VBScript GetRef return??

[Ryan Tomayko]

How does the VBScript GetRef("function") work? I can't seem to find any
documentation on how to write objects that can recieve a GetRef pointer..

-Ryan

[Ryan Tomayko]

GAWD I love answering my own posts...

GetRef() returns a VT_DISPATCH VARIANT. The IDispatch returned is special in
that you may only invoke the defualt dispid(0). Which is, of course, the
function you called GetRef on. Same goes for jscript function assignment
operator.

VBScript
Set bla.onclick = GetRef("function");
JScript
bla.onclick = function;

Alright, more questions...
Is this the same way the IDispatch passed through IBindEventHandler works?
Is another IDispatch created each time a connection is sanked in this manor?

[Andrew Nosenko]

Hi Ryan and All,

The following information on IBindEventHandler might be useful to you.

I've just discovered, IBindEventHandler has no appication with IE (at least
IE5). Even more, all IE objects that support
function <object>.<event>() { .. }
binding don't expose IBindEventHandler. Still note, complex things like this
<script>
function window.document.onkeydown() { alert("Blah") }
</script>
do work!

My IBindEventHandler was never being queried for. It turns out, when JScript
sees
function <object>.<event>() { alert("Blah") }
syntax, it understands it and merely assigns object.event, which is much the
same as:
<object>.<event> = function() { alert("Blah") }

I implemented a special property per event (like IE does):

[propput] HRESULT event([in] IDispatch* handler)
[propget] HRESULT event([out, retval] IDispatch** handler)

and it works perfectly. You should call Invoke(DISPID_VALUE,...) on passed
IDispatch when the corresponding event occurs. Some time it's even easier and
more efficient than implementing standard IConnectionPointContainer schema. It
allows you to sink events from children objects as easy as:
function <root>.<child1>.<child2>.<event>() { alert("Blah") }
with VBScript, you can do the same with
sub handler
end sub
<root>.<child1>.<child2>.<event> = GetRef(handler);

Eric please, should IBindEventHandler be consdered as legacy interface?

Btw, new cool features are here for engines V5. Look:

****************
interface IActiveScriptProperty : IUnknown
{
// NOTES:
// (*) This is a generic information passing interface to allow
// the host to get and set pre-defined properties of the engine
// (*) dwProperty must be a SCRIPTPROP_* value
// (*) pvarIndex (when used) further identifies the dwProperty
// (*) pvarValue is the value of the property, can be any VARIANT including
// binary data in a VT_BSTR, most common is VT_BOOL
HRESULT GetProperty(
[in] DWORD dwProperty,
[in] VARIANT *pvarIndex,
[out] VARIANT *pvarValue
);
HRESULT SetProperty(
[in] DWORD dwProperty,
[in] VARIANT *pvarIndex,
[in] VARIANT *pvarValue
);
}

/* Properties for IActiveScriptProperty */
#define SCRIPTPROP_NAME 0x00000000
#define SCRIPTPROP_MAJORVERSION 0x00000001
#define SCRIPTPROP_MINORVERSION 0x00000002
#define SCRIPTPROP_BUILDNUMBER 0x00000003

#define SCRIPTPROP_DELAYEDEVENTSINKING 0x00001000
#define SCRIPTPROP_CATCHEXCEPTION 0x00001001

#define SCRIPTPROP_DEBUGGER 0x00001100
#define SCRIPTPROP_JITDEBUG 0x00001101

// These properties are defined and available, but are not
// officially supported.
#define SCRIPTPROP_HACK_FIBERSUPPORT 0x70000000
#define SCRIPTPROP_HACK_TRIDENTEVENTSINK 0x70000001

****************

I'm especially interested at SCRIPTPROP_DEBUGGER, SCRIPTPROP_DEBUGGER,
SCRIPTPROP_CATCHEXCEPTION.
Note also this:

****************

[
object,
uuid(1DC9CA50-06EF-11d2-8415-006008C3FBFC),
pointer_default(unique)
]
interface ITridentEventSink : IUnknown
{
HRESULT FireEvent(
[in] LPCOLESTR pstrEvent,
[in] DISPPARAMS *pdp,
[out] VARIANT *pvarRes,
[out] EXCEPINFO *pei
);
}

****************

I'm going to investigate this. Andrew and Eric, we would all appreciate if you
made available new ActiveScripting Docs. Btw, nothing on ActiveScripting is
available on MSDN online. Thanks

--
Regards,
Andrew Nosenko,
Mead & Company
ScriptX control, free:
http://www.meadroid.com/scriptx/
Browser extensions for weblications:
http://www.meadroid.com/wpm/

[Eric Lippert (Microsoft Scripting Dev)]

That's a lot of stuff -- I'll split my reply up into several posts.

Eric

Andrew Nosenko <cap...@meadroid.com> wrote in message
news:eDRpDa0i#GA.261@cppssbbsa03...

[Eric Lippert (Microsoft Scripting Dev)]

These are NOT cool new features, these are hacks we added to the engine in
order to get performance features into IE and ASP without re-writing the
Windows Script Interfaces entirely. DO NOT USE THEM. As far as I know,
they will NEVER be documented or supported. Their behaviour is entirely
dependent on my whims, and you know how capricious I can be. ;-) If by
some strange twist of fate we do decide to support these as public WSIs,
we'll add them to the doc then. Until then, please don't muck with them as
we cannot guarantee that future script engines will be forward compatible
with any host that uses these interfaces.

In particular, ITridentEventSink is a hack that we added which allows
VBScript to walk the IE type info looking for events to bind much faster
than the traditional type info walking code. We found that we had
situations where there would be a table with a thousand entries, say, and
we'd spend thirty, forty seconds just looking at every entry to see if there
were any events bound on it. (JScript doesn't have this problem because
JScript doesn't have automagic event hookup, events must be hooked up
explicitly in the code or the HTML.) This interface is a PRIVATE interface
between VBScript and the IE HTML rendering surface, DO NOT USE IT. Pay no
attention to the man behind the curtain!

Eric

[Eric Lippert (Microsoft Scripting Dev)]

IBindEventHandler has _nothing_ to do with either IE or with the
"button1.onclick = myfunc;" syntax. It is specifically for the JScript
event binding syntax which is not supported by IE -- when you bind an event
with

function object::event() {}

then the object is QI'd for IBindEventHandler. If it doesn't support it, we
construct a sink on the outgoing dispatch just like normal.

Your analysis of JScript is correct -- JScript has no idea that
"button1.onclick = myfunc" is doing an event binding, it is just assigning
an object to a property. The fact that this assignment causes a certain
event-like behaviour to occur later is a property of the OBJECT, not a
property of the JScript engine.

Eric

[Ryan Tomayko]

> These are NOT cool new features, these are hacks we added to the engine in
> order to get performance features into IE and ASP without re-writing the
> Windows Script Interfaces entirely. DO NOT USE THEM.

Cool new performance features?!?!! Right on! Hack up some docs and
standardize it!

-Ryan

[Andrew Nosenko]

Thanks Eric,
Finally the sequence is clear to me.
-Andrew.

Eric Lippert (Microsoft Scripting Dev) <Eri...@Microsoft.com> wrote in message
news:OfIblN2i#GA.260@cppssbbsa03...

[Andrew Nosenko]

>>we cannot guarantee that future script engines will be forward compatible
with any host that uses these interfaces.
<<

What about strong COM interface contract? ;-) [he-he, just kidding]

>>In particular, ITridentEventSink is a hack... <
Ok, I won't use ITridentEventSink. I like IActiveScriptProperty much more :-)

Thanks Eric for your spots.
-Andrew.