mark guerrieri

I have an app that hosts the browser control, and in the HTML of the browser
I use window.external to assign an automation object to a variable in
VbScript. The automation object is a straigt forward ATL object that
implements IProviderClassInfo2 and IObjectSafety.

Is it possible to sink events from this object in VbScript? It seems that
the "Sub Object_Event" method only works if the object was created on the
page. I cant find a way to get the browser control to call Advise for my
object's events. Events fire and work fine outside of a scripting host.

Say, for example, you passed a Recordset object into the script via
window.external:

Dim oRs
Set oRs = window.external

I can now access the properties and methods of the recordset, but how can I
sink its events?

Thanks-

Mark Guerrieri
CTO
Creative Marketing Strategies
mguerrieri@cmsgrp.com

nic roche

I am using the window.external to reference interfaces.

I haven't found a reference to recieving event notifications from the
objects...

Id the recordset method the default method in your object, or have you
omitted the methodname?


Nic Roche

michael harris \(mvp\)

ScriptX from http://www.meadroid.com has (in its free unlicensed subset) support
for Dynamic Event Binding (connecting event sources and sinks of existing
objects).


--
Michael Harris
Microsoft MVP Scripting

mark guerrieri

I was only using Recordset as an example. My object is called CMSUser, so
for example:

Dim oUser
Set oUser = window.external
oUser.Login

The CMSUser object is created by the scripting host and passed into the
script via window.external. CMSUser resides in an out-of-process server
app.

oUser.Login begins the Login process for this object, which will trigger an
OnLogin event on the oUser object when complete. I need a way to sink that
(and other) events.

Mark

igor tandetnik

I don't know of any way to sink COM-style (connection point based)
events from an object not created with an <object> tag (without using
third-party solutions). However, if you can modify your windows.external
implementation, you can implement DHTML-style events - those are easier
for the script to work with.

A DHTML-style event is actually a property that accepts a function
object as its value. A function object is an IDispatch pointer whose
only method, the one with a DISPID of DISPID_VALUE (0, zero), invokes
the script function. So in script you write something like this:

// JavaScript
function eventHandler() {...}
external.onmyevent = eventHandler;

' VBScript (sorry if my syntax is off - I don't usually code in
VBScript)
Sub eventHandler
End Sub
external.onmyevent = GetRef("eventHandler")

In your component, you have a property of type IDispatch*. In put_*
method, you cache the interface in some member variable. To fire an
event, call IDispatch::Invoke(DISPID_VALUE) on it. If needed, you can
pass parameters and obtain return value in the usual way.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925

mark guerrieri

Interesting idea- but how would I know when to release the cached interface?
My COM object lives externally to the browser component, and many different
pages will be loaded into the browser during its lifetime. When a new page
is loaded, the old script method event handler will go out of scope (and I
presume have its reference count decreased), but I will still have a
reference to it. If a new event handler is not assigned on the new page,
what happens when I Invoke into the cached interface to fire the event?

Mark

igor tandetnik

When you are being unloaded, usually when IOleObject::SetClientSite(NULL) is called


Then make it IOleObjectWithSite::SetSite(NULL)

Are you saying you have a COM singleton? Bad idea. Instead of giving out
the same object to every client, create a separate object for each
client, and have them forward method calls to a C++ singleton (that is
not exposed to the clients directly). Then each COM object can take care
of its event sinks.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925

mark guerrieri

My object is a non-visual automation object created in an out-of-process
server, not an ActiveX control and therefore does not implement
IOleObjectWithSite. It is not unloaded, as it is not hosted by the browser
in the first place. it is simply AddRef'ed when window.external is called
and Released when the browser page goes away, as far as I can tell. The
client application that hosts the browser control holds a reference to the
object to keep it alive.

That is basically what I have already.

It goes like this: I have a single-instance OOP server that acts as a
"Login Service" for my "System." Applications that create an in instance of
my "User" object will launch the OOP server, if it is not already running,
and it will provide a new User object. Each client connects to the same OOP
server, but gets their own "User" object. So I have a single-
instance/multiple-use OOP server that serves unique User objects to clients.
Each client can then call the Login() method of the User object to log in to
the "System" and multple client applications can all be logged in uniquely
at the same time using different User objects.

One particular client application, which hosts a browser control, creates an
instance of the User object. If certain options are selected in the
application, the browser window is displayed. The content of the browser
needs to be able to interact with User object, thus the use of
window.external. The problem is that the interaction between the browser's
content and the User object is not just limited to properties and methods,
but also to handling events. For example, their may be VbScript on the page
like this:

Dim oUser
Set oUser = window.external
oUser.SomeAsyncMethod()

SomeAsyncMethod would do some backround processing and return the results
via an event, and the client would need to sink that event to know when the
method was complete and update the browser's content accordingly. I would
have thought there would be a way to manually hook up an event sink for an
external object, otherwise the ability to extend DHTML through
window.external becomes very limiting in this case.

Mark

michael harris \(mvp\)

Couldn't you app just handle the BeforeNavigate or BeforeNavigate2 event of
the browser control and do housekeeping wrt clearing aby assigned event
handlers?


--
Michael Harris
Microsoft MVP Scripting

igor tandetnik

It's IObjectWithSite - my bad. You can happily implement it on a
non-visual component, whether in-proc or out-of-proc. Alternatively, you
can just wait until all references on you are released.

In this case, whoever implements window.external could notify the
component (perhaps by calling a special method on a custom interface)
that the page got unloaded, so the component can release event sink interfaces.


Can't the client application, the one that implements window.external,
sink events from your component using the regular COM connection point
mechanism, and translate these events into DHTML-style events?
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925