Do you receive WM_PAINT when waiting for a COM call to return?

When a COM call is made that involves a COM Proxy or a call to CoWaitForMultipleHandles() (e.g. in a .NET Runtime Callable Wrapper), you could see this behavior where you would not have under pre-Vista versions of Windows.

We made the design change in Vista, among other reasons, to allow proper painting of the applications when the consent dialog is shown.

If you suffer from this design change and you cannot easily modify your code to handle gracefully this type of reentrancy, you’ll want to ensure that Windows behaves the way it used to.

How do you do that?

As explained in this Connect Feedback:

You can work around this by doing an application compatibility shim. The flag is DisableNewWMPAINTDispatchInOLE.

Once you have downloaded the Application Compatibility Toolkit (version 5.5 as of 8/4/2009), run the Compatibility Administrator program to create a new database for your software and follow the steps to produce an SDB for your software. This could include several .EXEs but no DLLs, as those cannot be shimmed.

You’ll want to make sure you pick the right flag in the following dialog:

Once you’ve created you .SDB file, you can register the information it contains by running sdbinst.exe on the file. When installing your software, you’ll want to have a Windows Installer Customer Action launching sdbinst.exe with the same .SDB file as parameter.

I’m no A.C.T. guru so please look at the Application Compatibility site for more information.

 

Note added after initial post:

Ensure that the cache is flushed:

· Elevate cmd

· Execute the following line from the elevated console Rundll32 apphelp.dll, ShimFlushCache