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!
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.