Hi,

I have an app that (sometimes) asserts when run i debugmode in the CView (grandparent to my CFormVew) code for OnMouseActivate. It does so when my app has focus and I position the mouse over, for example, an editor window in VisualStudio and spin the wheel on the mouse. The code for CView is 'ASSERT(pParentFrame == pDesktopWnd || pDesktopWnd->IsChild(pParentFrame));'. Is this a problem in my app or not? Should I even get this message to my view wnd? If I press TryAgain to debug I don't get into debug mode but my app continues as if nothing hapened (loosing focus...).

Ruben

Hej Ruben!

Obviously, MFC wants you to map this to the top-level parent of your app.
There must of course be a reson for this - but you'll have to go over the
MFC source. OTOH, you might just move your handler to the frame window, and
manage as appropriate from there.

Johan Rosengren
Responsable Informatique
PACTA S.A.

Hi,

I have an app that (sometimes) asserts when run i debugmode in the CView
(grandparent to my CFormVew) code for OnMouseActivate. It does so when my
app has focus and I position the mouse over, for example, an editor window
in VisualStudio and spin the wheel on the mouse. The code for CView is
'ASSERT(pParentFrame == pDesktopWnd ||
pDesktopWnd->IsChild(pParentFrame));'. Is this a problem in my app or not?
Should I even get this message to my view wnd? If I press TryAgain to debug
I don't get into debug mode but my app continues as if nothing hapened
(loosing focus...).

Ruben

Hej Johan,

I have gone over the CView source but I don't quite understand it, here it is:

int CView::OnMouseActivate(CWnd* pDesktopWnd, UINT nHitTest, UINT message)
{
 int nResult = CWnd::OnMouseActivate(pDesktopWnd, nHitTest, message);
 if (nResult == MA_NOACTIVATE || nResult == MA_NOACTIVATEANDEAT)
  return nResult;   // frame does not want to activate

 CFrameWnd* pParentFrame = GetParentFrame();
 if (pParentFrame != NULL)
 {
  // eat it if this will cause activation
  ASSERT(pParentFrame == pDesktopWnd || pDesktopWnd->IsChild(pParentFrame));

  // either re-activate the current view, or set this view to be active
  CView* pView = pParentFrame->GetActiveView();
  HWND hWndFocus = ::GetFocus();
  if (pView == this &&
   m_hWnd != hWndFocus && !::IsChild(m_hWnd, hWndFocus))
  {
   // re-activate this view
   OnActivateView(TRUE, this, this);
  }
  else
  {
   // activate this view
   pParentFrame->SetActiveView(this);
  }
 }
 return nResult;

I could probably avoid this by doing the check in my form view and if the expression in the ASSERT would return false just skip the call to the parent class and return an appropriate value. The problem with this is that I don't understand why I have to do this, I mean how many other places do I have to do a similar test? I thought the WM_MOUSEACTIVATE should only go to the window under the mouse pointer (which isn't my window), which probably is the main problem here.

I don't get the ASSERT if I click in another window when my app is active (and I don't get a WM_MOUSEACTIVATE). It's only if I spin the mouse wheel over another window or even the desktop itself.

Also, why doesn't the de{*filter*} start when I hit Retry?

So many questions....

Ruben

Tjena Ruben!

Comments inline

is:

pDesktopWnd->IsChild(pParentFrame));

Here the code will assert if the view parent is not the desktop or the
parent is not a top-level window. In this case, you must have created a view
with a non-toplevel frame as a parent?

<snip>

The problem seems to be the parent-relation for CViews - are you perhaps
hosting a CView in a non-CFrameWnd derived class?

