D
D-Code-99
Hi,
I've been trying to get my app to trigger a Send/Receive in Outlook from my
C++ code through automation. I'm using O2k for this test but the same
behaviour happens with O2k3 + typelibs. I can successfully kick off a
Send/Receive with each account listed (I do this by getting the commandbars,
then the Tools menu, then Send/Receive, then calling Execute() on each
enabled item which is apparently the only way to do this - a major oversight
IMO).
Now I'm making the code more robust. The first check I added is that
Application::ActiveExplorer() returns a valid LPDISPATCH. If it doesn't my
code creates a new, hidden Explorer. This bit works perfectly, but it's shown
up an odd bug.
If Outlook isn't loaded and my code creates a new Explorer, all subsequent
calls to automation methods work perfectly. I can get the command bars and
drill down to the accounts under Send/Receive. I can also call any other
automation method.
However even though I have the CommandBarControl LPDISPATCH of each mail
account, when I call CommandBarControl::Execute() on it the first time
absolutely nothing happens. No exception is thrown, the code execution
continues, but no Send/Receive is done. I can prove this by requiring a
password for the account - no password prompt appears and no network traffic
occurs.
However if I then tell my app to go through the entire process again
beginning with getting the top level CommandBars and drilling down from
there, the Send/Receive works. Therefore the code should not be at fault.
I tested this further. After I find ActiveExplorer returns NULL and I create
a new Explorer, I put an artificial ::Sleep(1000) before beginning the
drill-down to the Send/Receive accounts and Execute()'ing them.
This solves the problem. In other words, after attaching to Outlook, if I
don't artifically pause for approx 1 second after creating a new Explorer,
calling Execute on a CommandBarControl silently fails. No exception is
thrown, no flags are set and Execute is a void return. So it appears to work,
it just doesn't. It's like Outlook needs a second to catch itself up before
you can interact with a CommandBarControl. This problem doesn't occur if an
instance of Outlook already exists (ie: ActiveExplorer() returns a valid
LPDISPATCH).
Has anyone experienced this bug before? Is there a status query method I can
call to check whether Outlook is ready for me to call Execute()? Simply
artificially pausing for a second to hope that it'll work is a nasty
solution. It feels like a bug because of the silent failure.
Thanks!
I've been trying to get my app to trigger a Send/Receive in Outlook from my
C++ code through automation. I'm using O2k for this test but the same
behaviour happens with O2k3 + typelibs. I can successfully kick off a
Send/Receive with each account listed (I do this by getting the commandbars,
then the Tools menu, then Send/Receive, then calling Execute() on each
enabled item which is apparently the only way to do this - a major oversight
IMO).
Now I'm making the code more robust. The first check I added is that
Application::ActiveExplorer() returns a valid LPDISPATCH. If it doesn't my
code creates a new, hidden Explorer. This bit works perfectly, but it's shown
up an odd bug.
If Outlook isn't loaded and my code creates a new Explorer, all subsequent
calls to automation methods work perfectly. I can get the command bars and
drill down to the accounts under Send/Receive. I can also call any other
automation method.
However even though I have the CommandBarControl LPDISPATCH of each mail
account, when I call CommandBarControl::Execute() on it the first time
absolutely nothing happens. No exception is thrown, the code execution
continues, but no Send/Receive is done. I can prove this by requiring a
password for the account - no password prompt appears and no network traffic
occurs.
However if I then tell my app to go through the entire process again
beginning with getting the top level CommandBars and drilling down from
there, the Send/Receive works. Therefore the code should not be at fault.
I tested this further. After I find ActiveExplorer returns NULL and I create
a new Explorer, I put an artificial ::Sleep(1000) before beginning the
drill-down to the Send/Receive accounts and Execute()'ing them.
This solves the problem. In other words, after attaching to Outlook, if I
don't artifically pause for approx 1 second after creating a new Explorer,
calling Execute on a CommandBarControl silently fails. No exception is
thrown, no flags are set and Execute is a void return. So it appears to work,
it just doesn't. It's like Outlook needs a second to catch itself up before
you can interact with a CommandBarControl. This problem doesn't occur if an
instance of Outlook already exists (ie: ActiveExplorer() returns a valid
LPDISPATCH).
Has anyone experienced this bug before? Is there a status query method I can
call to check whether Outlook is ready for me to call Execute()? Simply
artificially pausing for a second to hope that it'll work is a nasty
solution. It feels like a bug because of the silent failure.
Thanks!