OI Version 4.1.2 - Win 2000

Have you ever noticed that parts of the background application sometimes paint through onto you OI application? I have and I find this behaviour tacky so have looked into it. So far this is what I have noticed.

1) This paint through affect can be seen in the OI MAPI application (from RevTech).

2) It is particularly bad when Internet Explorer is the immediate background application. Outlook seems not to show this problem

3) Paint through occurs for the short period after the window (MDI child) is started but before the Create event of this child is called.

To see this effect open the main window of the OI MAPI application. Position the button bar of Internet Explorer so that it overlaps the top of (but is behind) the MDI client area. Choose the ?Read Mail? menu item then wave mouse cursor over the top of the MDI client area (i.e. over the position of the internet explorer buttons (which are hidden of course)). If you do this before the read mail window has a chance to open then you will (may) see the Internet Explorer buttons painted on top of the OI application.

Has anyone else noticed this ??? Any ideas of a cure ???

Kevin,

Your problem is one that has been reported several times. My first post on this was back in '98.

So far no one at Revelation has resolved it. I believe they have had difficulties replicating the problem.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Kevin,

Has anyone tried the process I descried in the first posting of this thread?

Oh yes. Your scenario is almost identical to the typical problems we see everyday. It seems to happen when a window with hover buttons appears behind the OI window.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Don,

I think I figured this one out and have a fix for the next OI 7.0 beta release.

Let me describe what the set of events are that set this up (although Kevin pretty much nailed it already).

OI likes to create it's windows hidden so it can add in all of the controls and then display it all at once. Apparently it is not possible to create a Mdi Child window that it not visible, so to work around this, OI sends a WM_SETREDRAW:FALSE message to the Mdi Frame window, creates the Mdi Child window, and then hides the just create Mdi Child window first thing.

Currently, OI then creates all of the controls of that window while the WM_SETREDRAW is FALSE. Once the all of the controls have been created, OI sets the Mdi Child to be visible. Finally, OI sets WM_SETREDRAW back to TRUE and forces a redraw of the entire Mdi Main window.

What I believe is happening is that while the Mdi Frame window is in the WM_SETREDRAW FALSE mode that you get the bleed through effect. So a good way to reproduce this would be to create a Mdi Child window that contains a LOT of controls, causing the Mdi Frame to be in the WM_SETREDRAW FALSE mode for a long time.

What I did to fix this is I set the WM_SETREDRAW mode back to TRUE immediately after creating and then hiding the Mdi Child window, rather than waiting until all of the controls of this child window are created as is currently being done.

I don't know why you would get such a bleed through in this scenario and have a slight concern that there is still a very, very small time slice when the Mdi Frame is in this state. It does seem to be a small enough time frame that I was unable to reproduce the problem with this fix.

Pat

Has anyone tried the process I descried in the first posting of this thread? It would be interesting to know if it can be reproduced in other OI systems. If it is then I expect that RevTech would be keen to try it them self (and fix it).

Thanks for the responses

Kevin,

Many people - me included - have reported this repainting bug in MDI frames. Have you really found a consistent way to reproduce the problem? You give me hope. Perhaps this will enable Revelation to find a solution.

- Oystein -

Pat - Thanks for looking into this issue. It's good to know that it will be all but gone in version 7.

View this thread on the forum...