ActiveExplorer return NULL on new Window user login and running Outlook first time

[Shawn]

I'm trying to figure out why ActiveExplorer is returning NULL when the user is a new user login (logged into windows for the first time) and then start outlook for the first time, ActiveExplorer return NULL and we cannot display our command bar and menu bar.

If the user exit Outlook and then start Outlook again, ActiveExplorer return a pointer to ExplorerPtr and then we can display our command bar and menu bar.

Is there something else we can get ExplorerPtr when a user run Outlook for the first time for a new windows user that login for the first time?.
Submitted using http://www.outlookforums.com

 

[Ken Slovak - [MVP - Outlook]]

When are you testing for ActiveExplorer? It should not be in OnConnection()
but in or after OnStartupComplete(). You don't mention the type of code or
Outlook version, so it's hard to be specific without adequate information.

It also may work better if you check the Explorers.Count and if there is at
least one Explorer access Explorers[1] to get a handle to that Explorer.

 

[Dmitry Streblechenko]

Also note that there won't be any explorers if Outlook is launched
programmatically withour diaplysing any UI or if, for example, mailto link
opens an inspector t oedit a new e-mail (no explorers).

--
Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool
-

 

[Shawn]

We get the pointer to IOutlookExtCallback and IID_IDispatch from Install on EECONTEXT_TASK. When we get back into Install on EECONTEXT_VIEWER is when we try to create the menu/toolbar which is where IOutlookExtCallback::ActiveExplorer() is returning NULL.

We are not using IDTExtensibility2 OnConnection/OnStartupComplete which I was not aware of that until now. I'll take a look at that.

kenslovak wrote on Wed, 14 April 2010 14:3

When are you testing for ActiveExplorer? It should not be in OnConnection()
but in or after OnStartupComplete(). You don't mention the type of code or
Outlook version, so it's hard to be specific without adequate information.

It also may work better if you check the Explorers.Count and if there is at
least one Explorer access Explorers[1] to get a handle to that Explorer.

I'm trying to figure out why ActiveExplorer is returning NULL when the
user is a new user login (logged into windows for the first time) and then
start outlook for the first time, ActiveExplorer return NULL and we cannot
display our command bar and menu bar.

If the user exit Outlook and then start Outlook again, ActiveExplorer
return a pointer to ExplorerPtr and then we can display our command bar
and menu bar.

Is there something else we can get ExplorerPtr when a user run Outlook for
the first time for a new windows user that login for the first time?.
Submitted using http://www.outlookforums.co

 

[Ken Slovak - [MVP - Outlook]]

Those events are for COM addins, if you aren't writing a COM addin the
events won't be available.

 

[Shawn]

Okay, I'm back to working on this. This DLL is a COM addin. We do get events from Outlook when a user click on a message and such. But, it is using the Exchange Client Extension which has been deprecated and from my understanding, 2010 is no longer supporting Exchange Client Extension.

So now, we need to convert the code from using Exchange Client Extension to IDTExtensibility2.

kenslovak wrote on Thu, 15 April 2010 16:1

 

[Ken Slovak - [MVP - Outlook]]

OK, if it is an Exchange client extension it is not a COM addin. It is an
Outlook addin but not a COM addin. And yes, Exchange client extensions are
deprecated in Outlook 2010 and won't work there.

 

[Shawn]

Another question, do we need to use CDO.dll or that is just an option to use MAPI in the COM addin? We don't care about the messages, we just care about the folder.

kenslovak wrote on Thu, 22 April 2010 13:2

 

[Ken Slovak - [MVP - Outlook]]

No one ever has to use CDO. What API's you use depend on what you need to do
and what versions of Outlook you are programming for. It also depends on
whether or not you are using other API's such as Redemption
(www.dimastr.com/redemption). Since I have no idea why you would need CDO or
not I have no way of answering that question other than to say that in
general CDO has pretty much been deprecated or because of its security has
become less important.

 

[Shawn]

Thanks for the answer. We are not currently using CDO or Redemption. The only thing we used is the MAPI folder (IMAPIFolder interface).

kenslovak wrote on Fri, 23 April 2010 09:3

 

[Ken Slovak - [MVP - Outlook]]

