defer_bug

[TRMW]
defer_bug=1

normally specified in [TRMW] only.

This setting, added in a patch to releases 4.621 and 4.622, controls how trmw32.dll uses of the Windows API DeferWindowPos(). In some circumstances this API fails and causes a leak, which can cause TRMW32.DLL to suffer from resource starvation and eventually crash.(It is not known exactly what triggers this failure in the API - it seems to be very sensitive to the recent history of how Windows have been created and updated on screen, and apparently similar maps can give rise to different results)

There are three possible settings:

• If defer_bug=0 is set, DP4 expects DeferWindowPos() to work as documented. If a call to DeferWindowPos() fails DP4 does not call EndDeferWindowPos(). This is how Microsoft say you should use handle a failure from DeferWindowPos(), but on Windows XP and 2000, this causes a leak. This setting might be needed on a hypothetical future release of Windows where this bug has been fixed.

• If defer_bug=1 is set, DP4 attempts to work around the bug in DeferWindowPos() by always calling EndDeferWindowPos() whether DeferWindowPos() succeeds or not. When DeferWindowPos() fails, the last good handle returned by DeferWindowPos() is passed to EndDeferWindowPos(). MSDN documentation states that this is the wrong thing to do, but it stops the leak from happening and does not have any known adverse consequences.

• If defer_bug=2 is set, DP4 does not use DeferWindowPos() to change the Z-order of windows. Instead it always uses SetWindowPos(). You can use this setting if you find that you are suffering from the leak, and the work-around added does not fix the leak, or has other adverse consequences. Using this setting might cause the screen display to flicker more than when DeferWindowPos() is used.