Anyone have any comments about calling VCL's (Delphi/Builder)
Application->ProcessMessages() function from within a COM add-in, like
inside of the OnDisconnect event to make sure any modeless VCL forms
are destroyed and all messages processed before Outlook unloads the
add-in? As a general practice I don't like to run my own message loop
like that, because any custom processing Outlook's internal message
loop does, would be skipped, but I've done a bit of testing and it
doesn't seem to cause problems so far...

Also, I'm going to be doing some long processes sometimes and I'd like
to make this as transparent as possible to the Outlook user. Is this
also a good place to call ProcessMessages(), or run a PeekMessages()
loop, or is there some other method which lets me yield to Outlook?
Or do I even need to worry about this, since Outlook seems to run a
seperate thread for COM add-ins anyway?

I'm developing for Outlook 2000, 2002, and 2003. Thanks for any
advise!

No, Outlook COM addins run in the main Outlook thread. You can however run
your code in your own threads.
Why do you need to run a message loop and wait for the modeless VCL forms to
be closed? Why can't you close them programmatically? Or better yes, make
your forms children of the Outlook explorers/inspectors (so that they don't
get their own task bar buttons) and close them whenever the parent Outlook
window closes - see uParentedWnd.pas in the Babelfish addin source code on
my site.

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


"Eric" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Anyone have any comments about calling VCL's (Delphi/Builder)
> Application->ProcessMessages() function from within a COM add-in, like
> inside of the OnDisconnect event to make sure any modeless VCL forms
> are destroyed and all messages processed before Outlook unloads the
> add-in? As a general practice I don't like to run my own message loop
> like that, because any custom processing Outlook's internal message
> loop does, would be skipped, but I've done a bit of testing and it
> doesn't seem to cause problems so far...
>
> Also, I'm going to be doing some long processes sometimes and I'd like
> to make this as transparent as possible to the Outlook user. Is this
> also a good place to call ProcessMessages(), or run a PeekMessages()
> loop, or is there some other method which lets me yield to Outlook?
> Or do I even need to worry about this, since Outlook seems to run a
> seperate thread for COM add-ins anyway?
>
> I'm developing for Outlook 2000, 2002, and 2003. Thanks for any
> advise!

I do call TForm::Close() to close the form when Outlook closes, or
more specificly when the explorer or inspector closes, or my add-in is
unloaded. TForm::Close() doesn't free the object until the remove
message is processed though. I guess I could just use PeekMessage()
to only process the remove message, or maybe it is safe to use the
delete opperator on a TForm, but I've never tried that. I could
probably have to call Close() first, and then delete, so the window
handles get destroyed?

But before I get way off-topic for this group (oops too late), and
into a VCL group topic, I'm still wondering if I can process messages
during these other lengthy processes which might take several seconds
to complete. I'd rather not use seperate threads, mostly because most
COM add-ins I see don't do it, and I don't want to be making the
add-in that flushes out all the bugs/issues related to this. I will
be using purely Extended MAPI during these processes, so I guess
another thread is an option still, I'm just gun-shy when it comes to
calling MAPIInitialize() myself, because 75% of the error messages
reported by users have been that the call to MAPIInitialize() fails,
even though they are quick to point out "Outlook is working just fine,
and it initializes MAPI, how come your application can't".

Thanks!

"Dmitry Streblechenko" <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> No, Outlook COM addins run in the main Outlook thread. You can however run
> your code in your own threads.
> Why do you need to run a message loop and wait for the modeless VCL forms to
> be closed? Why can't you close them programmatically? Or better yes, make
> your forms children of the Outlook explorers/inspectors (so that they don't
> get their own task bar buttons) and close them whenever the parent Outlook
> window closes - see uParentedWnd.pas in the Babelfish addin source code on
> my site.
>
> Dmitry Streblechenko (MVP)
> http://www.dimastr.com/
> OutlookSpy - Outlook, CDO
> and MAPI Developer Tool
>

Destroying the form will hide and completely release all its resources,
there is absolutely no reason to close it first.
Nothing's wrong with using your own threads in Outlook add-ins/extensions, I
do it all the time.
You do not need to call MAPIInitialize() if you are in the main Outlook
thread, your own threads are your responsibility, so you do need to
initialize MAPI, but I never had any problems with MAPIInitialize() in my
own threads.

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


"Eric" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> I do call TForm::Close() to close the form when Outlook closes, or
> more specificly when the explorer or inspector closes, or my add-in is
> unloaded. TForm::Close() doesn't free the object until the remove
> message is processed though. I guess I could just use PeekMessage()
> to only process the remove message, or maybe it is safe to use the
> delete opperator on a TForm, but I've never tried that. I could
> probably have to call Close() first, and then delete, so the window
> handles get destroyed?
>
> But before I get way off-topic for this group (oops too late), and
> into a VCL group topic, I'm still wondering if I can process messages
> during these other lengthy processes which might take several seconds
> to complete. I'd rather not use seperate threads, mostly because most
> COM add-ins I see don't do it, and I don't want to be making the
> add-in that flushes out all the bugs/issues related to this. I will
> be using purely Extended MAPI during these processes, so I guess
> another thread is an option still, I'm just gun-shy when it comes to
> calling MAPIInitialize() myself, because 75% of the error messages
> reported by users have been that the call to MAPIInitialize() fails,
> even though they are quick to point out "Outlook is working just fine,
> and it initializes MAPI, how come your application can't".
>
> Thanks!
>
> "Dmitry Streblechenko" <(E-Mail Removed)> wrote in message
news:<(E-Mail Removed)>...
> > No, Outlook COM addins run in the main Outlook thread. You can however
run
> > your code in your own threads.
> > Why do you need to run a message loop and wait for the modeless VCL
forms to
> > be closed? Why can't you close them programmatically? Or better yes,
make
> > your forms children of the Outlook explorers/inspectors (so that they
don't
> > get their own task bar buttons) and close them whenever the parent
Outlook
> > window closes - see uParentedWnd.pas in the Babelfish addin source code
on
> > my site.
> >
> > Dmitry Streblechenko (MVP)
> > http://www.dimastr.com/
> > OutlookSpy - Outlook, CDO
> > and MAPI Developer Tool
> >