Re: Creating event objects

The generic IDispatch sink Adam and I wrote is here:

http://cvs.sourceforge.net/viewcvs.py/jsegue/jSegue/src/com/moesol/bindings/platform_sdk/component_services/GenericSink.cpp?rev=1.1.1.1&view=markup

It relies on some information that is extracted from the typelib and from
the JNI signature of the method it needs to call. Here's the start of an
example of the JNI signature information:

            static
::com::moesol::bindings::jni_ConnectionPointSink::MethodInfo sig_map[] = {
                { 2000, "OnEvent", "()V" },
                { 2001, "OnEventWithLong", "(I)V" },
                { 2002, "OnEventWithLongLong", "(II)V" },

The first numer is the IDispatch method id. It also relies on type
information passed along in the VARIANT array of args. However, John needs
to do something different.

I've looked at the current callback mechanism to understand how jawin
encodes this info.
I've looked at the COMDelegator, but I think it might be more jawin like
using a approach were we build the vtbl using existing jawin callback
mechanism:

COM is a binary standard that defines exactly how the vtbl should look. For
an interface like this:

IFoo : IUnknown {
OnEvent();
OnEventWithLong(LONG l);
}

We'll first have the IUnknown methods, then the IFoo methods:

QueryInterface,
AddRef,
Release,
OnEvent,
OnEventWithLong

Then the actual object pointer should first have a vtbl pointer then its
state (if any).

I'm not that familar with the jawin marshaling strings, but I found examples
as noted below where you can hopefully figure out what you need. An idea of
how this might work...

If we get this working in a hand coded state, I imagine that we can get the
JTB to generate it.


First declare all of the call back functions.

class QueryInterfaceHandler extends WinFuncPtr {
//see org.jawin.donated.win32.HandlerRoutine for how java classes are setup
to be C++ function callbacks.
}
class AddRefHandler extends WinFuncPtr {
}
class ReleaseHandler extends WinFuncPtr {
}
class OnEventHandler extends WinFuncPtr {
}
class OnEventHandlerWithLong extends WinFuncPtr {
}


Then declare a class to act as a  vtbl:

class IFooVtbl {
// see org.jawin.donated.win32.WNDCLASS for how the marshalling string might
look, basically
// we have a structure with consectutive fields that are all function
callbacks. Unfortunately WNDCLASS
// only has one function callback, but hopefully we can extrapolate...

QueryInterfaceHandler vtbl_0;
AddRefHandler vtbl_4;
ReleaseHandler vtbl_8;
OnEventHandler vtbl_12;
OnEventHandler vtbl_16;
}


Then declare a class to act as a structure that will hold a pointer to the
vtbl:
class IFooHandler {
IFooVtbl vtbl;
// we need a marshal string that will nest the vtbl structure in the
IFooHandler structure

The constructor needs to fill out the structure and vtbl structure. I just
show it calling back to itself.

IFooHandler() {
    vtbl = new IFooVtbl();
    vtbl.vtbl_0 = new QueryInterfaceHandler() { call(...) {
QueryInterface(...); } }
    vtbl.vtbl_4 = new AddRefHandler() { call() { AddRef(); } }
    ...
    vtbl.vtbl_16 = new OnEventWithLongHandler() { call(int longArg) {
OnEventWithLong(longArg); } }

QueryInterface(...) { }
AddRef() { }
...
OnEventWithLong(int longArg) { }
}


Finally you'd have to make the marshalling wrapper for the testCallback
method, which you would call something like:

IFooHandler fh = new IFooHandler() { OnEventWithLong(int l) {
System.out.println(l); } }
bar.testCallback(1000, fh);

There's still a lot of details to be cleared up, but assuming we can get the
marshaller to layout a nested structure with callback funtions this should
all work (in theory). If the native testCallback method never calls IFoo's
QueryInterface, the it should be pretty easy, otherwise we'd have to make QI
work or supply a native impl for it. AddRef and Release could do nothing, or
they could actually keep the ref count and if it goes to zero IFooHandler
could tear down the structure, setting the vtbl.vtbl_* to 0 should allow
IFoo to GC, but I'm not sure jawin has a way to make the indivual handler
classes GC (it hold global refs from the JNI side to these).

Robert


----- Original Message -----
From: "John Pompeii" <[email protected]>
To: <[email protected]>
Sent: Thursday, July 22, 2004 5:45 AM
Subject: Re: [JAWIN] Creating event objects


> Hi Morton,
>
> >So if I understand you correct, if we can support a testcase like the
> >following, we would also be able to support your problem?
> >
> >IDL:
> >   HRESULT testCallback([in] int callbackTimeout, [in] ICallbackTest*
> >pCallbackTest);
> >
> >Implementation:
> >
> >STDMETHODIMP CDualTest::testCallback(int callbackTimeout, ICallbackTest*
> >pCallbackTest) {
> >        // setup new thread calling a callback method on pCallbackTest
> after
> >callbackTimeout milliseconds?
> >}
> >
> >
> >The ICallbackTest should then be a very simple COM-interface with just
> >one callback method, and Jawin should be able to let a Java class
> >"implement" this interface, marshal an instance of this Java class to
> >native code and hand it to the "testCallback()" method? Jawin should
> >then intercept the native callback, and marshal it into the appropriate
> >java-method call on the passed java-instance.
> >
>
> Yep, I think that's pretty much it!  It is possible to do this with the
> current version of jawin, assuming that I code the C++ COM classes that
> implement the event interfaces?  Robert, you mentioned that you've done
> something similar before, do have any examples?
>
> thanks,
> --john
>