gymshoe
September 18th, 2000, 04:00 PM
Hello,
I am writing a java applet and wish to interface with COM based
objects. I am using Sun jdk1.3 and JNI to do this.
What I have done is to create a dll from two source files.
* jniintrf.cpp -- interface between my Java app and the dll using JNI.
* comintrf.cpp -- interface between my dll and the COM objects
If I receive a request through jniintrf.cpp from Java I forward the
request to functions in comintrf.cpp. Everything works fine except I
cannot get callbacks to work properly. Inside of comintrf.cpp I register
for some callback events with the COM objects. For whatever reason,
these callbacks do not make it back to my dll. In order to test this
further I created a very simple MS application that links in the .lib
file (which then loads my .dll). The MS application calls directly into
the comintrf.cpp layer of my dll. This works just great. I get callbacks
from the COM objects back to my dll. However, when I load the .dll from
Java and access my dll through the JNI layer, the callbacks do not work.
Note, I realize that I would need to synchronize threads to make it back
all the way to the JVM - I am just trying to make it back to my dll for
now.
I am pretty weak on COM/ActiveX/OLE or whatever it is supposed to be
called. I believe that ActiveX controls require some sort of container
to run in but I don't know if the same is try for MS COM objects. I
noticed that when I used the MFC wizard to create my MS app it inserted
the following code:
// Initialize OLE libraries
if (!AfxOleInit())
{
AfxMessageBox(IDP_OLE_INIT_FAILED);
return FALSE;
}
AfxEnableControlContainer();
I really don't understand the implications of an application vs a dll in
the MS world but I pasted this in my dll just for kicks - it didn't
help.
The third party that supplies the COM objects has plenty of examples of
how to access their objects via an application but not from a dll - and
not in a situation where no MS application is involved. Basically, my
dll is my "application" and is the only piece of MS code in the system.
If I need to create some sort of container or enable some sort of
dispatch mechanism I image I will need to do it here.
thanks for any help you can give,
gymshoe
I am writing a java applet and wish to interface with COM based
objects. I am using Sun jdk1.3 and JNI to do this.
What I have done is to create a dll from two source files.
* jniintrf.cpp -- interface between my Java app and the dll using JNI.
* comintrf.cpp -- interface between my dll and the COM objects
If I receive a request through jniintrf.cpp from Java I forward the
request to functions in comintrf.cpp. Everything works fine except I
cannot get callbacks to work properly. Inside of comintrf.cpp I register
for some callback events with the COM objects. For whatever reason,
these callbacks do not make it back to my dll. In order to test this
further I created a very simple MS application that links in the .lib
file (which then loads my .dll). The MS application calls directly into
the comintrf.cpp layer of my dll. This works just great. I get callbacks
from the COM objects back to my dll. However, when I load the .dll from
Java and access my dll through the JNI layer, the callbacks do not work.
Note, I realize that I would need to synchronize threads to make it back
all the way to the JVM - I am just trying to make it back to my dll for
now.
I am pretty weak on COM/ActiveX/OLE or whatever it is supposed to be
called. I believe that ActiveX controls require some sort of container
to run in but I don't know if the same is try for MS COM objects. I
noticed that when I used the MFC wizard to create my MS app it inserted
the following code:
// Initialize OLE libraries
if (!AfxOleInit())
{
AfxMessageBox(IDP_OLE_INIT_FAILED);
return FALSE;
}
AfxEnableControlContainer();
I really don't understand the implications of an application vs a dll in
the MS world but I pasted this in my dll just for kicks - it didn't
help.
The third party that supplies the COM objects has plenty of examples of
how to access their objects via an application but not from a dll - and
not in a situation where no MS application is involved. Basically, my
dll is my "application" and is the only piece of MS code in the system.
If I need to create some sort of container or enable some sort of
dispatch mechanism I image I will need to do it here.
thanks for any help you can give,
gymshoe