Is there a reason MailItem.Display method's z-order behaviour varies across machines?

Question

We're finding that calling the

myMailItem.Display(false)

method works fine on our development machine, in that it opens the message window in the user's foreground. Whether or not we're running within VS/with debugger attached or simply as an installed application.

However on certain customers' machines the message opens behind our Winforms application.

The version of Windows doesn't seem to make any difference.

Is this something that can be explained and predicted?

Of course we can play around with setting SetForegroundWindow but I'd prefer to be able to understand why the difference and reproduce the "problem" on our development machine before blindly experimenting with SetForegroundWindows etc.

Answer 1

This is a pretty normal mishap. The window that's used to display the mail item is owned by a different process, Outlook.exe. Whether or not an process can push one of its own windows into the foreground is a crap-shoot, the basic heuristics used by the Windows window manager are described in this MSDN Library article.

Getting a consistent repro for this on your own machine is going to be difficult. One thing I've observed on later versions of Windows is that timing appears to play a role as well. The longer it takes the app to get the window created, the bigger the odds that it won't work and ends up behind the current foreground window. Already common before because input events play a role. The typical hang-up with dev machines is that they have too much horse-power :)

The only consistent way to avoid it is to write your app as an Outlook add-in so that your window is owned by the same process and thread as the Outlook window. That ship probably sailed a long time ago. Next best thing is to maximize the odds that Outlook succeeds, do force the foreground window to an Outlook window. Hard to do unfortunately, check this post for code. Use Spy++ to check if the window class name is still accurate. And minimize your own window so it is completely out of the way for the Outlook window and cannot possibly get any input events.