Type not supported: 13

51 views
Skip to first unread message

Oyvind Foshaug

unread,
May 30, 2017, 9:16:58 AM5/30/17
to Java Native Access
Hi,

I get an error



Exception in thread "main" java.lang.IllegalStateException: Type not supported: 13

at com.sun.jna.platform.win32.OaIdlUtil.toPrimitiveArray(OaIdlUtil.java:272)

at com.sun.jna.platform.win32.OaIdlUtil.toPrimitiveArray(OaIdlUtil.java:284)

at com.sun.jna.platform.win32.OaIdlUtil.toPrimitiveArray(OaIdlUtil.java:176)

at test.Import.main(Import.java:153)


when running this code:


SAFEARRAY sa= new SAFEARRAY(pbr3.getValue());


Object[] objectResult = (Object[]) OaIdlUtil.toPrimitiveArray(sa, false);



When I loop through, the cause of the error are text cells (or at least they appear to be when accessed in Excel).

How can I debug this?


Thanks,


Oyvind


Oyvind Foshaug

unread,
May 30, 2017, 9:36:44 AM5/30/17
to Java Native Access
The text cells all start with an ', for display-formatting in Excel. That is probably the cause, since the first cell is translated properly and only this call does not have the leading ' character.



Op dinsdag 30 mei 2017 15:16:58 UTC+2 schreef Oyvind Foshaug:

Matthias Bläsing

unread,
May 30, 2017, 12:59:13 PM5/30/17
to jna-...@googlegroups.com
Hey Oyvind,

Am Dienstag, den 30.05.2017, 06:36 -0700 schrieb Oyvind Foshaug:
> The text cells all start with an ', for display-formatting in Excel.
> That is probably the cause, since the first cell is translated
> properly and only this call does not have the leading ' character.
>
>
>
> Op dinsdag 30 mei 2017 15:16:58 UTC+2 schreef Oyvind Foshaug:
> > Hi,
> >
> > I get an error
> >
> >
> > Exception in thread "main" java.lang.IllegalStateException: Type not supported: 13
> > at com.sun.jna.platform.win32.OaIdlUtil.toPrimitiveArray(OaIdlUtil.java:272)
> > at com.sun.jna.platform.win32.OaIdlUtil.toPrimitiveArray(OaIdlUtil.java:284)
> > at com.sun.jna.platform.win32.OaIdlUtil.toPrimitiveArray(OaIdlUtil.java:176)
> > at test.Import.main(Import.java:153)
> >
> > when running this code:
> >
> > SAFEARRAY sa= new SAFEARRAY(pbr3.getValue());
> >
> > Object[] objectResult = (Object[]) OaIdlUtil.toPrimitiveArray(sa, false);
> >


varType 13 is VT_UNKNOWN. So what you get from excel is not a
primitive, but a COM interface.

The toPrimitiveArray was implemented not so much to make it easier to
access COM arrays, but to do that fast.

I did not come accross this. What you can do:

- iterate over the SAFEARRAY yourself (it contains VARIANTs)
- Use OleAuto.INSTANCE.VariantChangeType to coerce the VT_UNKNOWN into
your target format

HTH

Matthias

Oyvind Foshaug

unread,
May 31, 2017, 3:44:37 AM5/31/17
to Java Native Access
Hi Matthias,
Thanks so much for the quick response. I cannot find the method you refer to OleAuto.INSTANCE.VariantChangeType in 4.4.0. Do I need to set up development environment ? In that case, any instructions for Eclipse available? 

Gr, Oyvind


Op dinsdag 30 mei 2017 15:16:58 UTC+2 schreef Oyvind Foshaug:
Hi,

Oyvind Foshaug

unread,
May 31, 2017, 6:52:50 AM5/31/17
to Java Native Access
Update:
I found the snapshot in the Sonatype repository, so that issue is solved.
I still get valuetype 13:

