Re: Help please: Trouble getting a value back from COM.
Darrin Smith <[email protected]>
| Newsgroups | gmane.comp.windows.devel.jawin |
|---|---|
| Message-ID | <060420041818.4419.40C0BCEF000E3FF60000114321602807419CA19FA102079D9D0E0B@att.net> |
We might just try doing getXXX methods then and returning a String instead of a padded char array then. I'll let the group know how it goes if we go this route (instead of buying a commercial product...really would like to be able to pass varying length String parameters to be inspected than use getXXX functions if possible).
Way back when I used to do COM I knew a little about callbacks and event handling, but that was about 8 years ago. I don't recall much at all about COM now, other than it reminds me a lot of CORBA.
-------------- Original message from Roger I Martin PhD : --------------
> ----- Original Message -----
> From: "Darrin Smith"
> To:
> Sent: Friday, June 04, 2004 1:55 PM
> Subject: Re: [JAWIN] Help please: Trouble getting a value back from COM.
>
>
> > First off, THANKS for the reply!
> >
> > Although it won't be me specifically writing the COM side, I can request
> for it to look however I want and it will be written that way (in house).
> >
> > What we need to have is the ability to return Strings across COM from the
> DLL to the Jawin application. The Strings will be of varying size, but that
> doesn't mean that we couldn't pad them I guess.
> >
> > What I think I am hearing then is that instead of String, we should use a
> character array of a known length with getXXX methods for each value.
>
> Your in a good situation and I did similar at times rather than fix Jawin's
> marshaling. I wrapped other COM objects and made an interface that worked
> with the parts of Jawin that work. The getXXX is the best way but I don't
> think it need be of a known length. Return arguments can be dynamic and as
> I look at that part of Jawin it looks fairly well handled. When an argument
> is passed in a method it would need to be of a known length for filling it
> in with the return.
> >
> > Does that sound about right?.
> >
> > BTW, Jawin really seems like a nice product (better than average
> documentation for example) and the Jawingen is GREAT, but not handling basic
> parameters like this is a really big hole. I've already tried JCOM2 (didn't
> work at all for me) and JACOB seems to be dead with respect to new
> development (support group exists), so it looks like I might have to pay for
> either JacoZoom or Java2COM if there isn't some work around. To me, Jawin
> showed the most promise of the non-commerical products.
>
> I reached this same situation a couple of years ago and haven't went back
> and reevaluated the techs so thanks for doing it:-) I think with refactor,
> 1.5 and nio Jawin could be even more useful. Are you familiar with COM
> callbacks? Event handling? It's been a while. But these need to be added
> to Jawin as well. I started looking into using vtables but haven't found a
> way to pass things back to Java. I've usually pushed things back with a
> socket.
>
> >
> >
> >
> > -------------- Original message from Roger I Martin PhD : --------------
> > > Are you writing both sides?
> > >
> > > primitives such as int and float can go across as int[] on the Java side
> and
> > > int* on the COM side.
> > >
> > > Creation of objects on the COM and passed back up thru the argument list
> may
> > > not be supported. (Recognise that I didn't write the original
> marshaling; am
> > > talking with others about giving it a refactoring). If you are writing
> both
> > > side you can make the Java side have a String of the correct size and
> fill
> > > it in. Some Variants are working but anything with dynamic data has this
> > > same problem. (The longated marshalling byte array does not seem to
> allow
> > > for chunks to get larger or smaller (could be very inefficient). The
> > > marshaling takes everything out of pointers and lays their data end to
> end.
> > > I don't see anything growing and shrinking this array in the code. IMO
> > > needs a rewrite. Also there are new native io and JNI functionality to
> take
> > > advantage of in 1.5. May leap over 1.4 or have what can work with 1.4.
> > >
> > >
> > > ----- Original Message -----
> > > From: "Darrin Smith"
> > > To:
> > > Sent: Friday, June 04, 2004 12:10 PM
> > > Subject: [JAWIN] Help please: Trouble getting a value back from COM.
> > >
> > >
> > > > How do you need to set up the COM side to be able to get a value back
> to
> > > > your Jawin application without using simple getXXX methods? In other
> > > words,
> > > > I'd like to have a method that returns a value based on a parameter I
> > > send.
> > > >
> > > > For example, I have a DLL that had a method that looks like this:
> > > >
> > > > STDMETHODIMP CValidateLogin::Garbage(BSTR InputString, int InputInt,
> BSTR
> > > > returnString)
> > > > {
> > > > returnString = CString(_T("blah")).AllocSysString();
> > > > return 0;
> > > > }
> > > >
> > > > I can call this just fine, but of course I can't get the value back
> out
> > > > (call by value on the returnString), so I modified the Garbage method
> to
> > > > take an array. It ended up looking like this:
> > > >
> > > > STDMETHODIMP CValidateLogin::Garbage(BSTR InputString, int
> InputInt,BSTR
> > > > returnString[1])
> > > > {
> > > > returnString[0] = CString(_T("blah")).AllocSysString();
> > > > return 0;
> > > > }
> > > >
> > > > This compiled just fine after changing the IDL and header file, but
> when I
> > > > ran it through the Jawin Type Browser, it would hang (out of memory I
> > > > think...even after I upped it to 256meg).
> > > >
> > > > Next, I and a coworker (COM guy) tried to use a VARIANT like this:
> > > >
> > > > STDMETHODIMP CValidateLogin::Garbage(BSTR InputString, int
> > > > InputInt,VARIANT* returnString)
> > > > {
> > > > returnString->bstrVal = CString(_T("blah")).AllocSysString();
> > > > return 0;
> > > > }
> > > >
> > > > When that is run through the Jawin Type Browser, it ends up with this:
> > > >
> > > > public void Garbage(String InputString,int InputInt,Variant[]
> > > returnString)
> > > > throws COMException
> > > > {
> > > > invokeN("Garbage", new Object[] {InputString, new Integer(InputInt),
> > > > returnString});
> > > > }
> > > >
> > > > This is just fine, but when I run this:
> > > >
> > > > Variant[] v = new Variant[5];
> > > >
> > > > iLogin.Garbage("InputString", 5, v);
> > > >
> > > > it gives me this error:
> > > >
> > > > An unexpected exception has been detected in native code outside the
> VM.
> > > > Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred
> at
> > > > PC=0x7715CB4D
> > > > Function=SafeArrayAllocDescriptor+0xA0
> > > > Library=C:\WINDOWS\system32\OLEAUT32.dll
> > > > Current Java thread:
> > > > at org.jawin.marshal.GenericStub.dispatchInvoke0(Native Method)
> > > > at org.jawin.marshal.GenericStub.dispatchInvoke(GenericStub.java:84)
> > > > at org.jawin.DispatchPtr.invokeN(DispatchPtr.java:473)
> > > > at org.jawin.DispatchPtr.invokeN(DispatchPtr.java:433)
> > > > ...
> > > >
> > > >
> > > > So, my question is, how are you supposed to get a value back from COM?
> > > >
> > > > Can someone provide me with an example please? This should be simple
> to do
> > > > but I can't find any example of how to do it using Jawin.
> > > >
> > > > THANKS!