Announcement

Collapse
No announcement yet.

WNDCLASS style in custom controls..

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • WNDCLASS style in custom controls..

    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..


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

  • #2
    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).]

    Comment


    • #3
      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..


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

      Comment


      • #4
        Borje -
        Without %CS_HREDRAW Or %CS_VREDRAW you will not receive WM_PAINT during sizing.
        Code:
           #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]

        Comment


        • #5
          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..


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

          Comment


          • #6
            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
            Dominic Mitchell
            Phoenix Visual Designer
            http://www.phnxthunder.com

            Comment


            • #7
              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]

              Comment


              • #8
                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 ?



                ------------------
                Chris Boss
                Computer Workshop
                Developer of "EZGUI"
                http://cwsof.com
                http://twitter.com/EZGUIProGuy

                Comment


                • #9
                  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).]
                  Dominic Mitchell
                  Phoenix Visual Designer
                  http://www.phnxthunder.com

                  Comment


                  • #10
                    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]

                    Comment


                    • #11
                      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..


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

                      Comment


                      • #12
                        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]

                        ------------------
                        hutch at movsd dot com
                        The MASM Forum

                        www.masm32.com

                        Comment


                        • #13
                          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
                          Dominic Mitchell
                          Phoenix Visual Designer
                          http://www.phnxthunder.com

                          Comment

                          Working...
                          X