Best Practice UI handling for long-running code

[Mark Lawrence]

I've got an addin (VSTO 2008 on Outlook2007) that, upon startup, at user
option may make a web service call to get information to populate a bunch of
postItems in a folder. The web service call could take some time. If the
number of rows returned is large, creating the associated postItems could
take some time.

In previous efforts, there have been ways to manipulate the mouse icon for
the application to indicate that things are happening. I can find examples
for doing that for forms but not for the application in general. Is there a
best practice (other than "don't do that" )

Also, while working through the returned data and creating postItems, is it
necessary to pause occasionally and allow display refresh events to process
so that the user can see what's happening? If so, is there a best practice
for doing that?

 

[Ken Slovak - [MVP - Outlook]]

The actual Web service call can be made asynchronously using a background
worker thread. Any processing using the Outlook object model should always
be done in the main thread however, otherwise you crash or hang Outlook.

If the processing can take a long time using the Outlook object model then
you can divide it into a few parts and use a timer to determine when each
piece of the processing is done, say 10 items at a time or whatever. If
that's not possible due to needing to have all the data available
simultaneously then you could put up a progress dialog or something like
that to inform the user the process was ongoing. Calling to
Application.DoEvents() will allow the Windows message pump to run and will
allow the progress dialog to update. I usually do that once per loop
iteration if I'm running a long-running process.