WNDCLASS style in custom controls..

[Borje Hagsten]

Interesting. Often used style is %CS_HREDRAW OR %CS_VREDRAW, which makes
the control repaint itself if resized/moved in x/y direction. Discovered
that this can make a control flicker, if you already handle this yourself.

Also actually can make things slightly slower, especially on slow machines.
Ran the editor I am working on in an old 486 with Win95A and noticed how it
flickered when resized. Removed %CS_HREDRAW OR %CS_VREDRAW from the class
and the flicker disappeared, plus the control actually repainted a tiny bit
faster at scrolling. Last thing shouldn't be affected by those styles, but
still was. Obviously can't believe everything MS says..

Used MS Spy++ to check out the styles for some "commercial" controls and
noticed that especially edit controls often is created without %CS_HREDRAW
and %CS_VREDRAW. Worth playing around with a bit, I think..


------------------

[Semen Matusovski]

Interesting, what happends, if parent has (or do not have) WS_CLIPCHILDREN and repaints itself during moving/sizing ?
(I didn't test)


[This message has been edited by Semen Matusovski (edited March 31, 2001).]

[Borje Hagsten]

Haven't come so far yet. Here is interesting test: In PBnote MDI
sample - WinMain, PBNOTE class has %CS_HREDRAW OR %CS_VREDRAW style
set and PBNOTE32 class has the same. If you run this program and
resize, you'll notice that the toolbar buttons disappeares for a
short moment when program is resized.

So I tested. Remove %CS_HREDRAW OR %CS_VREDRAW from PBNOTE class, so
it only has %CS_DBLCLKS style. Then set hbrBackground member for
PBNOTE class to %NULL instead of %COLOR_APPWORKSPACE + 1. Found that
several "commercial" MDI editors had styles and brushes set this way.

Voila - when you run the PBnote sample, buttons on toolbar remains
visible while resizing. Looks much more "professional". Hint to the
PB people: whoever wrote PBedit actually has made the same "mistake",
when resizing it, the toolbar buttons disappears for a short moment..


------------------

[Semen Matusovski]

Borje -
Without %CS_HREDRAW Or %CS_VREDRAW you will not receive WM_PAINT during sizing.

   #Compile Exe
   #Register None
   #Dim All
   #Include "WIN32API.INC"

   Function PbMain
      Local Msg         As tagMsg
      Local wndclass    As WndClassEx
      Local szAppName   As Asciiz * 80
      Local hWnd        As Long

      szAppName              = "HelloWin"
      wndclass.cbSize        = SizeOf(WndClass)
      ' wndclass.style         = %CS_HREDRAW Or %CS_VREDRAW ' <-----
      wndclass.lpfnWndProc   = CodePtr( WndProc )
      wndclass.hInstance     = GetModuleHandle(ByVal 0&)
      wndclass.hCursor       = LoadCursor( %NULL, ByVal %IDC_ARROW )
      wndclass.hbrBackground = GetStockObject( %BLACK_BRUSH)
      wndclass.lpszClassName = VarPtr( szAppName )
    
      RegisterClassEx wndclass

      hWnd = CreateWindow(szAppName, "Test", %WS_OVERLAPPEDWINDOW Or %WS_VISIBLE, _
           %CW_USEDEFAULT, %CW_USEDEFAULT, %CW_USEDEFAULT, %CW_USEDEFAULT, _
            %NULL, %NULL, wndClass.hInstance, ByVal %NULL)

      While GetMessage(Msg, %NULL, 0, 0)
         TranslateMessage Msg
         DispatchMessage Msg
      Wend
     
   End Function  ' WinMain

   Function WndProc (ByVal hWnd As Long, ByVal wMsg As Long, _
                     ByVal wParam As Long, ByVal lParam As Long) Export As Long

      Dim ps As PAINTSTRUCT, rc As RECT, xu As Static Long
      Select Case wMsg
         Case %WM_PAINT
            Incr xu: GetClientRect hWnd, rc: SetwIndowText hWnd, Str$(xu) + Str$(rc.nRight) + Str$(rc.nBottom)
            BeginPaint hWnd, ps
            SetBkMode ps.hDC, %TRANSPARENT: SetTextColor ps.hDC, %WHITE
            DrawText ps.hDC, "Hello, Windows !", -1, rc, %DT_SINGLELINE Or %DT_CENTER Or %DT_VCENTER
            EndPaint hWnd, ps
         Case %WM_DESTROY: PostQuitMessage 0: Exit Function
      End Select
      Function = DefWindowProc(hWnd, wMsg, wParam, lParam)
   End Function

Probably, for childs it's not dangerous. But anyway it's necessary to be careful and to redraw at least in EXITSIZEMOVE.


------------------
E-MAIL: [email protected]

[Borje Hagsten]

In MDI world, there atre at least three "layers" of controls, Main,
Client and Child, plus of course editor or whatever control one is
using. If all these have %CS_HREDRAW OR %CS_VREDRAW style, there
will be a lot of unnecessary repainting when program is resized, as
seen in PBedit or PBnote sample, where the buttons on toolbar is
"overdrawn" for a short while on resize.

Like you say, Semen - one has to be careful, but rightfully done, it
can make a lot of difference on visual behaviour = "professional"
feeling in an application.

Always interesting to see how others have done things. Using MS Spy++
sure can reveal a lot of "well-hidden secrets" that others use..


------------------

[Dominic Mitchell]

Borje,
Using CS_HREDRAW AND CS_VREDRAW on large windows is a no no since they
cause the entire client area and not just the newly exposed areas to be
invalidated whenever a window is resized.

Semen,
Did you use a spy utility to verify your results?
I had a look at the editor I wrote and all the windows receive WM_PAINT
when resized. None of the windows except the one displaying line numbers
have the CS_HREDRAW or CS_VREDRAW styles.

------------------
Dominic Mitchell

[Semen Matusovski]

Dominic --
For what purpose to use spy, if there is WndProc ?
Under Win2000 I see exactly that without CS_HREDRAW or CS_VREDRAW styles a window receives WM_PAINT, if to increase client area only.
If to decrease - no.
If a window has CS_HREDRAW or CS_VREDRAW, it receives WM_PAINT in any case.

------------------
E-MAIL: [email protected]

[Chris Boss]

Borje;

If you don't use %CS_HREDRAW OR %CS_VREDRAW what must you do to
make sure the window repaints correctly ?

Do you simply invalidate the window in the WM_SIZE and WM_MOVE messages ?

If you invalidate the window yourself, how do you determine what
rectangle to use to invalidate it ?



------------------

[Dominic Mitchell]

Without %CS_HREDRAW Or %CS_VREDRAW you will not receive WM_PAINT during sizing.

Semen,
I was responding to what you said above which is clearly wrong. However, you
corrected your reply in a later post.

Chris,
Windows without the CS_HREDRAW and CS_VREDRAW styles receive WM_PAINT messages
just like any other window. Therefore, the rectangle returned from the call to
BeginPaint is the invalidated area.
The only reason why you would use these styles is so that the entire client area
of a window is invalidated, not just the newly exposed areas, when a window is
resized. There is no special processing needed on your part.


[This message has been edited by Dominic Mitchell (edited March 31, 2001).]

[Semen Matusovski]

Dominic --
Everybody thinks about own apps.
Probably in your editor you do not need to redraw background, to resize/re-allocate childs as result of sizing.
Because typically I do this, to lose WM_PAINT, when user will decrease a window, means, at least, to receive incorrect background.

------------------
E-MAIL: [email protected]

[Borje Hagsten]

Fellows, this is a new area to me so I can't I'm sure about anything
yet. Just that I have looked at the classes in several commercial app's
and noticed they often do things differently. Need to study this more,
but just the simple test I did with PBnote shows there's a lot one can
gain from changing class styles, especially in MDI world..


------------------

[Steve Hutchesson]

Borje,

What I have tended to do depending on the app is to not use those
styles if the window is filled with a control like an edit control
as it will update its display when resized anyway. Another trick
is to set the parent class to a %HOLLOW_BRUSH background colour
and this reduces flicker even further.

%CS_HREDRAW OR %CS_VREDRAW are basically leftovers from win3? but
they still have a few areas where they are needed if you are doing
direct client area graphics and to avoid the worst of flickering,
you need to creat a memory device context, write you graphics on
it an BitBlt the result to the screen.

CS_BYTEALIGNCLIENT or CS_BYTEALIGNWINDOW are supposed to improve
the speed of graphics in the client area of a window.

Regards,

[email protected]

------------------

[Dominic Mitchell]

Semen,
Ok, I see where you are coming from.
When you decrease the size of a window that do not have the %CS_HREDRAW or
%CS_VREDRAW styles it does not receive a WM_PAINT event. However, it always
receives a WM_SIZE event and this is where I handle the resizing of child
controls for the editor. This is a simplication. Also, the editor does not
use the WM_PAINT event. A paint handler is called whenever a WM_PAINT is
generated(window increasing in size or being uncovered). My point is you do
not need those styles in a code or form editor if you are willing to take the
time to figure out what needs repainting.

Steve,
The benefits gained from using CS_BYTEALIGNCLIENT or CS_BYTEALIGNWINDOW
started vanishing with the advent of Win3.0 and are more or less useless
today because display drivers(256-color and up) are byte-aligned.

Window Classes in Win32. Kyle Marsh. Microsoft Developer Network Technology Group.


------------------
Dominic Mitchell