OleAuto.INSTANCE.VariantChangeType(var, var,(short) 1, new VARTYPE(Variant.VT_BSTR));

System.out.println(var.getVarType());


gr,
Oyvind




Op woensdag 31 mei 2017 09:44:37 UTC+2 schreef Oyvind Foshaug:

Matthias Bläsing

unread,
May 31, 2017, 3:21:01 PM5/31/17
to jna-...@googlegroups.com
Hey,


Am Mittwoch, den 31.05.2017, 03:52 -0700 schrieb Oyvind Foshaug:
> Update:
> I found the snapshot in the Sonatype repository, so that issue is
> solved.

Sorry, I did not realize, that I merged that in the 4.5.0 cycle.

> I still get valuetype 13:
>
> OleAuto.INSTANCE.VariantChangeType(var, var,(short) 1, new
> VARTYPE(Variant.VT_BSTR));
> System.out.println(var.getVarType());
>

You explizitly asked the system to to so:

HRESULT VariantChangeType(
  _Out_       VARIANTARG *pvargDest,
  _In_  const VARIANTARG *pvarSrc,
  _In_        USHORT     wFlags,
  _In_        VARTYPE    vt
);

wFlags [in]

    Flags.
    Value Meaning

    VARIANT_NOVALUEPROP

    Prevents the function from attempting to coerce an object to a
fundamental type by getting the Value property. Applications should set
this flag only if necessary, because it makes their behavior
inconsistent with other applications.


VARIANT_NOVALUEPROP has the value 1!

Try to pass 0.

Greetings

Matthias

Oyvind Foshaug

unread,
May 31, 2017, 3:41:08 PM5/31/17
to Java Native Access
Hi,

OK, I changed that to 0 but to no avail. The result from the function is 0x7FFDFFF8, I searched but could not find the interpretation of the error code.

Gr,
Oyvind



Op woensdag 31 mei 2017 21:21:01 UTC+2 schreef Matthias Bläsing:

Matthias Bläsing

unread,
May 31, 2017, 3:46:01 PM5/31/17
to jna-...@googlegroups.com
Hey,

Am Mittwoch, den 31.05.2017, 12:41 -0700 schrieb Oyvind Foshaug:
>
> OK, I changed that to 0 but to no avail. The result from the function
> is 0x7FFDFFF8, I searched but could not find the interpretation of
> the error code.
>

Please run the return of VariantChangeType through:

com.sun.jna.platform.win32.COM.COMUtils#checkRC

Greetings

Matthias

Oyvind Foshaug

unread,
May 31, 2017, 3:53:03 PM5/31/17
to Java Native Access
Hi,
This is what I get (first the HR):

-2147352568

Exception in thread "main" com.sun.jna.platform.win32.COM.COMException: Bad variable type.(HRESULT: 80020008) (puArgErr=)

at com.sun.jna.platform.win32.COM.COMUtils.checkRC(COMUtils.java:131)

at com.sun.jna.platform.win32.COM.COMUtils.checkRC(COMUtils.java:108)

 





Op woensdag 31 mei 2017 21:46:01 UTC+2 schreef Matthias Bläsing:

Matthias Bläsing

unread,
May 31, 2017, 4:06:02 PM5/31/17
to jna-...@googlegroups.com
Hey,

Am Mittwoch, den 31.05.2017, 12:53 -0700 schrieb Oyvind Foshaug:
> Hi,
> This is what I get (first the HR):
>
> -2147352568
> Exception in thread "main" com.sun.jna.platform.win32.COM.COMException: Bad variable type.(HRESULT: 80020008) (puArgErr=)
> at com.sun.jna.platform.win32.COM.COMUtils.checkRC(COMUtils.java:131)
> at com.sun.jna.platform.win32.COM.COMUtils.checkRC(COMUtils.java:108)
>  

sorry, no idea. Can you make a minimal sample (code + data) that
reproduces the problem?

