MS Office automation example broken with 4.2.1 release

[9percent]

The JNA MS office example from: https://github.com/java-native-access/jna/tree/master/contrib/msoffice is broken.
The example code works fine with JNA 4.1.0, but when I update JNA to latest 4.2.1 release, it's broken.
I get the following exception:

Exception in thread "main" com.sun.jna.platform.win32.COM.COMException: A null reference pointer was passed to the stub. (puArgErr=)
at com.sun.jna.platform.win32.COM.COMUtils.checkRC(COMUtils.java:112)
at com.sun.jna.platform.win32.COM.COMUtils.checkRC(COMUtils.java:95)
at com.sun.jna.platform.win32.COM.COMBindingBaseObject.oleMethod(COMBindingBaseObject.java:217)
at com.sun.jna.platform.win32.COM.COMBindingBaseObject.oleMethod(COMBindingBaseObject.java:322)
at com.sun.jna.platform.win32.COM.COMLateBindingObject.invokeNoReply(COMLateBindingObject.java:422)
at testjna.MSExcel.quit(MSExcel.java:42)
at testjna.MSOfficeDemo.testMSExcel(MSOfficeDemo.java:120)
at testjna.MSOfficeDemo.(MSOfficeDemo.java:21)
at testjna.MSOfficeDemo.main(MSOfficeDemo.java:13)

[lwahonen]

This test seems to be working ok for me. I tried using both master and 4.2.1 versions of JNA, with Office 16.0. Which version of Office are you using? Are you using JNA from a jar or from sources?

[lwahonen]

The NPE is #412, actually.

[9percent]

I am using Office 15 (Office 2013) Windows 7, using JNA from jar(jna.jar& jna-platform.jar)

[burksr]

I receive this error as well. I'm using Excel 16 on Windows 10 with the jars. It works when I us 4.1.0, but not 4.2.1. The Excel application seems to be created, but if I try to invoke any methods, or set any properties, this error happens.

[SevenOf9Sleeper]

Hi there, I had the same problem with Word 2007, Java 8 (32-Bit). When I switched to 64-Bit-Java the call of setProperty works well.

[9percent]

Hi @dblock @lwahonen ,
I can confirm this issue only happens on 32 bit JVM, and still exists in 4.2.2 release.
Will you mark this issue as a bug?

[dblock]

bug? => bug

[matthiasblaesing]

There were several fixes that already went into the 4.3 branch, at least one segfault was fixed (callbacks). I updated the msoffice sample:

https://github.com/matthiasblaesing/jna/tree/msoffice_enhancement

and would appreciate further tests. With this branch I tested:

• Java 1.8.0_77 64 Bit + Office 2013 64 Bit (Testversion)
• Java 1.8.0_77 32 Bit + Office 2013 64 Bit (Testversion)
• Java 1.8.0_60 64 Bit + Office 2007 32 Bit
• Java 1.8.0_60 32 Bit + Office 2007 32 Bit

With these calls:

java -cp demo-msoffice.jar com.sun.jna.platform.win32.COM.office.MSOfficeDemo
java -cp demo-msoffice.jar com.sun.jna.platform.win32.COM.util.office.Excelautomation_KB_219151_Mod
java -cp demo-msoffice.jar com.sun.jna.platform.win32.COM.util.office.Wordautomation_KB_313193_Mod
java -cp demo-msoffice.jar com.sun.jna.platform.win32.COM.util.office.MSOfficeWordDemo
java -cp demo-msoffice.jar com.sun.jna.platform.win32.COM.util.office.MSOfficeExcelDemo

Please note: the head of the branch contains the version for english locales, I offer prebuild versions:

DE: http://www.doppel-helix.eu/demo-msoffice.jar
EN: http://www.doppel-helix.eu/demo-msoffice-en.jar

[SevenOf9Sleeper]

When I start the MSOfficeDemo in the actual 4.3-branch (4b7421c) I get following error:

com.sun.jna.platform.win32.COM.COMException: COM object with ProgID 'Excel.Application' and CLSID {00024500-0000-0000-C000-000000000046} not registered properly!
    at com.sun.jna.platform.win32.COM.COMBindingBaseObject.<init>(COMBindingBaseObject.java:134)
    at com.sun.jna.platform.win32.COM.COMBindingBaseObject.<init>(COMBindingBaseObject.java:144)
    at com.sun.jna.platform.win32.COM.COMLateBindingObject.<init>(COMLateBindingObject.java:66)
    at com.sun.jna.platform.win32.COM.office.MSExcel.<init>(MSExcel.java:11)
    at com.sun.jna.platform.win32.COM.office.MSOfficeDemo.testMSExcel(MSOfficeDemo.java:100)
    at com.sun.jna.platform.win32.COM.office.MSOfficeDemo.<init>(MSOfficeDemo.java:22)
    at com.sun.jna.platform.win32.COM.office.MSOfficeDemo.main(MSOfficeDemo.java:14)

It is with Java8, Java7, 32 Bit or 64 Bit all the same. I use Excel 2016 on Windows 7.

When I use JNA to start Excel in this way, all is working fine:

        com.sun.jna.platform.win32.COM.util.Factory factory = new com.sun.jna.platform.win32.COM.util.Factory();
        Application app = factory.createObject(Application.class);

and Application is:

@ComObject(clsId = "{00024500-0000-0000-C000-000000000046}")
public interface Application extends _Application, IConnectionPoint {
}

So the application is registered properly... Is this a problem of the resolution of the progID?

[matthiasblaesing]

The example in HEAD is is broken, as the COM subsystem is not correctly initialized (please run with assertions enabled, than it should show). And I would bet, that:

        // This is line 128
        } else {
            hr = Ole32.INSTANCE.CoCreateInstance(clsid, null, dwClsContext,
                    IDispatch.IID_IDISPATCH, this.pDispatch);
        }

        if (COMUtils.FAILED(hr)) {
            throw new COMException("COM object with ProgID '" + progId
                    + "' and CLSID " + clsid.toGuidString()
                    + " not registered properly!");
        }

fails because that precondition is not met. That was one of the things covered in the patch (correctly initialize COM).

[matthiasblaesing]

I doubt that the ProgId can't be resolved, as that happens around line 109 in ComBindingBaseObject:

        // Get CLSID for Word.Application...
        CLSID.ByReference clsid = new CLSID.ByReference();
        hr = Ole32.INSTANCE.CLSIDFromProgID(progId, clsid);

        if (COMUtils.FAILED(hr)) {
            throw new COMException("CLSIDFromProgID() failed!");
        }

As this is error checked, it should have failed earlier

[SevenOf9Sleeper]

@matthiasblaesing ah, yes, you are right. The initialization isn't done. But the error handling in MSOfficeDemo is quite misleading. If the FAILED hr code would have been tested with COMUtils.checkRC(hr) then there is the enlightening error message:
com.sun.jna.platform.win32.COM.COMException: CoInitialize wurde nicht aufgerufen.(HRESULT: 800401f0) (puArgErr=)
(in english: CoInitialize wasn't been called)
Wouldn't it be better to use COMUtils.checkRC() in COMBindingBaseObject instead of creating a misleading error message?

[matthiasblaesing]

@SevenOf9Sleeper - both your point are correct:

• Yes COMBindingBaseObject should be optimized (I registered that as COMBindingBaseObject should use COMUtils#checkRC() #646)
• c:\temp should not be hardcoded (raised in pull request COM initialization must be done before accessing COM methods #645), this is fixed in the WIP branch and the provided binaries were updated

I'd appreciate another testrun.