Re: when and how do the the system inform the CFormView to redraw ?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Thanks, Joe.
I will try to demestrate the effect later with your tips.

I think we have egnore one import aspect about WM_PAINT message.
If both parent and it's children control have invalidate area, in which
order that system send WM_PAINT ?
Is it send WM_PAINT to parent earlier than childrens? Is the sequence of
WM_PAINT sent to childrens
accord to their tab-order or Z-Order?

Best Regard
youhua wang

"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:r3e851pmdenh57v8ife27eblmv58drcfjk@xxxxxxxxxx
> In CS_PARENTDC, which is a style many controls have, the clipping
rectangle of the DC when
> the OnPaint handler is called is the client rectangle of the parent
window.
>
> CS_CLASSDC is a DC that is shared among all instances of the class. This
is a throwback to
> the days of 16-bit Windows where space was at such a premium that such
optimizations were
> often necessary. It is not clear that it has much value in Win32.
>
> CS_OWNDC establishes a "static" DC for each window. Thus changes made in
the DC on one
> call are retained across calls. While there may be performance issues that
would make this
> desirable, the side effects of retaining these settings may result in a
more complex
> program. However, it may sometimes make sense to do this. I have yet to
run across a case
> where I would want this, but I'm not trying for incredibly
high-performance graphics (and
> if I did, I'd probably be motivated to learn DirectX drawing techniques).
>
> So on the whole, you can ignore these class options in terms of your own
classes. However,
> the fact that most controls use CS_PARENTDC may necessitate computing your
own clipping
> rectangle to keep drawing from spilling out onto the parent window; I've
had to do this in
> several cases.
> joe
>
> On Wed, 6 Apr 2005 18:24:31 +0800, "youhua.wang"
<youhua.wang@xxxxxxxxxxxxxxxxxx> wrote:
>
> >Thank Joe.
> >
> > Your detailed statement as well as Scott's give me clearer enderstand
> >about window's message mechanism.
> >
> >BTW,
> >Last week, i have figure out a demo project that vividly show the effect
of
> >WS_CLIPSIBLINGS and WS_CLIPCHILDREN to help me grasp the useage of these
> >style.
> >
> >But i haven't grasp the usage of CS_PARENTDC, CS_CLASSDC, CS_OWNDC. Nor
have
> >i figure out a demo project to show the defferent effect of them.
> >
> >Is there any project explain the effect of those calss style?
> >
> >I think maybe you can help me on this because your abundant experience.
Save
> >my launch another topic thread ^_^
> >
> >Thank again for your earnest help.
> >
> >
> >"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
> >news:8ir651hv32jncmm1d0ma7eeqkgmv0rhjt9@xxxxxxxxxx
> >> OK, that's a more reasonable set of questions.
> >>
> >> In a multi-generation descendant window organization, the problem is
> >identical to having a
> >> single top-level window: each window is responsible for drawing itself.
No
> >window EVER
> >> sends a WM_PAINT message to any other window; in fact, to do so would
be a
> >deep and
> >> fundamental mistake. So the answer is that nobody is responsible for
> >sending the messages;
> >> the responsibility is solely the Windows USER component.
> >>
> >> A window is responsible for determining if a change to its data
requires
> >its contents, or
> >> a piece of its contents, generates a need to redraw all or part of
itself.
> >Thus each
> >> window implements whatever its policy is with respect to its data
changes.
> >It, and it
> >> alone, is responsible for INITIATING the WM_PAINT process, and it does
so
> >by calling
> >> InvalidateRect to mark whatever area of the window now requires
redrawing
> >(or the simpler
> >> Invaldiate() if the entire contents need to be redrawn). Parents are
not
> >even a part of
> >> the question, let alone part of the answer.
> >>
> >> In the case of CFormView, the answer is the same. The child control and
> >only the child
> >> control is responsible for determining if it needs to be redrawn. You,
the
> >programmer,
> >> will never, ever, under any conditions imaginable, send a WM_PAINT
message
> >at any time, to
> >> any window. You will only invalidate the contents of the window in
which
> >you are working.
> >> Under some fairly rare but interesting conditions you may call
> >UpdateWindow to force an
> >> immediate redraw, having invalidated the window. Note that a window
only
> >invalidates
> >> itself, not a child or parent window. In some cases, such as
> >document/view, a view may
> >> send a notification to another window to request it to update itself;
> >because underlying
> >> data has changed. In this case, the window that receives the message,
by
> >examining the
> >> data involved, computes the area to be invalidated, and invalidates its
> >own contents.
> >>
> >> To a first approximation, the only interfaces you are allowed to have
> >between windows
> >> involve:
> >> * parent windows calling methods of child windows to change or
> >query the
> >> state of the child
> >> * parent windows sending messages to child windows to change or
> >query the
> >> state of the child
> >> * child windows sending messages to parent windows to change or
> >query the
> >> state of the parent (NEVER, EVER will a child window, in a
> >properly-designed
> >> system, have a #include of its parent class! This is poor design
> >methodology!)
> >> * Windows sending messages to sibling windows to indicate an
> >> interaction between two associated windows (one view requesting another
> >> view to update itself, "buddy" controls such as spin/edit controls, and
> >> the like)
> >> joe
> >>
> >> On Tue, 5 Apr 2005 11:54:01 +0800, "youhua.wang"
> ><youhua.wang@xxxxxxxxxxxxxxxxxx> wrote:
> >>
> >> >Thank your response, Joe.
> >> >
> >> > I haven't overrode OnWndMsg although i wish to ^_^. I think it is
one
> >> >hard task.
> >> >
> >> >Now, goto the point. It is just a study case. What i want is to
> >understand
> >> >the mechanism.
> >> >1) In multi-generation descendent children window case, who's duty to
> >send
> >> >WM_PAINT to children window? Is the root-parent window or
direct-parent
> >or
> >> >the window system ?
> >> >
> >> >2) In narrow case , such as CFormView, CDialog, who's children window
are
> >> >standard common control, is up to CFormView/CDialog to send children
> >> >control WM_PAINT message , or up to window system ?
> >> >
> >> >
> >> >"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
> >> >news:49c351h2gs77d76fmgu4n65dsnohriprh3@xxxxxxxxxx
> >> >> CFormViews rarely, if ever, have anything to redraw. In fact, if
they
> >do,
> >> >you have
> >> >> probably made a mistake.
> >> >>
> >> >> Putting an OnPaint message in a CFormView is almost always a
> >fundamental
> >> >design error. Why
> >> >> do you think you need one?
> >> >>
> >> >> In a decade of MFC programming, I overrode OnWndMsg exacty once, and
> >that
> >> >was when I was
> >> >> doing some very sophisticated tracing of a message as part of a
student
> >> >example program.
> >> >> So as soon as I hear someone being concerned about it, I immediately
> >come
> >> >to the
> >> >> conclusion they are making a deep and extremely serious design
error.
> >I'm
> >> >sure your
> >> >> problem can be described this way.
> >> >>
> >> >> Whenever there is a desire to draw on the CFormView surface, there
is
> >> >almost always a much
> >> >> better way to do it, and in most cases, the reason for drawing on
the
> >> >CFormView was
> >> >> misguided.
> >> >>
> >> >> Instead of asking how to do something that is probably wrong, how
about
> >> >describing your
> >> >> problem so a correct solution can be proposed?
> >> >> joe
> >> >>
> >> >> On Mon, 4 Apr 2005 18:19:04 +0800, "youhua.wang"
> >> ><youhua.wang@xxxxxxxxxxxxxxxxxx> wrote:
> >> >>
> >> >>
> >> >> Joseph M. Newcomer [MVP]
> >> >> email: newcomer@xxxxxxxxxxxx
> >> >> Web: http://www.flounder.com
> >> >> MVP Tips: http://www.flounder.com/mvp_tips.htm
> >> >
> >> >Best Regard!
> >> >youhua wang
> >> >
> >>
> >> Joseph M. Newcomer [MVP]
> >> email: newcomer@xxxxxxxxxxxx
> >> Web: http://www.flounder.com
> >> MVP Tips: http://www.flounder.com/mvp_tips.htm
> >
>
> Joseph M. Newcomer [MVP]
> email: newcomer@xxxxxxxxxxxx
> Web: http://www.flounder.com
> MVP Tips: http://www.flounder.com/mvp_tips.htm


.

Relevant Pages

  • Re: Casting CWnd-derived Pointers ?
    ... you should not be accessing member functions of a parent window from a child ...
    (microsoft.public.vc.mfc)
  • Re: Win32 - forked process doesnt create a Window
    ... > The only thing missing is the graphical window for NOTEPAD so I can type ... returns zero to the child. ... you are exec'ing from the parent ...
    (comp.lang.perl)
  • Re: Composite. Again!
    ... >> In order to hide its child components the parent needs to become a ... Which means that every operation required to invoke on child ... >> needs to be passed thought parent. ... > Then how does the Window object know which interfacea view implements? ...
    (comp.object)
  • Re: System.ArgumentException on close when dialog not on top
    ... I'm not trying to close the parent of a child. ... close the parent of an active window without closing that window, ... the parent that no longer contains sensible data, causing the exception. ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: Need help solving a threading issue
    ... (represented by a SendMessage to the window) ... create HWND's on a secondary thread. ... thread, but the issues really *are* different if you create child windows, dialogs, etc. ... I agree a child HWND whose parent was created in another thread is an issue, ...
    (microsoft.public.vc.mfc)