Then I'm willing to look it some more.

Greetings

Matthias

Oyvind Foshaug

unread,
May 31, 2017, 4:24:18 PM5/31/17
to Java Native Access
Sounds great, I will send you the data and code but it has to be tomorrow (I notice we have 9 hour timedifference).
I guess serialization of the VARIANT array and send it in a text file is the way to do this?

Thanks

Op woensdag 31 mei 2017 22:06:02 UTC+2 schreef Matthias Bläsing:

Matthias Bläsing

unread,
May 31, 2017, 4:30:38 PM5/31/17
to jna-...@googlegroups.com
Hey,

Am Mittwoch, den 31.05.2017, 13:24 -0700 schrieb Oyvind Foshaug:
> Sounds great, I will send you the data and code but it has to be
> tomorrow (I notice we have 9 hour timedifference).
> I guess serialization of the VARIANT array and send it in a text file
> is the way to do this?

If I read your messages correctly you extract data from excel (you
spoke about test cells), I think my test office license should work for
that.

The preferred form would be a public git repository with the code and
sample data (make sure data is clean and you are not leaking sensitive
info). If this is just java code + data I can work with that, if it is
a directly runnable maven project that would be awesome.

Greetings

Matthias

Oyvind Foshaug

unread,
Jun 2, 2017, 6:08:41 AM6/2/17
to Java Native Access
Hi again,

I've set up a repository:
https://github.com/oyvfos/rep1

The task is not about data from Excel, but from a COM interface to a properitary application at work.
As such I can only mimic the interface. The dll and the Visual basic files are in the resources folder in the repository .
You could either use VS 2015 or above to rebuild the COM dll (this will do registering for you if you run as an adminstrator),or register the COM dll the usual way.

I have modified the mmarquee ui autmation project for my purposes. The starting point is com.test.Import class.

At this point I am still working to reproduce the error I told you about. Hopefully that will be resolved within a short time. 

Op woensdag 31 mei 2017 22:30:38 UTC+2 schreef Matthias Bläsing:
Message has been deleted

Oyvind Foshaug

unread,
Jun 2, 2017, 10:44:49 AM6/2/17
to Java Native Access
Update
Functions work properly, and I cannot reproduce the error I am afraid. The Unknown problem I experience with the real interface  has to do something about the formatting of the cells in the object array, But what it is I do not know (Ive tried different characters etc ).
Any ideas?

Op vrijdag 2 juni 2017 12:08:41 UTC+2 schreef Oyvind Foshaug:

Matthias Bläsing

unread,
Jun 3, 2017, 8:17:39 AM6/3/17
to jna-...@googlegroups.com
Hey,

Am Freitag, den 02.06.2017, 07:44 -0700 schrieb Oyvind Foshaug:
> Update Functions work properly, and I cannot reproduce the error I am
> afraid. The Unknown problem I experience with the real interface  has
> to do something about the formatting of the cells in the object
> array, But what it is I do not know (Ive tried different characters
> etc ). 
> Any ideas?

No, sorry. You can try to ask the producer of the library what goes on.
The documentation for VariantChangeType has to say:

An object is coerced to a value by invoking the object's Value
property (DISPID_VALUE).

So if the IUnknown you retrieve is either not a IDispatch or does not
handle the DISPID_VALUE.

Matthias

Oyvind Foshaug

unread,
Jun 7, 2017, 3:29:27 AM6/7/17
to Java Native Access
Hi,
I made a silly mistake so issue solved. The IUnknown is indeed a pointer to an interface, which needs to be accessed via invokeInt () the usual way.


Now I have stumbled into something different. I want to invoke this function :

        HRESULT Func(

                        [in] BSTR str1,

                        [in] BSTR str2,

                        [in] BSTR str3,

                        [out, retval] HRESULT* retVal);

Do I simply call invokeInt like this (which does not seem to work):

