#150 OneNote COM interface incompatibility

[Ashok P. Nadkarni]

From Paul Obermeir:

Hi Ashok,

A CAWT user just recently asked, if it is possible to use CAWT for OneNote automation.

So I did an internet search and found, that OneNote does have a COM interface, ex.
https://msdn.microsoft.com/library/ms788684%28office.12%29.aspx#Office2007OneNoteWhatsNew_OneNote2007COMAPI

Starting OneNote with TWAPI succeeded:

set appId [twapi::comobj OneNote.Application]

But when I try to use the object, ex.

$appId Application
I get an error message "Library not registered" (Note, that this is my translation from the German error message into English)

After looking through the TWAPI documentation, I found the "-registration" option of the twapi::ITypeLibProxy_from_path command.

So I tried:
set applName "C:/Program Files/Microsoft Office 15/root/office15/ONENOTE.EXE"
set typeLib [twapi::ITypeLibProxy_from_path $applName -registration register] set appId [twapi::comobj OneNote.Application] $appId Application

Here I get an error message from the ITypeLibProxy_from_path command:
Error loading type library/DLL.

Next was to try another OneNote related library, which looked like the right one:
set applName "C:/Program Files/Microsoft Office 15/root/office15/ONLNTCOMLIB.DLL"
set typeLib [twapi::ITypeLibProxy_from_path $applName -registration register] set appId [twapi::comobj OneNote.Application] $appId Application

Here ITypeLibProxy_from_path succeeds, but again I get the "Library not registered" error message.

So my question to the Windows expert:
Is the "-registration" way the right one (and there is something wrong in my code) or am I completely on the wrong way??

Thanks for any insights,

Paul

[Ashok P. Nadkarni]

Thanks for the fast response.

Unfortunately the registry trick did not help. I have tested with 2 Office 2013 and 1 Office 2016 installation on Windows8 systems and still get the error message.

But the information, that it works on your system helps me a lot.
Now that I know, that in principle it should work and I'm not doing something wrong, I can hopefully search the web for the error causes.
Maybe it has to do with the German Windows or Office??

Or I may ask some of the CAWT users to test it on their systems.
Did you use the ITypeLibProxy_from_path command in your test or would the following 3-liner be sufficient for testers:

package require twapi
set appId [twapi::comobj OneNote.Application] $appId -print

Paul

Am 25.01.2016 um 08:06 schrieb Ashok P. Nadkarni:

Spent some time looking into this with no clear conclusion. Some research shows that the issue may be caused by multiple Office installations after which some have been uninstalled. The closest possible solution seems to be the note below from https://github.com/varunsrin/one-py:

---

(Office 2013) This COM object can not automate the makepy process -
please run makepy manually for this object To work around this, run
regedit.exe, and navigate to

HKEY_CLASSES_ROOT\TypeLib{0EA692EE-BB50-4E3C-AEF0-356D91732725}
There should only be one subfolder in this class called 1.1. If you see 1.0 or any other folders, you'll need to delete them. The final hierarchy should look like this:

|- {0EA692EE-BB50-4E3C-AEF0-356D91732725}
| |- 1.1
| |-0
| | |- win32
| |- FLAGDS
| |- HELPDIR

---

I had the same problem on my system so I deleted the 1.0 key. (If not running Office 2013, key may be different). Then I no longer get the "Library not registered" error and $appId -print shows the available methods (Application is not one of them).

You can see if this is also an issue on your system and whether deleting the 1.0 key solves the problem.

/Ashok