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?.

 

[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.

"Shawn" <swalker[at]bynari[dot]net> wrote in message

news:OnISxdy2KHA.5880@TK2MSFTNGP02.phx.gbl...
> 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?.
>

 

[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)

-

"Shawn" <swalker[at]bynari[dot]net> wrote in message

news:OnISxdy2KHA.5880@TK2MSFTNGP02.phx.gbl...
> 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?.
>

 

[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:34
> 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.

> >

>

> "Shawn" <swalker[at]bynari[dot]net> wrote in message
> news:OnISxdy2KHA.5880@TK2MSFTNGP02.phx.gbl...
> > 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?.
> >

 

[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" <swalker[at]bynari[dot]net> wrote in message

news:u8TppUL3KHA.4964@TK2MSFTNGP05.phx.gbl...
> 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.
>

 

[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:11
> Those events are for COM addins, if you aren't writing a COM addin the
> events won't be available.

> >

 

[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" <swalker[at]bynari[dot]net> wrote in message

news:uEaTlTj4KHA.5880@TK2MSFTNGP04.phx.gbl...
> 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.

 

[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:25
> 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.

> >

>

 

[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" <swalker[at]bynari[dot]net> wrote in message

news:%234RgfWl4KHA.3712@TK2MSFTNGP04.phx.gbl...
> 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.
>

 

[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:33
> 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.

> >

>

 

[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" <swalker[at]bynari[dot]net> wrote in message

news:u5aMcCw4KHA.5548@TK2MSFTNGP04.phx.gbl...
> Thanks for the answer. We are not currently using CDO or Redemption. The
> only thing we used is the MAPI folder (IMAPIFolder interface).

 

[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..

 

[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" <swalker[at]bynari[dot]net> wrote in message

news:%23zKIeCx7KHA.5848@TK2MSFTNGP06.phx.gbl...
> 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..

 

[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:58
> 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" <swalker[at]bynari[dot]net> wrote in message
> news:%23zKIeCx7KHA.5848@TK2MSFTNGP06.phx.gbl...
> > 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),/*dispin terface*/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..

 

[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" <swalker[at]bynari[dot]net> wrote in message

news:u4DMr$F8KHA.5412@TK2MSFTNGP06.phx.gbl...
> 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?

 

[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:08
> 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" <swalker[at]bynari[dot]net> wrote in message
> news:u4DMr$F8KHA.5412@TK2MSFTNGP06.phx.gbl...
> > 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?

 

[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:53
> Are you talking about the CommandBarControl.put_Tag? If so, all of the strings is unique.

> kenslovak wrote on Mon, 10 May 2010 13:08
> > 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" <swalker[at]bynari[dot]net> wrote in message
> > news:u4DMr$F8KHA.5412@TK2MSFTNGP06.phx.gbl...
> > > 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?

 

[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" <swalker[at]bynari[dot]net> wrote in message

news:%23VGFLEH8KHA.3276@TK2MSFTNGP02.phx.gbl...
> 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.
>

 

[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.

> >

>

> "Shawn" <swalker[at]bynari[dot]net> wrote in message
> news:%23VGFLEH8KHA.3276@TK2MSFTNGP02.phx.gbl...
> >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.
> >

 

[Basha Shaik]

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?.

Hi,

I'm exactly facing the same issue where ActiveExplorer() is returning NULL.
Details as below
------------------
i. using Outlook 2010.
ii. a COM add-in extending IDTExtensibility2
iii. In the OnConnection() method, I'm calling ActiveExplorer().

Issue
----------
1. When Outlook is launched by double-clicking the icon, everything works fine. i.e ActiveExplorer() return a valid value. It doesn't return NULL. All is well here.

2.
But in some of the cases (when winword is opened, as as explained in this thread), Outlook gets launched with a command line argument '-Embedding' in which case, it would be running in the background without any 'User Interface'.
In this case, ActiveExplorer() returns NULL when OnConnection() is called.

Now, when Outlook is launched by double-clicking, new outlook process gets launched and exits where as the old outlook instance that has been running in background is brought to foreground, displaying the User Interface.

I tried to make a call to ActiveExplorer() on the saved object, CComQIPtr <Outlook::_Application> in GetCustomUI method of the interface IRibbonExtensibility

ActiveExplorer() returns NULL value, still.


For case(2), how can I get ActiveExplorer() to return a Non-Null value when Outlook comes to foreground so that I can register for the events folder change/view change/selection change.

Thanks.