|
AdrianP
Posts: 13
Joined: 2024-05-25
|
Hello,
I just noticed that HostStartMode is set to ADXHostStartMode.hsmUnknown for my Outlook addin, and I can't figure out why. I created a new project, with an empty module, no ribbon tabs, task panes or anything else, just a switch(HostStartMode) in the AddinInitialize event, and the result is identical. If I create a project for Word, it seems to work as I would expect (it's set to "hsmFromUI"). It is very likely that I'm missing something, but I don't know what :-)
My Outlook version string reads: "Microsoft® Outlook® 2019 MSO (Version 2405 Build 16.0.17628.20006) 32-bit" and I'm using latest ADX version with VS2022, on Win10.
Regards! |
|
Posted 11 Jun, 2024 19:24:29
|
|
Top
|
|
Andrei Smolin
Add-in Express team
Posts: 18965
Joined: 2006-05-11
|
Hello Adrian,
I get hsmUnknown after clicking a Ribbon button in my Outlook 365 Version 2405 (Build 17628.20110 Click-to-Run) Current Channel.
In the code of Add-in Express, I see that this is caused by Outlook providing the add-in with an incorrect value. I'll debug this issue and provide more details. I suppose I'll have a result later this week.
Regards from Poland (GMT+2),
Andrei Smolin
Add-in Express Team Leader |
|
Posted 11 Jun, 2024 22:42:12
|
|
Top
|
|
AdrianP
Posts: 13
Joined: 2024-05-25
|
|
Posted 12 Jun, 2024 17:15:57
|
|
Top
|
|
Andrei Smolin
Add-in Express team
Posts: 18965
Joined: 2006-05-11
|
Hello Adrian,
The issue is caused by Outlook. Unlike Excel, Word, and PowerPoint, it doesn't provide a value for the parameter called custom when it calls the IDTExtensibility2.OnConnection() method that the add-in implements. The method is described e.g. at https://learn.microsoft.com/en-us/dotnet/api/extensibility.idtextensibility2.onconnection?view=visualstudiosdk-2022.
I cannot find a page describing whether Office applications must pass anything to this parameter. I know such a page did exist; it looks like MS deleted it as they deleted many pages describing creating COM add-in for Office 2000 and 20002. Or, maybe it's just me being unable to find that page.
Regards from Poland (GMT+2),
Andrei Smolin
Add-in Express Team Leader |
|
Posted 13 Jun, 2024 10:50:45
|
|
Top
|
|
AdrianP
Posts: 13
Joined: 2024-05-25
|
Hello Andrei and thanks!
Well, it is what it is then, not much we can do about it :-) If I find something about it, I'll post here.
Have a good weekend! |
|
Posted 13 Jun, 2024 14:03:36
|
|
Top
|
|
Andrei Smolin
Add-in Express team
Posts: 18965
Joined: 2006-05-11
|
Have a good weekend!
Regards from Poland (GMT+2),
Andrei Smolin
Add-in Express Team Leader |
|
Posted 14 Jun, 2024 15:23:17
|
|
Top
|
|
AdrianP
Posts: 13
Joined: 2024-05-25
|
While doing some more digging in connection with https://www.add-in-express.com/forum/read.php?FID=5&TID=16686
I casually checked adxloader.log and noticed that the host process command line is logged, so it is known to the loader.
I started Outlook in 3 different scenarios:
1. Normally, and the command line from adxloader.log reads
"C:\Program Files (x86)\Microsoft Office\Root\Office16\OUTLOOK.EXE"
2. From any MS Office app, by using File->Share->Email->Send as attachment, and the command line from adxloader.log reads
"C:\Program Files (x86)\Microsoft Office\root\Office16\Outlook.exe" /simplemapi {F805811F-1880-446D-A858-32F83CFBE22E}#{C34EC8E8-EE65-4C32-BF1D-A11012CF5136} /ack {34116CC0-0F2A-4C89-89F3-29EBA14BA700}
3. From Windows Explorer, by using right-click->Send to mail recipient, and the command line from adxloader.log reads
"C:\Program Files (x86)\Microsoft Office\Root\Office16\OUTLOOK.EXE" -Embedding
So, I think that by simply checking the cmd line, one can get a good idea about how host was started, circumventing the need for ADXHostStartMode in the Outlook particular case. Is it possible for the addin module to retrieve the host command line from the loader? It would be a nice thing :-)
There is a way to get it directly, by calling GetWindowThreadProcessId with this.NativeWindowHandle to retrieve the PID that started the Outlook window and, from there, using either WMI or NtQueryInformationProcess/ReadProcessMemory to get to the command line. I tried the WMI route and it works, but seems kinda overkill to me, pulling the System.Management to read a string.
Having a HostCmdLine property would be useful, I think. Maybe in some future update =)
Regards,
Adrian |
|
Posted 13 Jul, 2024 07:30:59
|
|
Top
|
|
Andrei Smolin
Add-in Express team
Posts: 18965
Joined: 2006-05-11
|
|
Posted 15 Jul, 2024 12:02:39
|
|
Top
|
|
AdrianP
Posts: 13
Joined: 2024-05-25
|
Hello Andrei and thanks for the link, bookmarked.
You're right, using Process.GetCurrentProcess() seems indeed less arcane than Pinvoke/GetWindowThreadProcessId, but still uses WMI for cmd line retrieval. I'll do some more test and decide if I'll follow this route.
Regards,
Adrian |
|
Posted 15 Jul, 2024 15:58:46
|
|
Top
|
|
Andrei Smolin
Add-in Express team
Posts: 18965
Joined: 2006-05-11
|
You are welcome!
Regards from Poland (GMT+2),
Andrei Smolin
Add-in Express Team Leader |
|
Posted 17 Jul, 2024 14:24:15
|
|
Top
|
|