Re: Annoying PeekMessage/OnActivateView problem

From: Uwe Kotyczka (uwe.kotyczka_at_web.de)
Date: 06/08/04 

Date: 8 Jun 2004 02:17:56 -0700

Thanks for your reply, Joe.

So now I have two working solutions. I really would like to know why you
think that your's is better. Of course I see that the WM_MOUSEACTIVATE
handler is a proper place to handle this feature, allthough we also need a
helper variable here. OTOH the virtual OnActivateView does not seem to be the
complete wrong place to me. I guess is the PeekMessage call which you really
reccommend not to use. Could you tell me why PeekMessage is such a no-no
in a MFC app?
I use PeekMessage very rarely. Very seldom with the PM_REMOVE flag in
conjunction with TranslateMessage/DispatchMessage. And in some cases
when I have a group of radio buttons. When adding handlers for the radio
buttons I see the handlers being called once if I click the buttons.
But with the arrow keys each handler is called twice. If I really don't want
the handler being called twice I check for WM_MOUSE_MOVE with PM_NOREMOVE.
Never had problems with PeekMessage here.

Regards, Uwe

> You should not need a Boolean to decide to ignore the mouse click; that's what
> OnActivate/MA_ACTIVATEANDEAT does automatically.
>
> Indeed, I just did a little splitter project and WM_MOUSEACTIVATE is sent even if the
> window is already activated. But I discovered that an OnKillFocus handler can solve this.
> Here's my code:
>
> void CMaView::CMaView()
> {
> ...
> Eat = TRUE; // depending on taste, this might have to be set to FALSE
> }
>
> void CMaView::OnKillFocus(CWnd* pNewWnd)
> {
> CView::OnKillFocus(pNewWnd);
>
> Eat = TRUE;
>
> }
>
> int CMaView::OnMouseActivate(CWnd* pDesktopWnd, UINT nHitTest, UINT message)
> {
> if(Eat)
> { /* eat it */
> Eat = FALSE;
> return MA_ACTIVATEANDEAT;
> } /* eat it */
>
> return CView::OnMouseActivate(pDesktopWnd, nHitTest, message);
> }
>
> void CMaView::OnLButtonDown(UINT nFlags, CPoint point)
> {
> MessageBeep(0);
>
> CView::OnLButtonDown(nFlags, point);
> }
>
> While this also uses a Boolean, it isn't related to the the LButtonDown handler; it
> controls whether or not the MA_ACTIVATEANDEAT value is returned. The effect of this is
> that the WM_LBUTTONDOWN produces no sound the first time it is clicked in one of the
> splitter panes, and boinks (read: zooms) on subsequent clicks. And it doesn't involve
> PeekMessage.