Menu and window redraw

Menu and window redraw

Until now I used a Win32 application under Windows95. (CVF6.6B). Now I have changed the system to Windows 2000.
There appeared to be an important difference in redrawing the window when an activated menu is removed from the screen. In W95 only the part used by the menu was repainted, but in W2000 the whole window is repainted.
As well an executable made under W95 as a newly compiled and linked executable under W2000 produces the same problem.
How can I anticipate this complete redraw of the window when using a menu?
My program is an W32 application using OpenGL to draw the user window area.

Guus.

9 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

How did you reach that conclusion? A quick test I performed (both from my code and using Spy++) shows that WM_PAINT is never sent on Win2000 when a menu is opened/closed (as it should be, because Windows keeps the area beneath the menu buffered).

Jugoslav www.xeffort.com

First I reach the conclusion simply visual. The drawing is extensive and the building of it can be followed. When I select a menu item from the main menubar and release the left mouse button (without selecting an item) the menu is removed and the window is redrawn completely.
I also checked the messages with Spy++ and saw a WM_PAINT when selecting a menu item from the menu bar that yields a submenu.
Spy++ let us see the following messages ( WM_SETCURSOR and WM_ENTERIDLE ignored):
WM_MENUSELECT (with MF_POPUP)
WM_INITMENUPOPUP
WM_PAINT
WM_NCPAINT
WM_GETTEXT
WM_ERASEBKGND
WM-UNINITMENUPOPUP
WM_CAPTURECHANGED
WM_MENUSELECT (menu was closed)
WM_NCHITTEST
WM_SYSCOMMAND
WM_NCHITTEST
WM_PAINT

Guus.

Hmmm, I believe you, but I tried the same on 2-3 different applications and none exhibited such behaviour -- try it yourself. I see that WM_PAINT is sent only after overlapping of windows. Are you sure that something in your handler doesn't call InvalidateRect(NULL) in the process? Probably no, but...

After all, maybe it has something to do with different implementations of OpenGL. I know very little about OpenGL; maybe you could try some kind of double buffering (off-screen rendering)?

Jugoslav www.xeffort.com

Just found an interesting article in MSDN: "OpenGL VI: Rendering on DIBs with PFD_DRAW_TO_BITMAP" by Dale Rogerson.

Jugoslav www.xeffort.com

Jugoslav, thank you for your hint for the OpenGL-article.

I have only one InvalidateRect in my program, but it is located after a WM_QUERYNEWPALETTE message. I inserted a breakpoint at that position, but the position was not reached during execution.
There is another thing. I have three programs using OpenGL. Two of the three programs show the same behaviour of unexpected redraws, but one program does show the redraw when using the menu.
I think it is the best that I try to search the difference between them that cause the redraw.
I will come back, if I find the problem.

Guus.

Sorry, if this message appears twice, but I replied via the Reply-button in the last reply and I can not find the message on the thread. If I search for "New messages since last visit" it is listed, but I see only the first line.
So I reply again via the Topic-reply.

Jugoslav, thank you for the hint on the OpenGL article. It looks interesting.
But concerning my problem...
I found one InvalidateRect in my program after the handling of a WM_QUERYNEWPALETTE message, but I insert a breakpoint and it appears that this message is not reached.
I have three programs using OpenGL to draw the window. Two of the three programs show the reported problem of redrawing the window when the menu is clicked, but one of the programs does not show the problem. So, I think I will concentrate on the differences between the programs and try to find the problem by removing the differences gradually.
I come back when I isolate the problem.

Guus.

At last I solved the problem of the redraw by using double buffering as Jugoslav suggested already. This is at all events a good solution, because I don't see anymore the building of the drawing. Now it is built in the backbuffer and the Swapbuffer command puts it on the screen without delay.
By the way, there is still a WM_PAINT, but now it does not produce any pain.

Guus.

Well, I'm still curious about that WM_PAINT generation, but I guess some things will remain a mystery forever. I'm glad it works now -- "Don't fix if ain't broken".

All the best,
Jugoslav

Jugoslav www.xeffort.com

Login to leave a comment.