(and I don't > get a WM_MOUSEACTIVATE). It's only if I spin the mouse wheel
over another

The reason for *not* getting assertions is obviously that the other windows
don't derive from CView :-) But I am a bit surprised, do the ASSERT trigger
in your CView when you use the mouse wheel over windows outside your own
app? Are you perhaps capturing the mouse in your view, or something like
that?

This also leads me to suspecting you are doing something fundamentally...
bad? In your place, I would have made a minimum project - that is an empty
app with the same basic structure for the frame and view(s), and then
checked if there was a problem with this basic setting. If not, you have
some fishy proceedings in your code, try to copy suspect code to the test
project. Suspect code in this case would be mouse captures, hooks and the
like.

Med ett schysst j?rnr?r sl?r man v?rlden med h?pnad :-)

<snip>

Johan Rosengren
Responsable Informatique
PACTA S.A.

I searched my VC 5 copy of the MFC source for pDesktopWnd and found that
ASSERT in CView::OnMouseActivate and CMDIChildWnd::OnMouseActivate. Since
you say it is in the code for CView, I will assume it is in
CView::OnMouseActivate. The documentaion of CWnd::OnMouseActivate makes it
clear that pDesktopWnd is "a pointer to the top-level parent window of the
window being activated". Evidently the ASSERT is determining that it is not.
In my copy of the soruce the line prior to the ASSERT has the comment "eat
it if this will cause activation". I do not know what that means; hopefully
someone who does will explain. It is good that you provided the actual
ASSERT but it also helps to provide relevant comments also such as that.

Did you override CView::OnMouseActivate? If so, then you need to tell us
about that too.

Often asserts exist to catch potential problems. If your program works when
you ignore the assert then it will hopefully be easy to fix but sometimes
programmers get around problems by disabling something or doing something
else to make the problem seem to go away. In this case, if you build a
release version then you will not get an assert and the program might work
but then suddenly get sick. That could be embarrasing. So you need to
understand what is causing the assert condition and solve the problem in a
manner that eliminates the possibility of the assert conditon ever existing.

Hi,

I have an app that (sometimes) asserts when run i debugmode in the CView
(grandparent to my CFormVew) code for OnMouseActivate. It does so when my
app has focus and I position the mouse over, for example, an editor window
in VisualStudio and spin the wheel on the mouse. The code for CView is
'ASSERT(pParentFrame == pDesktopWnd ||
pDesktopWnd->IsChild(pParentFrame));'. Is this a problem in my app or not?
Should I even get this message to my view wnd? If I press TryAgain to debug
I don't get into debug mode but my app continues as if nothing hapened
(loosing focus...).

Ruben

Hej Johan,

Have checked a bit further:
When I get the assert in CView, pDesktopWnd points to the frame window of the window that my mouse pointer is positioned over, which definitely isn't my form's top level window !!!!

I also get this assert in a vanilla SDI FormView app, freshly baked by AppWizard with no modification whatsoever.

So, I think it's my mouse driver that is causing me the problems. When I spin the mouse wheel over a window that hasn't got focus, this window first gets focus (just as if I had clicked on it) before it starts scrolling, which means that I can just move the pointer over any window and spin the wheel directly, without first clicking on it, to scroll it's contents.

But somehow the window that previously had the focus gets a WM_MOUSEACTIVATE message with the pDesktopWnd parameter pointing to the top level window of the window under the mouse pointer and this triggers the assert. It also has the effect that the app previously having focus, still thinks that it has focus - it's button in the taskbar is checked and when I click this to get this app back up front it gets minimized instead!

It seams like it's logitech that has screwed up here, or is this a feature (bug) in MFC (don't think so)?

Regards Ruben

Hello Sam and thanks for Your time,

I think I have found the problem - se my earlier reply to Johan Rosengrens post.

Also see comments below.

Yes I did read the doc for CWnd::OnMouseActivate and since it wasn't my apps window that was being activated it just confused me more.

I only overrid it so I could set a breakpoint in it, no code change. That's why I did'n tell :-)

What it all boils down to is - Could there be any circumstances when my view gets a WM_MOUSEACTIVATE message with a pointer to ANOTHER window's top level parent as the pDesktopWnd parameter? Should I ever need to handle this?