return f.invokeInt(new Object[]{myInterfacePointer

,"aa","bb","cc"

});


?

Thanks,
Oyvind



Op zaterdag 3 juni 2017 14:17:39 UTC+2 schreef Matthias Bläsing:

Kustaa Nyholm

unread,
Jun 7, 2017, 3:33:09 AM6/7/17
to jna-...@googlegroups.com
I don't know anything about this but you seem to be giving the function 3 parameters when it expects 4...

wbr K


From: "jna-...@googlegroups.com" <jna-...@googlegroups.com> on behalf of Oyvind Foshaug <oyvind....@gmail.com>
Reply-To: "jna-...@googlegroups.com" <jna-...@googlegroups.com>
Date: Wednesday, 7 June 2017 10:29
To: "jna-...@googlegroups.com" <jna-...@googlegroups.com>
Subject: Re: Type not supported: 13

Hi,
I made a silly mistake so issue solved. The IUnknown is indeed a pointer to an interface, which needs to be accessed via invokeInt () the usual way.


Now I have stumbled into something different. I want to invoke this function :

        HRESULT Func(

                        [in] BSTR str1,

                        [in] BSTR str2,

                        [in] BSTR str3,

                        [out, retval] HRESULT* retVal);

Do I simply call invokeInt like this (which does not seem to work):

returnf.invokeInt(new Object[]{myInterfacePointer

,"aa","bb","cc"

});


?

Thanks,
Oyvind



Op zaterdag 3 juni 2017 14:17:39 UTC+2 schreef Matthias Bläsing:
Hey,

Am Freitag, den 02.06.2017, 07:44 -0700 schrieb Oyvind Foshaug:
> Update Functions work properly, and I cannot reproduce the error I am
> afraid. The Unknown problem I experience with the real interface  has
> to do something about the formatting of the cells in the object
> array, But what it is I do not know (Ive tried different characters
> etc ). 
> Any ideas?

No, sorry. You can try to ask the producer of the library what goes on.
 The documentation for VariantChangeType has to say:

    An object is coerced to a value by invoking the object's Value
    property (DISPID_VALUE).

So if the IUnknown you retrieve is either not a IDispatch or does not
handle the DISPID_VALUE.

Matthias

--
You received this message because you are subscribed to the Google Groups "Java Native Access" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jna-users+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Oyvind Foshaug

unread,
Jun 7, 2017, 10:47:29 AM6/7/17
to Java Native Access
I think the InvokeInt takes care of the last parameter.

This was BTW a false alarm.

returnf.invokeInt(new Object[]{myInterfacePointer

,"aa","bb","cc"

});


should be


returnf.invokeInt(new Object[]{myInterfacePointer

,new BSTR("aa"),new BSTR("bb"),new BSTR("cc")

});

 

Thanks

Oyvind



Op woensdag 7 juni 2017 09:33:09 UTC+2 schreef nyholku:

Matthias Bläsing

unread,
Jun 7, 2017, 1:35:20 PM6/7/17
to jna-...@googlegroups.com
Hey,

Am Mittwoch, den 07.06.2017, 07:47 -0700 schrieb Oyvind Foshaug:
> I think the InvokeInt takes care of the last parameter.
>
> This was BTW a false alarm.
> returnf.invokeInt(new Object[]{myInterfacePointer
> ,"aa","bb","cc"
> });
>
> should be
>
> returnf.invokeInt(new Object[]{myInterfacePointer
> ,new BSTR("aa"),new BSTR("bb"),new BSTR("cc")
> });
>  

beware! The out parameter is _not_ the return value of invokeInt.

You can see a sample in:

com.sun.jna.platform.win32.COM.TypeLib

That is the implementation of the bindings for ITypeLib. Look at
GetDocumentation:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms221396(v=vs.
85).aspx

That method has 4 out values. The return value is the HRESULT.

HTH

Matthias
Reply all
Reply to author
Forward
0 new messages