MAPIFolder is exposed in the Outlook object model but that doesn't
necessarily expose everything that the Extended MAPI IMAPIFolder interface
might expose. For example if you need access to folder properties not
exposed in the object model and might need to use a CDO or Redemption Fields
collection on the folder. In that case you'd need another API unless you
were coding only for Outlook 2007 or later, where you could use the
PropertyAccessor object.

 

[Shawn]

Back on working with this issue. I finally got a COM addin working. Outlook 2007 and 2010 is working now. I have our toolbar in Outlook in both version, but it currently cannot do anything since I have not been able to figure out exactly how to get the MAPI session so that I can see what account I'm on.

I do get the notification when the user click on the folder, since that is all we care about using the SINK that I have provided below:


SINK_ENTRY_INFO(1,__uuidof(Outlook::ExplorerEvents),/*dispinterface*/0xf002,OnFolderChange,&OnSimpleEventInfo);


How do I go about getting the Extended MAPI on that folder? If I do the following:


BSTR EntryID;
CComPtr<Outlook::MAPIFolder> MapiFolder;

m_spExplorer->get_CurrentFolder(&MapiFolder);
MapiFolder->get_EntryID(&EntryID);


Once I get the "EntryID", how do I go about opening the message store (IMsgStore/LPMDB) since I need to know what message store we are dealing with..
Submitted using http://www.outlookforums.com

 

[Ken Slovak - [MVP - Outlook]]

You really need to preserve parts of preceding messages in the thread, it
makes it very hard to figure out what you're talking about when you snip
things like that.

Once you have an EntryID you need to use that to get the folder using the
NameSpace.GetFolderFromID() method.

 

[Shawn]

Thanks. Now I have another problem with Outlook 2007. Whenever I click on the toolbar button, I'm getting two invokes into my "CButtonHandler::Invoke" method. I do not get that in 2003 and 2010.

But what is strange is that I do not get two callback when I click on the menu item in the drop down menu. Just the toolbar.

Is there something else that I need to handle that issue for 2007?

kenslovak wrote on Mon, 10 May 2010 09:5

 

[Ken Slovak - [MVP - Outlook]]

There is no difference in handling a
toolbar/menu/CommandBar/CommandBarPopup/etc. in Outlook 2007, 2003, or any
other version that supports that interface.

Usually if you get 2 click events firing for one click it means that the
buttons you created use the same Tag property. Every Tag should be unique.
If more than one button has the same Tag you will get one click event per
button using that Tag.

 

[Shawn]

Are you talking about the CommandBarControl.put_Tag? If so, all of the strings is unique.

kenslovak wrote on Mon, 10 May 2010 13:0

 

[Shawn]

I resolved this issue. I changed the code to do:


CommandBarControl.put_Tag(Guid.NewGuid().ToString());


I did that to all of the CommandBarControl and the double invoke stopped. Not sure which one I was missing or had the same strings. But, using the GUID string will make it easier to not forget or have the same string.

NightCode wrote on Mon, 10 May 2010 13:5

 

[Ken Slovak - [MVP - Outlook]]

I don't like using a pure guid for that. I often have to maintain state on
things such as toggle buttons on a per Inspector basis. What I do is
maintain a key property (int) that I use as an index into wrapper
collections for Inspectors and Explorers. Each wrapper class stores the key
value for that instance, which is a unique number during that Outlook
session. Then I take the key value and add that as a string to a unique tag
string or guid. That way I can always tell what specific button or
Inspector/Explorer a tag belongs to.

 

[Shawn]

I can see that if we need to keep some sort of state for the button/menu items. But, we don't have any state that we need to keep track for our buttons. So, for now this will do.

kenslovak wrote on Mon, 10 May 2010 14:58

I don't like using a pure guid for that. I often have to maintain state on
things such as toggle buttons on a per Inspector basis. What I do is
maintain a key property (int) that I use as an index into wrapper
collections for Inspectors and Explorers. Each wrapper class stores the key
value for that instance, which is a unique number during that Outlook
session. Then I take the key value and add that as a string to a unique tag
string or guid. That way I can always tell what specific button or
Inspector/Explorer a tag belongs to.

Submitted using http://www.outlookforums.com